why UDP6 when I use SIMPLE protocol to login SIP proxy?

Hawkins, William - AES Will.Hawkins at itt.com
Wed Sep 26 10:19:59 EDT 2007

I believe I have found the source of the confusion. Udp6, listed by netstat, is a bit of a misnomer. Apparently v6 sockets can be used to communicate with v4 nodes (as a server or client). From RFC2553:

"3.7 Compatibility with IPv4 Nodes

   The API also provides a different type of compatibility: the ability
   for IPv6 applications to interoperate with IPv4 applications.  This
   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
   addressing architecture specification [2].  This address form
   allows the IPv4 address of an IPv4 node to be represented as an IPv6
   address.  The IPv4 address is encoded into the low-order 32 bits of
   the IPv6 address, and the high-order 96 bits hold the fixed prefix
   0:0:0:0:0:FFFF.  IPv4- mapped addresses are written as follows:


   These addresses can be generated automatically by the
   getipnodebyname() function when the specified host has only IPv4
   addresses (as described in Section 6.1).

   Applications may use PF_INET6 sockets to open TCP connections to IPv4
   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
   destination's IPv4 address as an IPv4-mapped IPv6 address, and
   passing that address, within a sockaddr_in6 structure, in the
   connect() or sendto() call.  When applications use PF_INET6 sockets
   to accept TCP connections from IPv4 nodes, or receive UDP packets
   from IPv4 nodes, the system returns the peer's address to the
   application in the accept(), recvfrom(), or getpeername() call using
   a sockaddr_in6 structure encoded this way.

   Few applications will likely need to know which type of node they are
   interoperating with.  However, for those applications that do need to
   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is

According to the SIP standard, there is no "transport=udp6". The values of "transport" are limited to "udp" and "tcp". So, that should explain that. 

The "Socket:" field listed by openserctl seems consistent. I couldn't find adequate documentation, but I would imagine that this field is saying the connection used by OpenSER to communicate with the client (rather than vice-versa). 

I am still confused by the fact that your client is not sending a REGISTER message when it signs-off. Could you explain a little more about this so I can help?


-----Original Message-----
From: CHEN XUEQIN [mailto:chenxq at star-net.cn]
Sent: Mon 9/24/2007 11:02 PM
To: Hawkins, William - AES
Cc: devel at pidgin.im
Subject: Re: why UDP6 when  I use SIMPLE protocol to login SIP proxy?
      Thanks for you attention about my questions.

Hawkins, William - AES ??:
> In reference to listening only on UDPv6 port 5060, I believe this is what the developers intended. The SIMPLE code calls purple_network_listen_range to open these ports. This function iterates through each port in that range with each available protocol. The function uses (on linux) getaddrinfo to create a list of protocols to try with each port. As soon as a port is open, the function returns.  It would appear that Linux favors UDPv6 over UDPv4 which leads to the behavior that you are seeing. 
> It is possible to "hint" to the getaddrinfo function that you want v4 addresses to have preference. However, that is something that the libpurple people (eaters) would have to address. 
> Please correct me if I am wrong in my interpretation of this code. 
> Thanks,
> Will
On the host where pidgin client running(yeah, it's my PC), pidgin always listen on sip port on udp6. I have done the following test, the configuration was:

    * Pidgin 2.2.0  run on Ubunut 7.04 , Arch: i386,  IP:
    * Openser run on CentOS 5.0, Arch: x86_64, IP:
    * Pigdin register to openser using account 8871 at

My test process was:

   1. Start openser in debug mode,  fork=no, listen=udp:

   2. Start pidgin, setup SIMPLE account, register to openser SIP server
   3. on pidgin host, netstat -aup | grep pidgin
      udp6       0      0 *:sip                  
      *:*                                17635/pidgin
      udp6       0      0 *:sip                  
      *:*                                17635/pidgin
      udp6       0      0  *:sip                  
      *:*                                17635/pidgin
   4. on openser Server, check user location info, run "openserctl ul
      show"        AOR:: 8871
                      Contact:: sip:8871 at;transport=udp Q=
                              Expires:: 569
                              Cseq:: 5
                              User-agent:: Purple/2.2.0
                              State:: CS_SYNC
                              Flags:: 0
                              Cflag:: 0
                              Socket:: udp:
                              Methods:: 1792
      The socket display is udp:, not
      udp6: Also, the contract transport is udp, not
   5. Send SIP message to other SIP client which was also registered to
      openser. Both sending and receiving message is ok.
   6. Quit pidgin client, check user location info again, run
      "openserctl ul show" . AOR:: 8871 was still there with no change
      comparing to step 4.

 From the above process, can I draw a  conclusion that actually pidgin 
is listen on sip port of udpv4 not udpv6. The output of " netstat -aup | 
grep pidgin" command is mistaken?  And pigdin did not send unregister 
request to SIP proxy when client quit.

Again, thanks for your reply.

Chen Xueqin

This e-mail and any files transmitted with it may be proprietary 
and are intended solely for the use of the individual or entity to 
whom they are addressed. If you have received this e-mail in 
error please notify the sender. Please note that any views or
opinions presented in this e-mail are solely those of the author 
and do not necessarily represent those of ITT Corporation. The 
recipient should check this e-mail and any attachments for the 
presence of viruses. ITT accepts no liability for any damage 
caused by any virus transmitted by this e-mail.

More information about the Devel mailing list