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

"Elwell, John" <> Mon, 22 August 2011 06:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 498CD21F86DD for <>; Sun, 21 Aug 2011 23:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.289
X-Spam-Status: No, score=-103.289 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CF3FB8Ohkq6Q for <>; Sun, 21 Aug 2011 23:24:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7643D21F86B1 for <>; Sun, 21 Aug 2011 23:24:51 -0700 (PDT)
Received: from (unknown []) by (Server) with ESMTP id D1F291EB841E; Mon, 22 Aug 2011 08:25:52 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Mon, 22 Aug 2011 08:25:52 +0200
From: "Elwell, John" <>
To: "Worley, Dale R (Dale)" <>, "" <>
Date: Mon, 22 Aug 2011 08:25:51 +0200
Thread-Topic: Reviewers needed for new music-on-hold technique
Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1pUiLNrggAC07QCAANGxwIAA5GaygAPWgdA=
Message-ID: <>
References: <>, <> <>, <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Aug 2011 06:24:52 -0000


Yes, this text addresses my concerns.


> -----Original Message-----
> From: Worley, Dale R (Dale) [] 
> Sent: 19 August 2011 20:49
> To: Elwell, John;
> 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