[asterisk-bugs] [JIRA] (ASTERISK-20633) Asterisk SIP channel handling of MOH media re-INVITES not RFC 3264 compliant

[Private Name (JIRA)]

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

Private Name edited comment on ASTERISK-20633 at 4/13/17 7:11 PM:
------------------------------------------------------------------

I am facing this exact issue with Broadsoft, but I use PJSIP Asterisk version 13.5
Is there a workaround for this issue in PJSIP or I am bound to go back to old and obsolete technology?
Thanks in advance for helping.

PD I just confirmed that it works indeed with the SIP channel and the setting recommended here.



was (Author: falves11):
I am facing this exact issue with Broadsoft, but I use PJSIP Asterisk version 13.5
Is there a workaround for this issue in PJSIP or I am bound to go back to old and obsolete technology?
Thanks in advance for helping.


> Asterisk SIP channel handling of MOH media re-INVITES not RFC 3264 compliant
> ----------------------------------------------------------------------------
>
>                 Key: ASTERISK-20633
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20633
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability
>    Affects Versions: 1.8.15.0
>         Environment: asterisk 1.8.15.0 on CentOS 5
>            Reporter: sohosys
>            Severity: Minor
>         Attachments: mohdebug.pdf
>
>
> When asterisk is connected to a SIP peer that uses a re-INVITE to place a call on Music On Hold, but omits the "a=sendrecv" tag in the SDP the handling of the SDP offer by Asterisk is not RFC 3264 compliant. This is the case when interoperating with Broadsoft Broadworks , Cisco Call Manager and presumably some other IP PBXs.
> When the call is placed on hold the connected Broadworks platform first requests that the current media is stopped by sending a re-INVITE with a=”inactive” in the SDP. Asterisk accepts this SDP offer and starts MOH. The connected Broadworks platform then sends another re-INVITE with a new media endpoint IP address and port belonging to a media server that is streaming the MOH (this re-INVITE does not contain “a=sendrecv” in the SDP, but does contain a new media endpoint IP and port). Asterisk ACKs the SDP offer with “a=inactive” based on what appears to be logic that says “the media was previously inactive, and the re-INVITE does not explicitly request sendrecv, so we assume that the intention is to leave the media inactive”.
> According to RFC 3264 “If the offerer wishes to both send and receive media with its peer, it MAY include an a=sendrecv" attribute, or it MAY omit it, since sendrecv is the default.”
> The RFC compliant method of handling this SDP offer would be to evaluate each re-INVITE without regard to the previous media state and assume the default of sendrecv when there is no a=inactive, a=sendonly, or a=recvonly in the SDP.
> I have confirmed with both Broadsoft and Cisco that their products by design do not send a=sendrecv in the SDP when directing media to a media server to playback MOH or IVR prompts, and they both claim that this is RFC compliant, and the RFC supports their claims.



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