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

"Worley, Dale R (Dale)" <> Thu, 18 August 2011 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A564321F8B29 for <>; Thu, 18 Aug 2011 11:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.454
X-Spam-Status: No, score=-103.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 39UMdl7wjF8V for <>; Thu, 18 Aug 2011 11:10:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 86E2E21F8B02 for <>; Thu, 18 Aug 2011 11:10:27 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAGhUTU6HCzI1/2dsb2JhbABCp3R3gUABAQEBAgESKEQLAgEIDQghEDIlAgQBEggah0+cDgKcMYVpXwSYPYtn
X-IronPort-AV: E=Sophos;i="4.68,246,1312171200"; d="scan'208";a="298287533"
Received: from unknown (HELO ([]) by with ESMTP; 18 Aug 2011 14:11:15 -0400
Received: from (HELO ([]) by with ESMTP; 18 Aug 2011 14:02:58 -0400
Received: from ([]) by ([2002:870b:3414::870b:3414]) with mapi; Thu, 18 Aug 2011 14:11:15 -0400
From: "Worley, Dale R (Dale)" <>
To: "Elwell, John" <>, "" <>
Date: Thu, 18 Aug 2011 14:11:15 -0400
Thread-Topic: Reviewers needed for new music-on-hold technique
Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1pUiLNrggAC07QA=
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: Thu, 18 Aug 2011 18:10:28 -0000

> From: Elwell, John []
> Yes, it does now make an appropriate mention of RTCP - thanks.

Good -- Thanks for checking that out.

> I am also curious as to why there are a couple of mentions of using
> directionality "inactive". Why would any of the entities involved use
> "inactive" unless they don't wish to send/receive music-on-hold? In
> particular, why would the INVITE from the executing UA to the MOH
> source use "inactive" - it is specifically asking the MOH source to
> send music, so if it wants "inactive", why send the INVITE?

The strict answer as to why "inactive" is mentioned is that the
algorithm would not be correct without it, and I hadn't considered the
possible optimization of omitting the INVITE to the MOH source.

The situation arises when the remote UA gives directionality
"sendonly" because the remote UA has previously put the call on hold
also.  (The remote UA may reduce the directionality to "inactive" due
to the +sip.rendering="no" in the re-INVITE from the executing UA.)

There probably other situations where this arises.  E.g., where the
remote UA has formerly used a media stream in the dialog but no longer
wants to.

If all of the media streams that would be in the INVITE to the MOH
source have "inactive" directionality, the executing UA can omit
establishing the dialog with the MOH source.  The executing UA would
synthesize the SDP answer itself.  While the call is on hold, if the
remote UA sends a re-INVITE with directionality "active"/"recvonly",
then the executing UA has to start a dialog with the MOH source.

I should add a note that discusses this optimization.

> Perhaps this is to do with multiple media, where the remote UA offers
> several media, and MOH is required only for one of these, so the other
> media descriptions are set to "inactive" in the INVITE to the MOH
> source. Whether or not that was the intention of "inactive", I think
> further discussion of multi-media situations is required. For example,
> if the remote UA offers audio and video and the executing UA wants MOH
> only for audio, how would it behave? Perhaps the example should be
> extended to show such a possibility.

I would expect multiple media streams to work exactly as an extension
of the single media stream situation.  But there may be requirements
that I am not considering.

In the case where a call is being put on-hold and the remote UA is
willing to accept two streams (e.g., audio and video), I would expect
the executing UA to forward this request intact to the MOH server.
The MOH server would decide what media to send to the remote UA.

If the executing UA wanted to restrict the MOH media, it could do so
by editing the SDP offer.  But I don't see any particular reason to do

What are the complexities you are seeing?