[asterisk-bugs] [JIRA] (ASTERISK-20644) Don't always use the existing TCP connection for in-dialog requests

[Iñaki Baz Castillo (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199241#comment-199241 ] 

Iñaki Baz Castillo commented on ASTERISK-20644:
-----------------------------------------------

Another comment for defending the need of this "feature" or fix:

Let's assume that Asterisk XX supports Path.

* Clients send REGISTER to a Proxy (via UDP, TCP, TLS, WS or whatever transport).
* The Proxy adds Path header and routes the REGISTER requests to Asterisk using TCP transport.
* Now imagine that Asterisk does not implement the requested feature in this issue.
* Asterisk is restarted (for any reason).
* Now what, all the registrations are lost? Even worse, clients have no way to detect it, and the Proxy is a proxy, it cannot "resend" the REGISTER requests.

But if the current issue is fixed and the Proxy peer is configured with "reuse_connection=no" (or maybe "nat=comedia,rport,no_reuse_conn") then Asterisk will open a TCP connection to the Proxy when sending an INVITE to any registered user, so things would work even if Asterisk is restarted.

Please, give importance to this issue. With the incoming WebRTC world, INVITE requests may not fit into a UDP datagram (ICE, audio, video in the SDP...) and thus TCP becomes a real need. It must work properly.
                
> Don't always use the existing TCP connection for in-dialog requests
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-20644
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20644
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability, Channels/chan_sip/TCP-TLS
>    Affects Versions: 11.0.0
>            Reporter: Iñaki Baz Castillo
>      Target Release: 12
>
>
> If Asterisk receives an INVITE via TCP comming from a SIP proxy, answers the call and later Asterisk sends a re-INVITE or BYE for that dialog, Asterisk sends such an in-dialog request over the existing TCP connection previously opened by the SIP proxy. This is incorrect. Asterisk should open a NEW TCP connection to the address given in the top Record-Route header.
> So for example, Asterisk receives the following INVITE from TCP 1.2.3.4 port 8888:
> {code}
> # TCP 1.2.3.4:8888 => ASTERISK:5060
> INVITE sip:test at domain.com SIP/2.0
> Record-Route: <sip:1.2.3.4:5060;transport=tcp>
> {code}
> When Asterisk sends a BYE or a re-INVITE in this leg, it MUST respect the address in the top Route of the BYE or re-INVITE, which is: TCP 1.2.3.4 port 5060. So it should send the BYE to:
> {code}
> # TCP ASTERISK:5060 => 1.2.3.4:5060
> BYE sip:abc at 9.8.7.6 SIP/2.0
> Route: <sip:1.2.3.4:5060;transport=tcp>
> {code}
> This is something really basic in RFC 3261 and mandatory. Asterisk could use the existing TCP connection just in case nat=yes (or some other new values I don't fully know in the latest version), but by default, if "nat" parameter is not set for the Proxy peer, please DON'T reuse the existing TCP connection because that is a violation of RFC 3261.
> In fact, it's perfectly legal for a SIP proxy or SIP server to refuse/reject SIP requests coming from a TCP connection that the proxy/server itself opened against a remote proxy/server. These are RFC 3261 rules, really.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira