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.

Note: See TracTickets for help on using tickets.