IETF Logo Mail Archive

[MMUSIC] Scope and applicability of draft-ietf-mmusic-sdp-misc-cap

Jean-Francois Mule <jf.mule@cablelabs.com> Mon, 22 March 2010 22:44 UTC

Return-Path: <jf.mule@cablelabs.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D750E3A6B2A for <mmusic@core3.amsl.com>; Mon, 22 Mar 2010 15:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.951
X-Spam-Level: *
X-Spam-Status: No, score=1.951 tagged_above=-999 required=5 tests=[AWL=-1.730, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_12=0.6]
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 3DebG5j6-nyX for <mmusic@core3.amsl.com>; Mon, 22 Mar 2010 15:44:39 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 192683A6B25 for <mmusic@ietf.org>; Mon, 22 Mar 2010 15:44:39 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2MMit0i029176; Mon, 22 Mar 2010 16:44:55 -0600
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 22 Mar 2010 16:44:55 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 22 Mar 2010 16:44:56 -0600
From: Jean-Francois Mule <jf.mule@cablelabs.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "Simo.Veikkolainen@nokia.com" <Simo.Veikkolainen@nokia.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Date: Mon, 22 Mar 2010 16:44:56 -0600
Thread-Topic: Scope and applicability of draft-ietf-mmusic-sdp-misc-cap
Thread-Index: AcrFVjFYRt2MtoQCTWGSPO1ilSaHpgAVoJzgAAcGCNAAAG0jkAAAZ+NwAAMifLABCrldEA==
Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4E30D06@srvxchg>
References: <20100316221502.8E8A53A6895@core3.amsl.com> <A444A0F8084434499206E78C106220CABE904B1D@MCHP058A.global-ad.net> <B23B311878A0B4438F5F09F47E01AAE04E328EFCD2@NOK-EUMSG-01.mgdnok.nokia.com> <A444A0F8084434499206E78C106220CABE904D0A@MCHP058A.global-ad.net> <B23B311878A0B4438F5F09F47E01AAE04E328EFD0C@NOK-EUMSG-01.mgdnok.nokia.com> <A444A0F8084434499206E78C106220CABE904E28@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CABE904E28@MCHP058A.global-ad.net>
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
X-Approved: ondar
Subject: [MMUSIC] Scope and applicability of draft-ietf-mmusic-sdp-misc-cap
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2010 22:44:39 -0000

I wanted to come back to John's note and zoom in on the scope and areas of applicability of draft-ietf-mmusic-sdp-misc-cap.
	
John wrote:
> The reason I query this is because of the c-line negotiation
> mechanism, which introduces a new way of negotiation between IPv4
> and IPv6, in contradiction to the outcome of IETF#68, when there
> was consensus to use ICE as the basis, rather than ANAT or SDP
> capability negotiation (and leading to the deprecation of ANAT in
> the approved ICE draft). 

This ID (draft-ietf-mmusic-sdp-misc-cap-00.txt) introduces additional capability negotiation semantics into the general SDP capneg framework (i, c and b lines in SDP can now ). For the record, this ID was previously http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-01 and has been discussed in several MMUSIC meetings and on the list.

a) About the bcap:
I believe no objections have been raised on the capability attribute for bandwith (bcap).

b) icap:
There were some comments during an IETF meeting from Ted and others about the icap.

c) About the connection capability (ccap): 
draft-ietf-mmusic-sdp-misc-cap allows the negotiation of capabilities related to the c line.
If you recall, draft-garcia-mmusic-sdp-misc-cap-01 was introduced shortly after http://tools.ietf.org/html/draft-garcia-mmusic-sdp-cs-02 (now draft-ietf-mmusic-sdp-cs-03).
For folks that do want to use sdp capneg for proposing SDP configurations with CS bearers (c=pstn, see draft-ietf-mmusic-sdp-cs-03) as alternative to media connections (e.g., c=IN IP4), ccap as defined in misc-cap can do that.  It was noted in IETF#72 that using ICE for proposing CS bearers as ICE candidates may not be a good idea because the connectivity check requirements associated with ICE http://www.ietf.org/proceedings/72/minutes/mmusic.html). 
As for proposing IPv4/IPv6 alternatives, ICE deprecates ANAT and is the preferred solution the WG has chosen so far per IETF#68.

In summary, and this is a personal comment, I believe misc-cap is a draft that complements the sdp cap neg framework.

Thoughts and comments appreciated.

Jean-Francois.

v2.23.0 | Report a Bug | By Email