id summary reporter owner description type status priority milestone component version resolution keywords cc backport_to_milestone backported 250 Problems with byte ordering in Symbian bennylp bennylp " 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.. " defect closed normal Symbian-trunk-integration common trunk fixed