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

[Ian Gilmour (JIRA)]

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

Ian Gilmour edited comment on ASTERISK-27070 at 6/28/17 7:39 AM:
-----------------------------------------------------------------

output.tgz contains the cli output from running a sipp test that runs 5 concurrent loopback calls through Asterisk 13.16.0 (with bundled pjsip) to the Echo service running on the same Asterisk. When 1 call terminates sipp initiates another call. Calls are of varying duration.

Test run with:
{noformat}
core set debug 5
core set verbose 5
pjsip set logger on
pjproject set log level 4
{noformat}

This test regularily fails due to another pjsip issue I've already raised [ASTERISK-27001]. When it does so Asterisk reregisters with the OpenSIPS server using a different local port (as expected) but for calls in progress during the reregistration it fails to send SIP re-invites to the callee(s).

output.tgz contains:
* asterisk-cli.txt - asterisk cli output.
* grep.txt - highlights when the port change occurs.
* netstat.txt - confirms when port change occurs.
* sipp.txt - sipp output showing 7 of the 44 loopback calls failed (some of these failures were due to missing SIP BYE's, etc. not reaching their intended destination for calls in progress during the port change).


was (Author: tuxian):
output.tgz contains the cli output from running a sipp test that runs 5 concurrent loopback calls through Asterisk 13.16.0 (with bundled pjsip) to the Echo service running on the same Asterisk. When 1 call terminates sipp initiates another call. Calls are of varying duration.

Test run with:
{noformat}
core set debug 5
core set verbose 5
pjsip set logger on
pjproject set debug level 4
{noformat}

This test regularily fails due to another pjsip issue I've already raised [ASTERISK-27001]. When it does so Asterisk reregisters with the OpenSIPS server using a different local port (as expected) but for calls in progress during the reregistration it fails to send SIP re-invites to the callee(s).

output.tgz contains:
* asterisk-cli.txt - asterisk cli output.
* grep.txt - highlights when the port change occurs.
* netstat.txt - confirms when port change occurs.
* sipp.txt - sipp output showing 7 of the 44 loopback calls failed (some of these failures were due to missing SIP BYE's, etc. not reaching their intended destination for calls in progress during the port change).

> 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: Unassigned
>         Attachments: output.tgz
>
>
> 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)