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

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-20633:
----------------------------------------

The fact that the destination IP address changed is immaterial.  I'd argue that because the INVITE request containing the new destination IP address occurs within a dialog, i.e., it is a re-INVITE, it is hence part of the existing 'session'.  RFC 3264 notes that the Offer/Answer model it describes exists within the context of a higher layer, i.e., SIP.  It is SIP that determines the session, not the SDP contained in the SIP messages.

Section 8.3.1 also notes that you can, within an existing session, modify the address/port/transport:

{quote}
8.3.1 Modifying Address, Port or Transport

   The port number for a stream MAY be changed.  To do this, the offerer
   creates a new media description, with the port number in the m line
   different from the corresponding stream in the previous SDP.  If only
   the port number is to be changed, the rest of the media stream
   description SHOULD remain unchanged.  The offerer MUST be prepared to
   receive media on both the old and new ports as soon as the offer is
   sent.  The offerer SHOULD NOT cease listening for media on the old
   port until the answer is received and media arrives on the new port.
   Doing so could result in loss of media during the transition.

   Received, in this case, means that the media is passed to a media
   sink.  This means that if there is a playout buffer, the agent would
   continue to listen on the old port until the media on the new port
   reached the top of the playout buffer.  At that time, it MAY cease
   listening for media on the old port.

   The corresponding media stream in the answer MAY be the same as the
   stream in the previous SDP from the answerer, or it MAY be different.
   If the updated stream is accepted by the answerer, the answerer
   SHOULD begin sending traffic for that stream to the new port
   immediately.  If the answerer changes the port from the previous SDP,
   it MUST be prepared to receive media on both the old and new ports as
   soon as the answer is sent.  The answerer MUST NOT cease listening
   for media on the old port until media arrives on the new port.  At
   that time, it MAY cease listening for media on the old port.  The
   same is true for an offerer that sends an updated offer with a new
   port; it MUST NOT cease listening for media on the old port until
   media arrives on the new port.

   Of course, if the offered stream is rejected, the offerer can cease
   being prepared to receive using the new port as soon as the rejection
   is received.

   To change the IP address where media is sent to, the same procedure
   is followed for changing the port number.  The only difference is
   that the connection line is updated, not the port number.

   The transport for a stream MAY be changed.  The process for doing
   this is identical to changing the port, except the transport is
   updated, not the port.

{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: 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