[reSIProcate] IPv6 address in Via header gets its lower order bits chopped off (Win32 platform)

["Van c. Nguyen" <vann@xxxxxxxxxxxxxxx>]

Hi,

I have observed the following IPv6 address problem and will shortly commit
the fix for it.

The IPv6 address gets its lower bits chopped off in the Via header, like so:

Via: SIP/2.0/UDP [2001:618:400:5767::]:48160;branch=...

when it should have been like the Contact header, in this case.

Contact:
<sip:vann@[2001:618:400:5767:E898:721A:FBC0:DAF3]:48160;transport=udp>

Confirmed platform:
Win32 (XP SP2).

Requests formed like this will result in no response from a proxy (Asterisk)
that uses this address (instead of the socket's), to send the response.


--------------------------
The problem, for those interested:

is that assignment of a union member assigns only the number of bytes for
that member, not the entire union block (on Win32 at least). So a union like
the following, which is found in GenericAddress and Tuple:

      union
      {
            sockaddr address;
            sockaddr_in v4Address;
            sockaddr_in6 v6Address;

            char pad[28]; // this make union same size if v6 is in or out
      };

should be assigned as a whole, not constructed with v6 version: 'v6Address',
then assigned elsewhere with 'address', which is considerably smaller. The
ideal solution would be to define the union structure separately so that
it could be used by both GenericAddress and Tuple:

      union
      {
            sockaddr address;
            sockaddr_in v4Address;
            sockaddr_in6 v6Address;

            char pad[28]; // this make union same size if v6 is in or out
      } SockAddr;
...

SockAddr a, b;
a = b;          // safe no matter what garbage is in storage.

Doing this requires too many files changes (or ugly member reference to
other
member structure), since the union members are accessed directly everywhere.
... may be considered down the road.

Files affected:

Tuple.cxx
Tuple.hxx
TransportSelector.cxx
and
rutil/WinCompat.cxx


Van.