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

Sat Apr 11 13:59:25 CDT 2020

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

Abdul Karim Barbour edited comment on ASTERISK-28821 at 4/11/20 1:57 PM:
-------------------------------------------------------------------------

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

was (Author: nuclear-war):
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, 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

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