[asterisk-bugs] [JIRA] (ASTERISK-28821) a code change to chan_pjsip breaks SIP/ISUP internetworking in early state

[Abdul Karim Barbour (JIRA)]

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

Abdul Karim Barbour commented on ASTERISK-28821:
------------------------------------------------

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.

Best regards and Happy Easter
Barbour

> a code change to chan_pjsip breaks SIP/ISUP internetworking in early state
> --------------------------------------------------------------------------
>
>                 Key: ASTERISK-28821
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28821
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 16.5.0, 17.3.0
>            Reporter: Abdul Karim Barbour
>         Attachments: Asterisk-badcode-corrected.pdf
>
>
> 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



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