[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=250211#comment-250211 ] 

Abdul Karim Barbour edited comment on ASTERISK-28821 at 4/11/20 5:47 AM:
-------------------------------------------------------------------------

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


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

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