[Sip] Issue #163: "where does SDP section live"

"Tom-PT Taylor" <taylor@nortelnetworks.com> Mon, 10 September 2001 17:20 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23196 for <sip-archive@odin.ietf.org>; Mon, 10 Sep 2001 13:20:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08916; Mon, 10 Sep 2001 12:49:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08889 for <sip@optimus.ietf.org>; Mon, 10 Sep 2001 12:49:38 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22103 for <sip@ietf.org>; Mon, 10 Sep 2001 12:48:10 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8AGmdp23691 for <sip@ietf.org>; Mon, 10 Sep 2001 12:48:39 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 10 Sep 2001 12:48:42 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <R695PF8B>; Mon, 10 Sep 2001 12:48:49 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110514FAFD@zcard00g.ca.nortel.com>
From: Tom-PT Taylor <taylor@nortelnetworks.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Cc: confctrl@ISI.EDU
Date: Mon, 10 Sep 2001 12:48:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13A18.70753480"
X-Orig: <taylor@americasm01.nt.com>
Subject: [Sip] Issue #163: "where does SDP section live"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

I've clipped this description from Rohan Mahy's note, assuming it reflects
Jonathan's statement: 

 >#163 "where does SDP section live"
 >Issues: SIP spec has an appendix with SDP usage;
 >Not really a SIP issue at all;
 >Other descriptions will come along;
 >Sync issue with SDP spec;
 >Beefiness of SIP spec already
 >Some ideas: Separate RFC, Incorporate into SDP revision, Keep it as it is
 >Proposal: Keep it as it is

The implication of the decision on this issue is either that the negotiation
model for SDP is application-specific (implication if the SDP annex stays)
or that the negotiation model is general (implication if the annex becomes a
separate document in MMUSIC).

Megaco might be a bit different if a general document on SDP negotiation had
been available in 1999.  As it is, we built specific support for our model
into the Megaco protocol.

My point is that we should consider what is the best approach looking
forward.  When SDPng comes along, will we again face the necessity of
defining how it is used with each application, or will it be possible to
define a common view?

My personal preference is for a common document.  I think it is possible,
although it may contain different sections governing the operation of
different functions.  For example, there may be a difference in the model
used to reveal capabilities (a Megaco requirement), as opposed to
negotiating a specific media flow (a requirement common to Megaco and SIP).

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)