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

Michael L. Young commented on ASTERISK-20633:
---------------------------------------------

Asking questions is a good thing.  If you don't ask questions, you never learn or understand things.

You are correct.  Understanding what a "session" _is_, is very important.

Therefore, from the SIP RFC3261, in reading it, it is clear about what a session is.

Here are some quotes about re-INVITES under section 14 of RFC3261:

{quote}
14 Modifying an Existing Session

   A successful INVITE request (see Section 13) establishes both a
   dialog between two user agents and a session using the offer-answer
   model.  Section 12 explains how to modify an existing dialog using a
   target refresh request (for example, changing the remote target URI
   of the dialog).  This section describes how to modify the actual
   session.  This modification can involve changing addresses or ports,
   adding a media stream, deleting a media stream, and so on.  This is
   accomplished by sending a new INVITE request within the same dialog
   that established the session.  An INVITE request sent within an
   existing dialog is known as a re-INVITE.
{quote}

So, a re-INVITE is modifying an actual session that is already established.  It is not establishing a new session.

Under the section for UAC Behavior:

{quote}
 If the session description format has the capability for version
   numbers, the offerer SHOULD indicate that the version of the session
   description has changed.
{quote}

Here it discusses the version number in the session description.  It mentions that the version number should be used to indicate a change.  RFC3264 defines how to use that version number, which I have quoted up above.  That version number MUST increment, not start over at 1.  We are not establishing a new session... we are modifying an existing one.

The section for UAS Behavior:

{quote}
If a UA receives a re-INVITE for an existing dialog, it MUST check
   any version identifiers in the session description or, if there are
   no version identifiers, the content of the session description to see
   if it has changed.  If the session description has changed, the UAS
   MUST adjust the session parameters accordingly, possibly after asking
   the user for confirmation.

      Versioning of the session description can be used to accommodate
      the capabilities of new arrivals to a conference, add or delete
      media, or change from a unicast to a multicast conference.
{quote}

Again, the RFC mentions using a version for the session description for changing media streams.  The use of the version number is defined in RFC3264 as I have already quoted before.

I hope this helps to clarify what a session is and how re-INVITES work.  Essentially, a re-INVITE is modifying an existing session, not creating a new one.  Therefore, the SDP version number should follow the definition provided in RFC3264.
                
> 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: Michael L. Young
>            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 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