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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users