Re: [sipcore] Reviewers needed for new music-on-hold technique

["Elwell, John" <[e-mail]>]

Dale,

Yes, this text addresses my concerns.

John 

> -----Original Message-----
> From: Worley, Dale R (Dale) [mailto:[e-mail]] 
> Sent: 19 August 2011 20:49
> To: Elwell, John; [e-mail]
> Subject: RE: Reviewers needed for new music-on-hold technique
> 
> How about adding these sections to the end of section 2?
> 
> 
> When the Media Stream Directionality is "inactive"
> 
> The directionality of the media stream in the SDP offer in an INVITE
> or re-INVITE to the music source can be "inactive" if the SDP offer
> from the remote UA was "sendonly" or "inactive".  Generally, this
> happens when the remote UA also has put the call on hold and provided
> a directionality of "sendonly".  In this situation, the executing UA
> can omit establishing the dialog with the music source (or can
> terminate the existing dialog with the music source).
> 
> If the executing UA uses this optimization, it creates the SDP answer
> itself, with directionality "inactive" and using its own RTP/RTCP
> ports, and returns that answer to the remote UA.
> 
> The executing UA must be prepared for the remote UA to send a
> re-INVITE with directionality "active" or "recvonly", in which case
> the executing UA must initiate a dialog with the music source, as
> described above.
> 
> Multiple Media Streams
> 
> There may be multiple media streams (multiple m= lines) in any of the
> the SDPs involved in the dialogs.  As the SDPs are manipulated, each
> media description (each starting with an m= line) is manipulated as
> described above for a single media stream.  But there are some
> elaborations that the executing UA may implement to achieve specific
> effects.
> 
> If the executing UA desires to present only certain media types as
> on-hold media, when passing the offer SDP through, it can reject any
> particular media streams by setting the port number in the m= line to
> zero.[offer-answer]  This ensures that the answer SDP will also have a
> rejection for that m= line.
> 
> If the executing UA wishes to provide its own on-hold media for a
> particular m= line, it can do so by providing the answer information
> for that m= line.  The executing UA may decide to do this when the
> offer SDP is received (by modifying the m= line to rejected state when
> sending it to the music source), or upon receiving the answer from the
> music source and discovering that the m= line has been rejected.
> 
> The executing UA may not want to pass a rejected m= line from the
> music source to the remote UA (when the remote UA provided a
> non-rejected m= line), and instead provide an answer with
> directionality "inactive" (and specifying its own RTP/RTCP ports).
> 
> 
> Dale
>