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

[sohosys (JIRA)]

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

sohosys commented on ASTERISK-20633:
------------------------------------

Yes, and the setting ignoresdpversion=yes did provide a workaround. There is still some question around this. The vendors that we are trying to interop with disagree with the diagnosis that the problem is casued by the SDP version number not incrementing properly with the argument that when one of the endpoints in the media stream changes that a new session identifier with version 1 should be created. Both arguments have some validity at face value, and I have not been able to quickly find anything in the RFCs that clarifies this. Do you have an opinion on this or a reference to a RFC that supports the Asterisk position?
                
> 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
>            Assignee: sohosys
>         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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira