[asterisk-bugs] [JIRA] (ASTERISK-27147) Either asterisk or pjproject isn't re-using tcp connections (again)

[Richard Mudgett (JIRA)]

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

Richard Mudgett commented on ASTERISK-27147:
--------------------------------------------

The connections are being reused.  We're just not telling the other side the right contact address and port for there to be only one connection.  When Asterisk A registers with Asterisk B then the connection on A is IP-A:random-port (say port 56789) to IP-B:5060.  Asterisk A says contact it at IP-A:5060.  So when B wants to send A a call, it has no connection to A at IP-A:5060.  It does have one for IP-A:56789 but it wasn't told to use that address as a contact address.  When A responds to the INVITE it sends the responses over the incoming transport.  When A later sends a request to B (say a COLP UPDATE), it uses B's contact address which is IP-B:5060.  Asterisk A does find such a connection created by the registration and uses it.  However, this isn't the connection that B sent the original INVITE over.  This call is now using two different connections.  I'd think that if A had registered with a contact address of IP-A:56789 then B would use that existing connection and then there would be only one connection being used.

With rewrite_contact enabled only on A's side, when A sends the UPDATE request in the scenario above, it sends the UPDATE to the source address of the connection created by the incoming INVITE instead of where the contact header stated.  The register connection isn't used for the call.

With rewrite_contact enabled only on B's side, the above scenario only uses one connection and B doesn't create a new connection.

The rewrite_contact option is intended for B's server side situation.  However, it does have some potential benefit on A's client side situation.  The benefit is if B initiates a call with A because B doesn't have the rewrite_contact functionality or its not enabled.  Asterisk A will reuse the connection established by the incoming call for the duration of the call.

A problem does crop up on B's side with rewrite_contact enabled.  If the TCP connection gets disconnected or if B is restarted then the rewritten register contact for A is now invalid and won't go away until it expires.  If B tries to send a call to A using the invalid connection then A is not likely to see the request.  Asterisk A either won't be listening on that port for new connections or a NAT/firewall will block it.

A problem also crops up on A's side when the TCP connection gets disconnected.  Now A cannot receive incoming calls from B until it normally attempts to re-register.  If B also has max_contacts=1 set and remove_existing=no then the invalid register contact on B will cause A's register attempts to be rejected.  Asterisk A may give up registration attempts until manually prodded to resume.


> Either asterisk or pjproject isn't re-using tcp connections (again)
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-27147
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27147
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 13.17.0, 14.6.0, GIT
>            Reporter: George Joseph
>            Assignee: Richard Mudgett
>         Attachments: client_pjsip.conf, client_pjsip_wizard.conf, server_pjsip.conf, server_pjsip_wizard.conf
>
>
> Last year we submitted patches to pjproject to fix not re-using tcp connections.  It looks like it's broke again.
> Asterisk A and B have a "trunk" between them.  A registers to B.
> After A registers, there is 1 open TCP connection between them.
> B sends a call to A.
> Instead of re-using the existing connection, B establishes a new cconnection back to A.
> Now there are 2 tcp connections open.
> If A were behind a firewall that didn't allow inbound new connections, there'd be an issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)