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

[Michael L. Young (JIRA)]

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

Michael L. Young edited comment on ASTERISK-20633 at 11/19/12 9:29 AM:
-----------------------------------------------------------------------

I quoted RFC3264 section 8 in my prior comment.  I am not sure how much clearer it needs to be for those you are trying to interop with.

All aspects of the session can be modified except for the following:  the "o=" line which includes the SDP version.  The "o=" line MUST be identical and the version MUST increment by one if there was a change from the previous SDP (the last SDP provided).

Please take a look at the RFC3264 quote again in my prior comment for its full context.  It seems pretty clear to me.

{quote}
If the
offered SDP is different from the previous SDP, some constraints are
placed on its construction, discussed below.
{quote}

{quote}
Nearly all aspects of the session can be modified. New streams can
be added, existing streams can be deleted, and parameters of existing
streams can change. When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP.
{quote}
                
      was (Author: elguero):
    I quoted RFC3264 section 8 in my prior comment.  I am not sure how much clearer it needs to be for those you are trying to interop with.

All aspects of the session can be modified except for the following:  the "o=" line which includes the SDP version.  The "o=" line MUST be identical and the version MUST increment by one from the previous SDP (the last SDP provided).

Please take a look at the RFC3264 quote again in my prior comment for its full context.  It seems pretty clear to me.

{quote}
If the
offered SDP is different from the previous SDP, some constraints are
placed on its construction, discussed below.
{quote}

{quote}
Nearly all aspects of the session can be modified. New streams can
be added, existing streams can be deleted, and parameters of existing
streams can change. When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP.
{quote}
                  
> 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