Opened 18 years ago
Closed 18 years ago
#250 closed defect (fixed)
Problems with byte ordering in Symbian
Reported by: | bennylp | Owned by: | bennylp |
---|---|---|---|
Priority: | normal | Milestone: | Symbian-trunk-integration |
Component: | common | Version: | trunk |
Keywords: | Cc: | ||
Backport to 1.x milestone: | Backported: |
Description
Problem:
We are having problems with STUN in Symbian. It seems like
STUN request packets do not have the correct format. When
using Windows Mobile, STUN data starts with 0x0001 (Binding
Request); when using Symbian, STUN data starts with 0x0100 -
which does not seem correct.
Presently, pj_htons() is a no-op (pj/sock_symbian.cpp:219):
/* * Convert 16-bit value from host byte order to network byte order. */ PJ_DEF(pj_uint16_t) pj_htons(pj_uint16_t hostshort) { /* There's no difference in host/network byte order in Symbian */ return hostshort; }
We have a deeper problem here. While it's true that the integers in TInetAddr are in host order (therefore pj_ntohx() and pj_htonx() can be made no-op), the pj_ntohx()/pj_htonx() are used by other functions so they must convert the host/network orders correctly.
For now, a quick fix is to replace pj_htonx()/pj_ntohx() calls in STUN with something like swap16() and swap32(). Apart from this, unnfortunately pj_ntohx/pj_htonx are used in RTP and RTCP as well..
Change History (1)
comment:1 Changed 18 years ago by bennylp
- Resolution set to fixed
- Status changed from new to closed
Done. The pj_sockaddr_in now always stores value in network byte order, like all other targets. PJ will convert the value to host byte order before calling Symbian functions.