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

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

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


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