SIP Via TCP – New TCP Session Per Call Or Use Same Session For Multiple Calls?

Home » Asterisk Users » SIP Via TCP – New TCP Session Per Call Or Use Same Session For Multiple Calls?
Asterisk Users 4 Comments

Hi List

I wonder how SIP via TCP is supposed to work. Not realy Asterisk related, but I hope you experts might be able to help out 🙂

One of our customers has a SIP device registering via a complex NAT. To benefit from TCP Connection Tracking, he choose TCP instead of UDP.

So he expected, that an incoming call would be sent back to him on the already open TCP connection, making it easy to get through that NAT.

This is not the case. Our SBC is attempting to initiate a new SIP TCP
connection towards the NAT Firewall of the customer thus getting dropped because this is not the outgoing established connection opened during the registration.

So, how should SIP via TCP work? Should one TCP session be used for all signaling of potentially multiple concurrent calls, as expected by our customer. Or is it usual to make one TCP session per call as observed?

Mit freundlichen Grüssen

-Benoît Panizzon-
—
I m p r o W a r e A G – Leiter Commerce Kunden

4 thoughts on - SIP Via TCP – New TCP Session Per Call Or Use Same Session For Multiple Calls?

  • So long as the tcp socket is open your SBC should send the call back over the same socket. Now it can be that your SBC is seeing the socket as timing out. If you are using Kamailio you can have it send tcp keep alives every so often so that the socket stays up.

  • Dovid Bender writes:

    SBC?

    I am curious if the “reuse registration TCP connection” is required by standards or if it is merely obviously good practice.

    I have had this problem too with asterisk 16.5.0

    This is not the first recommendation I have seen to use kamailio as a proxy for asterisk, for these sorts of issues as well as clients that change addresses. Unfortunately the “jsr pc, set_up_kamailo” subroutine call is still executing so I can’t say if things work right then…

    —

  • There is a specification for doing it, but it’s not required by the main SIP RFC. In fact the main one states that you’re supposed to establish an outgoing connection to the address in the Contact header. In practice, though, this is futile as generally NAT Is in use so you can’t connect back and thus you reuse the connection. The chan_sip module should do this automatically, while chan_pjsip will do this if “rewrite_contact” is set to yes.

  • “Joshua C. Colp” writes:

    Thanks. I read the docs for pjsip (and the book) and failed to grasp that. It seems that this should be the default behavior.

    —