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

"Worley, Dale R (Dale)" <dworley@avaya.com> Wed, 27 October 2010 19:28 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A083A6912 for <sipcore@core3.amsl.com>; Wed, 27 Oct 2010 12:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.43
X-Spam-Level:
X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdtjHQ6M4PTj for <sipcore@core3.amsl.com>; Wed, 27 Oct 2010 12:28:44 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id A9E353A6902 for <sipcore@ietf.org>; Wed, 27 Oct 2010 12:28:43 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="215200296"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Oct 2010 15:29:48 -0400
X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="533284814"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Oct 2010 13:03:43 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 27 Oct 2010 13:03:43 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, Dale Worley <dworley@nortel.com>
Date: Wed, 27 Oct 2010 13:03:42 -0400
Thread-Topic: [sipcore] Reviewers needed for new music-on-hold technique
Thread-Index: ActxfyJo/BLSsIMMSF2xmeJDgfhkYwEZ5hb/
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B2202288991@DC-US1MBEX4.global.avaya.com>
References: <CD5674C3CD99574EBA7432465FC13C1B220228896D@DC-US1MBEX4.global.avaya.com>, <4CC0D91F.7060304@cisco.com>
In-Reply-To: <4CC0D91F.7060304@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Oct 2010 19:28:45 -0000

________________________________________
From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com]

[as individual]

Obviously the constraint about reusing payload numbers is problematic. I
think we should consider the possibility of relaxing it, though I don't
know if we can get away with that after the fact or not.

ISTM that the fundamental reason for such a constraint is transient.
When you have an existing session and then modify it, the change in the
signaling and the change in the media packets do not happen
synchronously. So when you make the offer you must be ready to receive
media based on the new offer while you are still receiving media on the
old offer. Similarly for sending.
_______________________________________________

You are quite correct about this.  But re-reading my draft, I notice that the problem is remarkably theoretical:  In this case, the UA that does not execute the hold generates an offer to which the MOH server generates an answer.  The MOH server sends RTP using the codecs specified in the UA's offer.  Thus, there can be no confusion when the UA decodes the RTP, as the RTP is being sent based on what the UA specified.  The problem is the requirement that the codecs that the MOH server lists in its answer must meet the non-reuse requirement (despite that no media will be sent to the MOH server).  In practice I am sure that the hold-executing phone does not need to worry about this problem at all.

Dale