[asterisk-bugs] [JIRA] (ASTERISK-27070) No SIP Re-INVITE on existing calls following reregistration on a different port

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-27070:
------------------------------------

    Assignee: Ian Gilmour
      Status: Waiting for Feedback  (was: Triage)

I think your observation is correct and that we should be re-inviting in that scenario, based on what I'm reading. Though it'll take someone more familiar with PJSIP perhaps to look into it.

Can you provide debug logs including pjsip traces, similar to what you did in ASTERISK-27001 ?

Turn up Asterisk debug and verbose both to 5 if possible.

> No SIP Re-INVITE on existing calls following reregistration on a different port
> -------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27070
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27070
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.15.0
>         Environment: Centos 6.9 x64
>            Reporter: Ian Gilmour
>            Assignee: Ian Gilmour
>
> I have a development Asterisk 13.16.0 test setup (uses the bundled pjsip-2.6).
> On startup Asterisk registers 1 Asterisk users with a remote OpenSIPS server over TLS, using the PJSIP stack. As part of the test this Asterisk PJSIP user is reregistered with OpenSIPS Server every couple of mins.
> Asterisk runs behind a NAT and the normal Asterisk TLS listening port is inaccessible from the OpenSIPS server side. So all SIP call traffic flows down the TLS connection opened during registration.
> Occassionally I see PJSIP close and reopen the TLS connection (see ASTERISK-27001 for more info on that particular issue). When it reopens (as expected) it uses a different local TCP port to make the connection and any new SIP calls are made down this new connection. All good so far.
> But if the TLS connection close/open happens when calls are in progress then any future SIP traffic related to these 'in-progress' calls (i.e. SIP UPDATE/ BYE/ INFO/ etc.) from the remote endpoints is lost because the TCP port has changed and Asterisk has not informed the other endpoint of the change. The remote endpoint continues sending call traffic to the now closed port.
> Throughout the SIP reregistration the UDP media flow for these 'in-progress' calls continues to flow ok. But remote sip call packets for these calls (sip bye/info/update/etc.) are no longer received at the Asterisk end.
> Looking at RFC3665 section 3.7 (https://tools.ietf.org/html/rfc3665#section-3.7) it looks like Asterisk should be issuing SIP Re-INVITE for any existing calls, and it doesn't.
> Or is this scenario handled some other way?



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