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

Richard Mudgett (JIRA) noreply at issues.asterisk.org
Fri Apr 10 14:20:25 CDT 2020


     [ https://issues.asterisk.org/jira/browse/ASTERISK-28821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Mudgett updated ASTERISK-28821:
---------------------------------------

    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

  was:
Commit ID .for this change : I7450b751083ec30d68d6abffe922215a15ae5a73
underlying Ticket ID : ASTERISK-27994
the colleague add wrong change to code which breaks SIP/ISUP Interoperability, hence goese 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 Feld 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


> 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
>
> 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)



More information about the asterisk-bugs mailing list