Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Flemming Andreasen <fandreas@cisco.com> Thu, 14 March 2013 19:45 UTC
Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0180D11E8231 for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 12:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.698
X-Spam-Level:
X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_LOAN=2.3, MANGLED_NOTICE=2.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHaP9a0eRDdB for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 12:45:38 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6952E11E8166 for <mmusic@ietf.org>; Thu, 14 Mar 2013 12:45:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34503; q=dns/txt; s=iport; t=1363290338; x=1364499938; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Oo9JeRvDeJsy1XTvPSN5pW6lXrAbKuXI7QbCUzCjWww=; b=mMq0Hl/r1RNSzkHnWbAQEnCsYZOyNA31xExRUxC5lzS66EGxk/Yg0MDT cqQyk00kAlwe4RssYsiO0eBfbJpPZ0YFDJIjkbQNC7odsvWC1lR6inAAe NZsNSfGCyhFUU83ktLHb29N1dhFUOibnzJhiTx+swzqg+RaIIY7cnoTbj M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAA8oQlGtJXG//2dsb2JhbABDhByJa7Z7gWUWdIIrAQEBBG4KARALEQQBAQEJFgEBBgcJAwIBAgE0CQgGDQEFAgEBBRKHeQzBaY8LAQoGAYNAA5ZYkQKBVIFSIA
X-IronPort-AV: E=Sophos; i="4.84,846,1355097600"; d="scan'208,217"; a="187589386"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2013 19:45:37 +0000
Received: from bxb-vpn3-830.cisco.com (bxb-vpn3-830.cisco.com [10.86.251.62]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2EJjaMO002591; Thu, 14 Mar 2013 19:45:36 GMT
Message-ID: <514228DF.8060303@cisco.com>
Date: Thu, 14 Mar 2013 15:45:35 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
References: <DBB452AD-7443-4B45-A706-BC79442979BB@vidyo.com> <BBF5DDFE515C3946BC18D733B20DAD2338D2AE5E@XMB104ADS.rim.net> <F81CEE99482EFE438DAE2A652361EE12067976D4@MCHP04MSX.global-ad.net>
In-Reply-To: <F81CEE99482EFE438DAE2A652361EE12067976D4@MCHP04MSX.global-ad.net>
Content-Type: multipart/alternative; boundary="------------080902050101060401070506"
Cc: "jonathan@vidyo.com" <jonathan@vidyo.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 14 Mar 2013 19:45:40 -0000
As to ccap not being an alternative to ICE we are all in agreement on that - the lack of port negotiation alone makes that clear (it simply doesn't work without that). As to ccap being explicitly forbidden to express IP4 and/or IP6 addresses as alternatives, can somebody please point me to either meeting minutes or mailing list discussion to that effect ? The only thing I have found is the port discussion we had in Taipei, where we agreed not to add a port capability. From http://www.ietf.org/proceedings/82/minutes/mmusic.htm: <quote> Miscellaneous Capabilities Negotiation in SDP (Simo Veikkolainen, 10) ===================================================================== draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt <http://www.ietf.org/id/draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt> Simo presented hisslides <http://www.ietf.org/proceedings/82/slides/mmusic-8.pptx>. Simo explained the need to be able to indicate alternative port numbers, but PSTN media, port number doesn't make sense. The CS draft says use port number 9 (the discard port). We have to put something there because required by SDP syntax. If an RTP stream is offered, then a regular port number should be written instead. The problem arises when both CS and RTP streams are offered at the same time, one as an alternative of the other. Then, the port number makes sense for RTP but not for CS, but still, there is a single place to write the port number in the SDP, so, has to be shared by both alternative media streams. Possible solutions: 1. Circuit-switched media uses the same port as RTP media even though the port is not really used 2. Extend capneg with a port number capability attribute, restricting its use to cases where ICE cannot be used. 3.Select anything as a port number and say "do not care on reception". Jonathan Lennox suggested saying that port numbers not equal 0 have to be ignored. Hadriel Kaplan asked if middle boxes not supporting this stuff can be broken. The discussion is moved offline. There are questions on how could be possible to indicate preference for one media stream above the alternative. Miguel Garcia suggested using port 9 if it works. If not take anything not equal 0. Receiver has to ignore. In general, there was pushback on the port negotiation approach. The authors should explore a solution along the third option: write the RTP port number in the "m=" line. If CS alternative is chosen, discard the port number on reception. </quote> Apart from that, the only thing I'm aware of is the 4 WG versions of this draft which have all said the same about IP4/IP6 and ICE, and again, that text was both WGLC'ed and reviewed by 2 volunteers without any concerns. Where does the alternate understanding come from ? Thanks -- Flemming On 3/14/13 2:16 PM, Stach, Thomas wrote: > This is also my understanding > ... although my initially proposed text does not reflect this correctly. > Regards > Thomas > > ------------------------------------------------------------------------ > *Von:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > *Im Auftrag von *Andrew Allen > *Gesendet:* Donnerstag, 14. März 2013 14:10 > *An:* jonathan@vidyo.com; fandreas@cisco.com > *Cc:* mmusic@ietf.org > *Betreff:* Re: [MMUSIC] RE : I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > My understanding also was that we agreed that CCAP was not an > alternative to ICE. > > > *From*: Jonathan Lennox [mailto:jonathan@vidyo.com] > *Sent*: Thursday, March 14, 2013 01:06 PM Central Standard Time > *To*: Flemming Andreasen <fandreas@cisco.com> > *Cc*: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>; > Andrew Allen; mmusic@ietf.org <mmusic@ietf.org> > *Subject*: Re: [MMUSIC] RE : I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote: > >> On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote: >>> Re-, >>> What is important is the quality of produced documents. The >>> content of the document is not frozen and unless I'm mistaken >>> there is not IETF LC. >>> >> Correct. >>> What I understand from the text in the draft is: ccap is allowed >>> to signal an IPv4@ and IPv6@ if ICE is not supported. >>> >> ccap is not prohibited from doing so in the absence of ICE, >> however as explained in the document >> 1) When the IETF Standard Track mechanism ICE is available, ccap >> MUST NOT signal an IPv4/IPV6 address alternative. >> 2) The draft does (intentionally) not provide a full solution for >> negotiating alternative IP-addresses since we have a Standards >> Track mechanism for doing so (ICE). > > Hi, Fleming -- > > My understanding of the WG consensus -- and my interpretation of > the text in the draft -- was stronger than this: ccap MUST NOT be > used for the kinds of alternatives ICE can express, whether or not > ICE is actually being used in a particular offer/answer. > > If we're getting divergent interpretations of this document, we > probably do need to update its text. > > -- > Jonathan Lennox > jonathan@vidyo.com <mailto:jonathan@vidyo.com> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), > or constitute non-public information. Any use of this information > by anyone other than the intended recipient is prohibited. If you > have received this transmission in error, please immediately reply > to the sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission > by unintended recipients is not authorized and may be unlawful. >
- [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscel… internet-drafts
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… Simo.Veikkolainen
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… mohamed.boucadair
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… Stach, Thomas
- [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-m… mohamed.boucadair
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… Stach, Thomas
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… Atle Monrad
- [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-m… mohamed.boucadair
- [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-m… mohamed.boucadair
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… DOLLY, MARTIN C
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Andrew Allen
- [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-… mohamed.boucadair
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… Atle Monrad
- Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmu… Andrew Allen
- [MMUSIC] RE : RE : RE : I-D Action: draft-ietf-mm… mohamed.boucadair
- Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmu… Simo.Veikkolainen
- Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmu… mohamed.boucadair
- Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmu… Simo.Veikkolainen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Jonathan Lennox
- Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmu… mohamed.boucadair
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Flemming Andreasen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… mohamed.boucadair
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Flemming Andreasen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Jonathan Lennox
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… mohamed.boucadair
- [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-… mohamed.boucadair
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Flemming Andreasen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Flemming Andreasen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Jonathan Lennox
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Andrew Allen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Stach, Thomas
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Flemming Andreasen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Andrew Allen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Flemming Andreasen
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… Hadriel Kaplan
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… Hadriel Kaplan
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… mohamed.boucadair
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Simo.Veikkolainen
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… Hadriel Kaplan
- Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mi… Flemming Andreasen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Flemming Andreasen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Andrew Allen
- Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-s… Flemming Andreasen