Summary:	ASTERISK-27070: res_pjsip: No SIP Re-INVITE on existing calls following reregistration on a different port
Reporter:	Ian Gilmour (tuxian)	Labels:
Date Opened:	2017-06-20 07:51:39	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Resources/res_pjsip
Versions:	13.15.0	Frequency of Occurrence
Related Issues:
Environment:	Centos 6.9 x64	Attachments:	( 0) output.tgz ( 1) pjsip-conf.tgz
Description:	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?
Comments:	By: Asterisk Team (asteriskteam) 2017-06-20 07:51:40.088-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2017-06-26 13:51:43.465-0500 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. By: Ian Gilmour (tuxian) 2017-06-28 07:37:22.390-0500 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). By: Rusty Newton (rnewton) 2017-07-01 13:06:39.717-0500 Ian, can you include a pcap of the same scenario as well as pjsip configuration? Thanks! By: Ian Gilmour (tuxian) 2017-07-03 09:20:46.441-0500 Hi Rusty, I've attached the PJSIP config as requested. But I'm not sure that a pcap would give any more info here - the SIP is TLS encrypted. The earlier Jira logs submitted already have the PJSIP traffic unencrypted in them. Is that not sufficient? If you're asking for a pcap because you are interested in what happens around a port change then there are a couple of pcap logs attached to ASTERISK-27001 showing that. My workaround patch on ASTERISK-27001 (which I accept isn't a finished solution), suggests this is likely due to a bug in the PJSIP TLS handling. On this particular Jira issue for my own clarification: *  Do we know if there is Asterisk/PJSIP code that is intended to send SIP RE-INVITE's in this call scenario? If someone can point me at the section of code that should be handling this I'm happy to investigate this further. * Or is this an edge case call scenario for which the Asterisk/PJSIP code does not yet exist in Asterisk or PJSIP? If you need this particular test repeated with a higher asterisk/pjproject logging levels please let me know. By: Joshua C. Colp (jcolp) 2017-07-03 09:44:51.543-0500 The functionality does not exist in either PJSIP itself or in chan_pjsip. By: Ian Gilmour (tuxian) 2017-07-04 02:41:00.387-0500 Hi Joshua - Thanks for the clarification. By: Ian Gilmour (tuxian) 2018-03-12 08:15:07.613-0500 Looking at https://trac.pjsip.org/repos/ticket/2041 it would appear that PJSIP (2.7+) does now include, some support for issuing SIP RE-INVITE's on an IP address/port change. So has Asterisk been modified to take advantage of this as yet? By: Joshua C. Colp (jcolp) 2018-03-12 08:33:48.833-0500 That code is in regards to pjsua, which is a client API that Asterisk does not use. It is not applicable. As there are no comments on here stating that someone is working on this there has been no progress as far as I am aware. By: Ian Gilmour (tuxian) 2018-03-12 11:08:09.303-0500 Hi Joshua, again thanks for the quick response and clarification. Earlier you said that "The functionality does not exist in either PJSIP itself or in chan_pjsip." Given that PJSIP now does support this functionality (albeit with an API that Asterisk doesn't use), am I correct in assuming that this missing functionality is now solely an Asterisk (chan_pjsip) issue? By: Joshua C. Colp (jcolp) 2018-03-12 11:09:38.405-0500 It always was a chan_pjsip issue. It's a low level thing that has to be implemented by the higher level consumer (Asterisk) to really do.