1 Dec
2006
1 Dec
'06
3:06 p.m.
Christophe Irles wrote:
Hi,
If a SIP device is using TCP, to accept incoming calls it must bind on port
5060.
No. If it is a server, it has to bind to the port announced in the SRV
records (of course 5060 is a good idea too).
If it is a client, it has to bind to the port announced in the Contact:
header of the REGISTER.
To call someone, this device must create a socket to
reach the proxy on port
5060. The port source of this socket cannot be 5060 ! In TCP you cannot bind
on a port and in same time using it in another socket. So the port source is
generally chosen randomly (XYZ)
Usually, the local port will be an ephemeral port.
But AFAIK it would also be possible to specify the local port which
should be used, although this is usually not used.
Now that all sockets and bind are done, what are the
correct info used to
create the Contact header ?
Example: client listens on tcp port 5060, and client created TCP
connection to server (for REGISTER) from port 4321.
The client can use port 5060. But this works only if the client is not
behind NAT.
The client can also use port 4321. In this case, the client has to
ensure that the TCP connection keeps established also after the
registration.
For me, the port used in the contact header in this
case must be 5060 since
the device accepts incoming calls on this port and never XYZ.
That is a bad implemented client. The client should also accept messages
on the TCP port XYZ. Which client do you use? minisip? It works with
minisip.
But in a NAT context, if this SIP device is behind a
NAT, the port 5060
cannot be used to reach it ! It's necessary to reuse the socket previously
opensed to reach it.
correct.
So in conclusion, the Contact header must be set with
5060 by the device and
if the client is behind NAT it is meaningless to put 5060 into the
contact header.
on the proxy side, if the client is detected behind a
NAT, this Contact
header is modified to used instead XYZ
There are 2 methods to handle this situation:
1. Either the client is intelligent (like eyebeam): Establish TCP
connection. Send REGISTER (contact includes local socket). Wait for 200
OK. Check rport and received parameter in Via header. If it is different
to the registered contact then unregister this contact and reregister
with the contact learned from the Via header. Of course the reregister
must be done in the same TCP connection. The client also sends keep
alive (CRLF) and if the TCP connection gets broken, the above process
restarts: new TCP connection, unregister old contact, register new
contact, learn from via header the public socket.
Although the client learned the public socket from Via header and uses
this socket in the Contact header, the Via header is always populated
with the local IP address.
The c= address in the SDP should be the public socket if STUN can be
used, or the public IP if STUN can't be used.
This way the proxy can detect if the cleint is behind NAT or NAT (e.g.
for forcing rtpproxy when the client is behind symmetric NAT).
2. The server makes the NAT traversal. This is the same as when using
UDP. fix_nated_register (for REGISTER),fix_nated_contact, and force_rport.
Am I right ?
Almost. I suggest to watch eyebeam's / x-lite 3.0 REGISTER when using
TCP. This helped me a lot. This is a real smart client.
For TLS, the problem is the same but instead of 5060 it's 5061.
yes.
regards
klaus
Thanks,
Christophe
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
Klaus Darilion
nic.at