asterisk users - Dec 2019 - SIP via TCP - new TCP session per call or use same session for multiple calls?

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
______________________________________________________

Zurlindenstrasse 29             Tel  +41 61 826 93 00
CH-4133 Pratteln                Fax  +41 61 826 93 01
Schweiz                         Web  http://www.imp.ch
______________________________________________________

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.



On Fri, Dec 27, 2019 at 10:41 AM Benoit Panizzon <benoit.panizzon at
imp.ch>
wrote:
> 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
> ______________________________________________________
>
> Zurlindenstrasse 29             Tel  +41 61 826 93 00
> CH-4133 Pratteln                Fax  +41 61 826 93 01
> Schweiz                         Web  http://www.imp.ch
> ______________________________________________________
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>       https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20191227/47ab02e8/attachment.html>

Dovid Bender <dovid at telecurve.com> writes:
> 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.
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...