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

["Worley, Dale R (Dale)" <[e-mail]>]

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