Summary:	ASTERISK-28821: a code change to chan_pjsip breaks SIP/ISUP internetworking in early state
Reporter:	Abdul Karim Barbour (NUCLEAR-WAR)	Labels:
Date Opened:	2020-04-10 13:41:59	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	Channels/chan_pjsip
Versions:	16.5.0 17.3.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) Asterisk-badcode-corrected.pdf
Description:	Commit ID .for this change : I7450b751083ec30d68d6abffe922215a15ae5a73 underlying Ticket ID : ASTERISK-27994 the colleague add wrong change to code which breaks SIP/ISUP Interoperability, hence goes against 3GPP TS 29.163 for what the MGCF expects, in case the support of the RFC 5009 P-Early-Media Extension in the provider's Network is mandatory ( e.g. most of the Providers in Germany). what happens is : the 183 will be marked with P-Early-Media=Inactive as the Network is not trusting media from the PBX, at 183 the O-MGCF will signals first ACM message with User indication Field set to : no indication, and optional Inband information also set to none, here if the caller coming from Legacy Network he will hear silence, as the O-MGCF here is still expecting 180 to signal ACM Message with Subscriber Free and start to generate Ring tones, MGCF only signals that when 180 been received, refer to the 3GPP TS 29.163 before doing such like this changes. To solve the SDP with 180, he needs to set the dialog to reliable i.e. set Require header to : 100rel, this can be done in the pjsip config by setting the vale of 100rel=required, without that Asterisk will keep sending 18x with SDP as they are NOT final answers, which is normal and expected, not sure why he consider it as final answer, only side effect is , the INVITE will be sent with Require 100rel (according to RFC its normal), its not on all devices welcomed, he must refer to the RFC related to "the Reliability of Provisional Responses in the Session Initiation Protocol" RFC3262 please revert this change, and if 183 need to be used, then activate the option inbandprogress=yes I hope i was able to explain the issue. Thanks in advance
Comments:	By: Asterisk Team (asteriskteam) 2020-04-10 13:42:00.892-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: George Joseph (gjoseph) 2020-04-10 13:51:54.911-0500 Thanks for the issue!  We're going to have to think about this one a bit. [~alexei gradinari] Can you comment on your original change? By: Alexei Gradinari (alexei gradinari) 2020-04-10 17:04:40.288-0500 Sorry, but I don't understand the issue. As I know asterisk doesn't support SIP-I/SIP-T. Could you, please, explain how you integrated SIP/ISUP with asterisk. I couldn't find any usage of P-Early-Media in asterisk code. By: Abdul Karim Barbour (NUCLEAR-WAR) 2020-04-11 05:46:16.459-0500 Hi Alexei, you don't need to integrate anything its just the normal setup, and the calling user is coming from legacy network to the PBX. in basic its as follows : I call the PBX from a cellphone or a PSTN/ISDN Phone, i set the dial plan so send first Progress and then Ringing, you can also have that in call forwarding for example, i have lot of such like those scenarios also with SIP Devices hanging to the IMS Core. First Asterisk will send 183 then he spouses to send 180, but after the code has been changed is is sending again 183, and will never send 180, this will not trigger ACM message with the User Indication Feld set to Subscriber Free, that means that the MGCF still waits for a 180 to send Alerting (BICC based) or ACM(ISUP based) Subscriber Free and start generate Ring tones ( when media is not authorized MGW will be told to generate the tones, if media authorized it will use the remote media), refer to 3GPP TS 29.163 Chapter 7.2.3.2.4 and 7.2.3.2.5, here you will find more info about how the O-MGCF react to the 180 and 183 respectively, where the Provider support for the P-Early-Media is mandatory, even if Asterisk is not supporting it, as this needed to Authorize/de-Authorize Media in early State, as here Asterisk is not trusted for Early Media in the IMS Core, i can provide you with call flows, but i think the one in the TS is more than sufficient. The other thing is, that in the Old Ticket, the unreliable respond considered as final Answer, which is not correct, and what Astrisk was doing by sending SDP in every 18x message was correct behavior and not bad at all, the User need to switch to reliabel mode as those SDPs are NOT Final Answer, its considered Final if its been sent reliably i.e. the 18x messeges have the Header Require set to 100rel, here Asterisk will send the SDP only one time here you can Refer to the RFC 3262, this can be done in the pjsip.conf file by setting the Option 100rel=required, without the need to change the code, as i mention the only side effect that he will have in the INVITE will have the require header also, not welcomed from some devices but its also OK, perhaps could be also improved to not send it in the INVITE. in our Deutsche Telekom 1TR114 document, we provide a Table for easy understanding on what a Device expected to do when specfic SIP Message come to it in our IMS Core based on the 3GPP TS. I hope i was able to explain the issue to you. Best regards Barbour References : 3GPP TS 29.163 Technical Specification Group Core Network and Terminals; Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks (Release 16) IETF RFC 3262 Reliability of Provisional Responses in the Session Initiation Protocol (SIP) 1TR114 Technical Technical Specification of the SIP (Gm) interface between the User Equipment (UE) and the IMS platform of Deutsche Telekom Chapter 4.2.6 Early Media and Early Dialogs By: Abdul Karim Barbour (NUCLEAR-WAR) 2020-04-11 06:29:27.536-0500 here is a call flow maybe it will help more By: Alexei Gradinari (alexei gradinari) 2020-04-11 10:27:04.603-0500 According to "Optional Case : where Astrisks ends P-Early-Media, improvment suggestion" don't you think that the "Core" should add P-Early-Media on 183 reply to MGCF that  "in case the support of the RFC 5009 P-Early-Media Extension in the provider's Network is mandatory" ? By: Alexei Gradinari (alexei gradinari) 2020-04-11 10:58:48.008-0500 On provided SIP flow I see incompatible because of missing P-Early-Media on 183 reply. If you want the asterisk to add P-Early-Media you should make a patch to support of RFC 5009. Keep in mind that the asterisk does not support SIP/ISUP. There are 2 ways to interconnect the asterisk with SIP/ISUP network: 1. Add SIP-T/SIP-I support to asterisk. 2. Use SIP proxy which support SIP-T/SIP-I between the asterisk and SIP/ISUP network. By: Abdul Karim Barbour (NUCLEAR-WAR) 2020-04-11 13:53:48.803-0500 H Alexei, its just a basic call to the SIP Trunk over the Provider, there is not integration to any ISUP Network. Asterisk is registered to the Provider and able to receive calls over IP Network ( IMS based network) Asterisk is being called from a user in the Network ( outside Astrisk) i.e. Terminating a call to the Trunk This user is coming to the Provider's Network from a legacy network over MGCF, which is located in the Provider's IMS Core, and does not belong to Asterisk in anyway, Asterisk work here in SIP-Trunk Mode with the Provider. Asterisk is sending SIP Messages to the Provider's network, which are delivered to the MGCF, which do the mapping of SIP to ISUP, Asterisk has nothing to do with mapping to ISUP, the problem is with the SIP messages that been sent from Asterisk. What happend is, when Asterisk sends 183 to network the network then hand this message to MGCF, then the MGCF maps the SIP 183 to ACM message according to the ACM Coding described  in the 3GPP TS 29.163 in chapter 7.2.3.2.5, here is what had been written : 7.2.3.2.5.1 Backward call indicators bits DC Called party's status indicator 01 subscriber free if the 180 Ringing has been received. as we have here only the 183, the Subscriber Free Flag will not be transmitted in the ACM, that cause, that the calling user hear silence, no ring tone will be played locally. this also applies to the SIP Devices, which are based on this Standard, as the media from Asterisk is not authorized Asterisk does not support RFC 5009, so its hard to tell if he sending media or not, the network will mark it with inactive, we may add a suggestion in core network, that in case of 18x with SDP coming through, we could mark it with Sendonly to authorize it, but it will not be so helpful as 183 from Asterisk  does not send RTPs, also this will not make MGCF/MSC happy as they will not signal Alerting to the originating User, as long as Asterisk does not send the 180. I improved the call flow, i added what the IMS Core Network marks the SIP responses from Asterisk, my mistake i did not add the Headers in the first time, i hope this time its better. also the modification  to the code consider the 183 SDP as final answer in spite of that this answer was not reliable, this is wrong and its against what in RFC 3262 already written, it considered only final if it has been transmitted reliably in 18x or in 200OK final answer, what was Asterisk doing what completely OK, he was just sending what we call it "Preview or Demo SDP" in every SDP Message. maybe an option could be added so Asterisk will always send 183 something like inbandprogress=always. i hope this time i was able to explain it, if still not cleared, i will be more happy to show you that in real time, feel free to contact me, so i can prepare the case for you. Best regards and happy Easter Barbour By: Abdul Karim Barbour (NUCLEAR-WAR) 2020-04-11 13:54:39.615-0500 improved call flow with Network headers By: Alexei Gradinari (alexei gradinari) 2020-04-11 14:32:10.111-0500 What do mean "183 SDP as final answer"? You shouldn't rely that always be 180 reply in all SIP calls. There are a lot of case where there isn't 180 reply in SIP flow, but only 183. What's asterisk should do in this case? Insert 180? As I understand your asterisk server sends 183 to "the Provider's network", "the Provider's network" expects to receive 183 with P-Early-Media, which is not in your case. The conclusion: your asterisk server must add P-Early-Media with all 183 replies. By: Abdul Karim Barbour (NUCLEAR-WAR) 2020-04-11 15:38:39.861-0500 Hi Alexei, What do mean "183 SDP as final answer"? The final SDP Answer, which will be used to establish the call, in the old Ticket  : ASTERISK-27994 the user wrote, that Asterisk is sending SDP in every 18x Message, this is normal because the 18x Messages were not transmitted reliably, 18x is only considered final answer if its has been transmitted reliably, therefore what Asterisk was doing was correct behavior, see RFC 3262 about that, the user should have set the dialog to reliable, then Asterisk will not send another SDP, as he already send the final one in the 183, he can also turn on the option inbandprogress=yes, then he will get always 183 with one time SDP in the first one, instead of changing the whole code, which breaks other scenarios.   What's asterisk should do in this case? Insert 180? revert back the code, which allow to send 180 even if 183 already sent, and in case that someone need it to always send 183 he should first set the option inbandprogress to "yes" and 100rel to "required" so he wll get always 183 and one time SDP >>You shouldn't rely that always be 180 reply in all SIP calls. There are a lot of case where there isn't 180 reply in SIP flow, but only 183 : <<< I expect 180 if the user B is ringing, i may only get 183, but this according to the standard is not Alerting, and will cause silence in early State. for example VoLTE Devices send first 183 SDP reliable Answer after they prepared there resources then after the acknowledgment (PRACK) they send 180, this normal Call flow for VoLTE.   it has nothing to do with the PEM values nor supporting it in Asterisk, it has to do with the provisional responses that Asterisk is sending, which is this case cause problem after forced using this change to never send 180 if 183 already sent, that its not what the standard says. What Asterisk should do is sending the 180 even if he send 183, as this is crucial to have at the other end of the network alerting state, this can be done by revert back this change. The notwork is expecting 180 and not 183 to signal alerting, see the chapter :7.2.3.2.4 to see what the network entity "MGCF" expect to start alerting also adding PEM to the 18x will not solve the issue for two reasons 1. Providers in generals dont trust early media from the PBXs 2. even if set to authorize this will not signal Alerting if there is no 180, 183 is used to deliverer announcements in most cases and does not mean alerting, only 180 means Alerting, Alerting = Subscriber Free in the ACM Message Best regards and Happy Easter Barbour By: Alexei Gradinari (alexei gradinari) 2020-04-11 16:50:17.821-0500 Could you please point me to RFC about 183 and "The final SDP Answer, which will be used to establish the call". The Final Response is 200. My code fixed "dead silence" that occurs between asterisk and SIP endpoints. Could you, please, carefully read the description of this change. Your case is the Interoperability issue between the asterisk which supports only simple SIP and a node/network which expects SIP/ISUP. You statement "Providers in generals dont trust early media from the PBXs" is incorrect. The SIP stack of asterisk knows nothing about "VoLTE Device", "MGCF", "ACM Message". If in your case this patch is not needed you can build the asterisk without this patch. Sorry, but I can’t spend more time arguing with you. [~gjoseph] Сan you comment? By: Abdul Karim Barbour (NUCLEAR-WAR) 2020-04-11 22:47:31.805-0500 Sir if you don't want to read the standards yourself im not going to teach it to you, you better start with SDP Offer/Answer in reliable mode, let me give you a hint: SDP Answer is not the same as 200OK SIP INVITE Answer, SDP can also get an Offer in 200OK INVITE, and get the final answer in the ACK, standards are there to organize things in VoIP Networks, if the standards did not convince you that this signaling is causing problem, i don't think i can do anything more. I already explain to you why the signaling is wrong and you still mixing the staff together, this is a case where a Customer calls my Asterisk based call center and hear silence, anyway its your code fix it or break it, its not my business at the end, i open the ticket after recommendation from Mr. George Joseph. you fixed an issue by breaking another im not sure what type if fix you did to be honest, i read the issue and understand what the user was facing and offer a suggestion, but you did not get the idea, i will simply revert back your broken fix, before compiling and that's it The issue is in the SIP Message which case the client to play silence as he did not get alerting read carefully what i explain to you, Asterisk is not expected to support other that SIP in this case., i explain to you what is happening at the client side and why the client is not switching to alerting, absolutely nothing to do with Asterisk ISUP capability. in regards of my statement, why in general the PBX is not trusted for early media from providers is because of Frauds, privacy...  issues, e.g. transmitting unwanted media ( User speaks before the call has been answered), can you also tell me if you are expecting Asterisk to be only be called from SIP User ? if yes, then i think we should throw away our 3G/ISDN.. etc networks away. its normal that we may not have the same opinion, i apologize, i hope some expert can come to this ticket and help us better. Best Regards and Happy Easter Barbour By: George Joseph (gjoseph) 2020-04-14 09:20:37.669-0500 I'd like to suggest that this discussion be re-stated on the asterisk users mailing list so more folks can weigh in. http://lists.digium.com/mailman/listinfo/asterisk-users