Summary:	ASTERISK-28878: chan_pjsip: PJSIP_MEDIA_OFFER Broken asterisk 16
Reporter:	Joseph Ades (jades)	Labels:
Date Opened:	2020-05-07 21:09:28	Date Closed:	2020-08-24 17:20:15
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_pjsip
Versions:	16.4.0 16.10.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) asterisk13-Working.pcap ( 1) asterisk13-working.txt ( 2) asterisk16-12-notworking.txt ( 3) asterisk16-NOT-WORKING.pcap ( 4) Code.txt ( 5) verbose13.txt ( 6) verbose16.txt
Description:	I am migrating from asterisk 13 and have successfully utilized the pjsip_media_offer function. Very simple code, not much else to it, and worked for years. https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Function_PJSIP_MEDIA_OFFER After testing an asterisk 16 machine, using exactly the same code, I am unable to get it to work. The CLI reads the code, but does not do anything with it. Furthermore, after analyzing the packet capture, there is no evidence of the asterisk machine sending an INVITE to renegotiate the codec. I downgraded back to asterisk 13 and everything started to work again
Comments:	By: Asterisk Team (asteriskteam) 2020-05-07 21:09:29.298-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]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Joshua C. Colp (jcolp) 2020-05-08 03:50:34.209-0500 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected and the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information In this case the precise configuration, dialplan logic, SIP trace, and console log. By: Joseph Ades (jades) 2020-05-08 10:16:55.033-0500 My apologies. The steps or actions was simply dialing the appropriate extension number with the below code. The behavior expected was for both endpoints to force to codec g722. I also attached a PCAP from asterisk 13 where this works, and a PCAP from asterisk 16 where it's broken Code (see attached - Code.txt. I did not know how to format here): CLI Verbose on Asterisk 16 where this is not working. Neither of the endpoints were asked to change codecs: (see attached - verbose16.txt) CLI verbose on Asterisk 13 where this is working as expected. Same code. Both endpoints were forced to codec g722. (see attached - verbose13.txt) I would also like to point out that the asterisk 16 test was on 16.4.0. I also tried with 16.10 (latest) and experienced the same result. By: Joshua C. Colp (jcolp) 2020-05-11 04:17:12.421-0500 If you try this in an earlier version, such as 16.7.0, does it work as expected there? By: Joseph Ades (jades) 2020-05-11 06:35:06.100-0500 I already tried on 16.4.0 and 16.10.0 and experienced the same result. Would you like me to try it on 16.7 or not necessary anymore? By: Joshua C. Colp (jcolp) 2020-05-11 06:57:50.863-0500 16.4.0 is old enough for checking. By: Kevin Harwell (kharwell) 2020-06-24 11:13:56.170-0500 [~jades] What version of 13 did you test this on? By: Joseph Ades (jades) 2020-06-24 17:00:56.200-0500 Currently I have 13.23.1 in production and am not having issues. I've previously used 13.22, and over the last 3 years I used few other earlier 13 versions that I cannot recall their exact version number, and did not experience any issues whatsoever. By: Kevin Harwell (kharwell) 2020-06-24 17:11:21.147-0500 For the configured endpoint(s) (13 and 16) what codecs are enabled (i.e. allow=)? By: Joseph Ades (jades) 2020-06-24 17:13:50.326-0500 opus, ulaw, g722, g729 By: Friendly Automation (friendly-automation) 2020-07-06 09:07:37.302-0500 Change 14619 merged by Friendly Automation: PJSIP_MEDIA_OFFER: override configuration on refresh [https://gerrit.asterisk.org/c/asterisk/+/14619|https://gerrit.asterisk.org/c/asterisk/+/14619] By: Friendly Automation (friendly-automation) 2020-07-06 09:08:10.953-0500 Change 14623 merged by Friendly Automation: PJSIP_MEDIA_OFFER: override configuration on refresh [https://gerrit.asterisk.org/c/asterisk/+/14623|https://gerrit.asterisk.org/c/asterisk/+/14623] By: Friendly Automation (friendly-automation) 2020-07-06 10:51:56.468-0500 Change 14622 merged by Joshua Colp: PJSIP_MEDIA_OFFER: override what's specified on configuration [https://gerrit.asterisk.org/c/asterisk/+/14622|https://gerrit.asterisk.org/c/asterisk/+/14622] By: Friendly Automation (friendly-automation) 2020-07-06 10:52:54.390-0500 Change 14618 merged by Joshua Colp: PJSIP_MEDIA_OFFER: override configuration on refresh [https://gerrit.asterisk.org/c/asterisk/+/14618|https://gerrit.asterisk.org/c/asterisk/+/14618] By: Joseph Ades (jades) 2020-08-12 16:46:15.072-0500 This issue is still not resolved. Compared asterisk 13.35 against asterisk 16.12 (and verified that the dialplan_functions.c and res_pjsip_session.c contain the updated information) and we are still not getting an invite to refresh the codecs. Attached two comparisons from my latest testing. I also checked into the asterisk 13 dialplan_functions.s and res_pjsip_session.c files and I do not see that they contain the contents from asterisk 16 patch file. Is it possible that there is additional work needed to patch this issue? By: Asterisk Team (asteriskteam) 2020-08-12 16:46:15.613-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Kevin Harwell (kharwell) 2020-08-12 17:43:47.324-0500 Hrm odd! The patches between 13 and 16 are slightly different due to other changes between 13 and 16, so they are not the same. How are you testing? Did you download and apply the patch, or download the 16.12 tarball? If the former did you do the following after applying the patch (or similar): {noformat} $ make $ make install {noformat} And then restarted Asterisk? By: Joseph Ades (jades) 2020-08-12 18:20:46.595-0500 I downloaded the 16.12 tarball and yes, configure / make / make install On that very same system I installed asterisk 13.35 just to test and make sure I didn't do anything wrong, and indeed it worked on first try with asterisk 13. So I have reason to believe that the patch was not implemented correctly. Please let me know next steps from here. By: Kevin Harwell (kharwell) 2020-08-18 17:40:11.140-0500 I'm going to look more into this, but I believe the initial patch missed a use case. By: Kevin Harwell (kharwell) 2020-08-24 14:08:54.297-0500 After some more investigation it doesn't appear the use case of attempting to send a session refresh before a call has been answered has ever been supported, and if so it shouldn't have been. So for instance, {noformat} [from-jc-custom] exten => _2XX,1,Set(PJSIP_MEDIA_OFFER(audio)=!all,g722) exten => _2XX,n,Set(PJSIP_SEND_SESSION_REFRESH()=invite) exten => _2XX,n,Dial(PJSIP/525${EXTEN},,b(gosub-jc-custom^s^1)) exten => _2XX,n,Hangup() [gosub-jc-custom] exten => s,1,Set(PJSIP_MEDIA_OFFER(audio)=!all,g722) exten => s,n,Set(PJSIP_SEND_SESSION_REFRESH()=invite) exten => s,n,Return() {noformat} In both of these cases a session refresh is attempted on channels (caller and callee) prior to the call, and associated sessions, being fully setup and established. It's actually a bug that Asterisk attempts to do anything at all in that case. Instead the PJSIP_SEND_SESSION_REFRESH function should fail and return an error. If you want to update the codecs, and re-invite then you'll have to do that after answer. By: Joseph Ades (jades) 2020-08-24 14:58:35.421-0500 If you can provide an appropriate dialplan example it would be appreciated, as it appears that an asterisk technician named jcolp contradicted what you stated, and suggests that this should indeed be set as a pre dial handler. Please reference his post: https://community.asterisk.org/t/pjsip-migration-sip-codec-and-sip-codec-outbound/73342/9 By: Joshua C. Colp (jcolp) 2020-08-24 15:16:18.110-0500 I was referring to the use of PJSIP_MEDIA_OFFER, as it was written for pre-dial usage. I didn't give any thought to the session refresh within that context. By: Joseph Ades (jades) 2020-08-24 15:30:49.784-0500 Not an issue. Please provide the appropriate testing method. There is nothing in the documentation/wiki that states how to properly test. To me it makes no difference if a session refresh is sent before or after the call is established. At this point I want to make it work correctly. Thanks By: Kevin Harwell (kharwell) 2020-08-24 16:08:39.658-0500 [~jades] I think maybe part of the confusion comes in in that there are two dialplan functions being used in this scenario. From the [PJSIP_MEDIA_OFFER|https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Function_PJSIP_MEDIA_OFFER] description: {quote} Media and codec offerings to be set on an outbound SIP channel prior to dialing. {quote} Typically, and in order to achieve the described behavior this function is used in a [pre-dial handler|https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers]. For example: {noformat} [from-jc-custom] exten => _2XX,1,NoOp() exten => _2XX,n,Dial(PJSIP/525${EXTEN},,b(gosub-jc-custom^s^1)) exten => _2XX,n,Hangup() [gosub-jc-custom] exten => s,1,Set(PJSIP_MEDIA_OFFER(audio)=!all,g722) exten => s,n,Return() {noformat} The above dialplan will "override" whatever is configured for endpoint 525, and use g722 in the offer when dialing the "outbound" channel. The second function being used is [PJSIP_SEND_SESSION_REFRESH|https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Function_PJSIP_SEND_SESSION_REFRESH]. From its description: {quote} Initiate a session refresh via an UPDATE or re-INVITE on an established media session {quote} _Established media session_ is the key phrase there. A simple example of that would be after Asterisk answers: {noformat} [from-jc-custom] exten => _2XX,1,NoOp() exten => _2XX,n,Answer() exten => _2XX,n,Set(PJSIP_SEND_SESSION_REFRESH()=invite) exten => _2XX,1,Playback(hello-world) ; Do something here exten => _2XX,n,Hangup() {noformat} That dialplan will cause Asterisk to answer the incoming channel (establish the media session), and then send a session refresh (re-invite) back out to the caller. Now you can combine the the two functions to make it so before sending out the re-invite the media being offered is also updated: {noformat} [from-jc-custom] exten => _2XX,1,NoOp() exten => _2XX,n,Answer() exten => _2XX,n,Set(PJSIP_MEDIA_OFFER(audio)=!all,g722) exten => _2XX,n,Set(PJSIP_SEND_SESSION_REFRESH()=invite) exten => _2XX,1,Playback(hello-world) ; Do something here exten => _2XX,n,Hangup() {noformat} Things get a little more tricky if you'd like to be able to refresh the session post [Dial|https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_Dial]. You'll either need to use some post dial handler mechanism (not sure a good one exists for that), or use some combination of Dial, [Local Channels|https://wiki.asterisk.org/wiki/display/AST/Local+Channel], [Originate|https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_Originate], and/or [Bridge|https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_Bridge]. Hope that helps. By: Joseph Ades (jades) 2020-08-24 17:20:09.445-0500 Thank you, yes, at this point you can close the ticket. A quick test proved that it is now functional. By: Kevin Harwell (kharwell) 2020-08-24 17:32:47.969-0500 No problem, and glad you were able to get it working. --I'm going to leave this open for the moment as-- I've created another [patch|https://gerrit.asterisk.org/c/asterisk/+/14809] against this issue that will make it so a warning is now emitted, and the PJSIP_SEND_SESSION_REFRESH dialplan function will return unsuccessful if an attempt is made to use it prior to a channel being "answered". [~kharwell] edit - was already closed :-) By: Friendly Automation (friendly-automation) 2020-08-28 12:25:32.078-0500 Change 14787 merged by Friendly Automation: chan_pjsip: disallow PJSIP_SEND_SESSION_REFRESH pre-answer execution [https://gerrit.asterisk.org/c/asterisk/+/14787|https://gerrit.asterisk.org/c/asterisk/+/14787] By: Friendly Automation (friendly-automation) 2020-08-28 12:58:20.410-0500 Change 14809 merged by Friendly Automation: chan_pjsip: disallow PJSIP_SEND_SESSION_REFRESH pre-answer execution [https://gerrit.asterisk.org/c/asterisk/+/14809|https://gerrit.asterisk.org/c/asterisk/+/14809] By: Friendly Automation (friendly-automation) 2020-08-28 13:03:03.039-0500 Change 14788 merged by Friendly Automation: chan_pjsip: disallow PJSIP_SEND_SESSION_REFRESH pre-answer execution [https://gerrit.asterisk.org/c/asterisk/+/14788|https://gerrit.asterisk.org/c/asterisk/+/14788] By: Friendly Automation (friendly-automation) 2020-08-28 13:11:31.937-0500 Change 14789 merged by Friendly Automation: chan_pjsip: disallow PJSIP_SEND_SESSION_REFRESH pre-answer execution [https://gerrit.asterisk.org/c/asterisk/+/14789|https://gerrit.asterisk.org/c/asterisk/+/14789] By: Friendly Automation (friendly-automation) 2020-08-28 13:23:09.374-0500 Change 14790 merged by Kevin Harwell: chan_pjsip: disallow PJSIP_SEND_SESSION_REFRESH pre-answer execution [https://gerrit.asterisk.org/c/asterisk/+/14790|https://gerrit.asterisk.org/c/asterisk/+/14790]