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:
::FFFF:<IPv4-address>
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
provided."
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?
Thanks!
Will
-----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?
Hawkins:
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: 192.168.35.40
* Openser run on CentOS 5.0, Arch: x86_64, IP: 192.168.35.245
* Pigdin register to openser using account 8871 at 192.168.35.245
My test process was:
1. Start openser in debug mode, fork=no, listen=udp:192.168.35.245:5060
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 192.168.35.40:5060;transport=udp Q=
Expires:: 569
Callid::
7F25g28F1a4883i2391m2498tDEDDbCD34x2F88x
Cseq:: 5
User-agent:: Purple/2.2.0
State:: CS_SYNC
Flags:: 0
Cflag:: 0
Socket:: udp:192.168.35.245:5060
Methods:: 1792
The socket display is udp:192.168.35.245:5060, not
udp6:192.168.35.245:5060. Also, the contract transport is udp, not
udp6.
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.
Regards,
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