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

Mon Nov 5 08:42:21 CST 2012

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

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

Hi, replying to all comments:

> For scenario's where there was a proxy, but not a record-route, it'd be even more wrong to reuse the connection. You want the in-dialog request to do to the Contact.

Sure, but if the proxy didn't add Record-Route then Asterisk may not be able to detect whether it is a proxy or not (it could inspect the number of Via headers...). Anyhow if there is no Record-Route IMHO the behavior should be (IMHO) what you suggest:

* if nat=someyes then reuse
* else open new connection

> Asterisk's behavior may not be "correct" (although like Walter, I haven't found the language in RFC 3261 that explicitly forbids it - but I could certainly be missing it)

If there are two RFC's (RFC 5626 and 5923) for allowing reusing a remotely initiated connection IMHO it's clear that this behavior is not allowed by RFC 3261. Please read section 1 "Introduction" in RFC 5923:

{quote}
   The SIP protocol includes the notion of a persistent connection
   (defined in Section 2), which is a mechanisms to insure that
   responses to a request reuse the existing connection that is
   typically still available, as well as reusing the existing
   connections for other requests sent by the originator of the
   connection.  However, new requests sent in the backwards direction
   are unlikely to reuse the existing connection.  This frequently
   causes a pair of SIP entities to use one connection for requests
   sent in each direction.

   Unlike TCP, TLS connections can be reused to send requests in the
   backwards direction since each end can be authenticated when the
   connection is initially set up.
{quote}

> For what devices and/or scenarios is the current behavior detrimental?

Well, for phones that directly connect to Asterisk there will be no problem or regression since there won't be Record-Route and thus Asterisk will behave as now (always reuse the connection initiated by the peer). Anyhow this is not correct and should be seteable via "nat" value(s) for that peer. If for example "nat=no/never" and the peer is a phone or server (not a proxy) then Asterisk should not reuse the connection but instead open a new one against the Contact URI hostport.

But there are proxies and servers that open an outgoing TCP connection (i.e. against Asterisk) and will not mantain that connection open all the time (they will close it after N minutes of inactivity, for example). Imagine that a proxy opens a connection with Asterisk, Asterisk receives an INVITE, dialog is established and takes more than 3 hours (no in-dialog requests in those 3 hours). The proxy will probably close that connection. Now leg B in Asterisk receives a BYE, will Asterisk fail to send it because the connection was closed "by peer A"? That's not correct. Asterisk should open a connection to the top Route URI regardless the connection is open or not (if "nat" != "no" / "never").

Phones instead are typically coded for mantaining outgoing TCP connections all the time (they "implement" something like RFC 5626 "Outbound" before such an RFC exists) because they expect to receive incoming requests over that connection (otherwise no way to work under NAT scenarios).

So maybe there could be a new SIP parameter "reuse_connection" (seteable for each peer), with "yes" as default value. If it's set to "no" and the peer establishes a TCP/TLS connection with Asterisk, then when Asterisk must send an in-dialog request to the peer:

- If there is Route header then open a new connection against the URI in the top Route.
- If not, open a new connection against the URI in the Request-URI (the value of the Contact URI in the received INVITE).

PS: And hopefuly, this will be also implemented when Asterisk supports Path ("RFC 3327") so a phone can send a REGISTER via a Proxy, the Proxy adds "Path" header, routes it to Asterisk (registrar server) and when Asterisk sends an initial INVITE to that peer it adds Route header with the value(s) of the Path header and follows same behaviour as described above (i.e. based on "reuse_connection" SIP peer parameter).

> 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
>
> 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