Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
<mohamed.boucadair@orange.com> Thu, 14 March 2013 09:05 UTC
Return-Path: <mohamed.boucadair@orange.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 1BF5121F8E71 for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 02:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level:
X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 PeZJCHTcnKeA for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 02:05:06 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7833921F8CB9 for <mmusic@ietf.org>; Thu, 14 Mar 2013 02:05:05 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3A03222CDE8; Thu, 14 Mar 2013 10:05:04 +0100 (CET)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id EF63C35C065; Thu, 14 Mar 2013 10:05:03 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 14 Mar 2013 10:05:03 +0100
From: mohamed.boucadair@orange.com
To: "Simo.Veikkolainen@nokia.com" <Simo.Veikkolainen@nokia.com>, "aallen@blackberry.com" <aallen@blackberry.com>, "thomas.stach@siemens-enterprise.com" <thomas.stach@siemens-enterprise.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "jonathan@vidyo.com" <jonathan@vidyo.com>
Date: Thu, 14 Mar 2013 10:05:02 +0100
Thread-Topic: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOIBnO+4bHDy/obkCLXK+GBDfayZij86oAgAAHBACAAAQ5gIAA4G3QgAADdsA=
Message-ID: <94C682931C08B048B7A8645303FDC9F36EB7356635@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36EB755B1AB@PUEXCB1B.nanterre.francetelecom.fr>, <BBF5DDFE515C3946BC18D733B20DAD2338D28C4F@XMB104ADS.rim.net> <94C682931C08B048B7A8645303FDC9F36EB755B1AC@PUEXCB1B.nanterre.francetelecom.fr> <D09DAE6B636851459F7575D146EFB54B210976E5@008-AM1MPN1-026.mgdnok.nokia.com>
In-Reply-To: <D09DAE6B636851459F7575D146EFB54B210976E5@008-AM1MPN1-026.mgdnok.nokia.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.14.83315
Subject: Re: [MMUSIC] RE : 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 09:05:07 -0000
Hi Simo, The proposed change is not sufficient. If you want ccap to be used to signal an IPv4 address and an IPv6 alternate one, the current text is underspecified (e.g, it does not specify how to signal an alternate port for a distinct AF, how to detect a ccap-unaware midllebox, whether multiple sessions are established or only one is allowed, how many ccap lines are allowed, whether ccap line can be present in both O/A, etc.). But as I understood there is no consensus change then the text should be explicit and say ccap MUST NOT be used to signal an IPv4 address and an IPv6 alternate one. Cheers, Med >-----Message d'origine----- >De : Simo.Veikkolainen@nokia.com [mailto:Simo.Veikkolainen@nokia.com] >Envoyé : jeudi 14 mars 2013 09:53 >À : BOUCADAIR Mohamed OLNC/OLN; aallen@blackberry.com; >thomas.stach@siemens-enterprise.com; mmusic@ietf.org; >jonathan@vidyo.com >Objet : RE: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >There is no change in the consensus, which is that ICE is used >to negotiating alternative IP addresses. > >I'm also fine with Thomas's proposed text, but just to >highlight that ICE is used for IP addresses I would modify a bit: > >--- >If an offerer has implemented Interactive Connectivity >Establishment (ICE) [RFC5245] and the 'ccap' attribute it MUST >use ICE to select between different IP addresses (e.g. "IP4" >and "IP6" or different IP addresses within the same IP address >family). >--- > >Regards, >Simo > >-----Original Message----- >From: ext mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: 13. maaliskuuta 2013 21:19 >To: Andrew Allen; thomas.stach@siemens-enterprise.com; >Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org; >jonathan@vidyo.com >Subject: RE : RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Re-, > >The point is that if the attribute is extended to be able to >convey an IPv4 and an alternate IPv6@, then your statement " >and is not intended for IPv4 vs IPv6 for which ICE is the IETF >defined mechanism." is not valid anymore...If that consensus >changed then I'm puzzled why that argument was raised against >altc and not ccap?!! > >OTOH, if the attribute is extended to cover IPv4/IPv6 then it >should be clearly specified. The current text does not say >much for that case. > >Cheers, >Med > >________________________________________ >De : Andrew Allen [aallen@blackberry.com] Date d'envoi : >mercredi 13 mars 2013 20:03 À : BOUCADAIR Mohamed OLNC/OLN; >thomas.stach@siemens-enterprise.com; >Simo.Veikkolainen@nokia.com; mmusic@ietf.org; >jonathan@vidyo.com Objet : Re: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >The text in the draft was worked out with Jonathan Lennox who >raised the initial concen about conflict with ICE. If Jonathan >is ok with the revised proposal from Thomas then I am OK with it. > >Andrew > >----- Original Message ----- >From: mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time >To: Andrew Allen; thomas.stach@siemens-enterprise.com ><thomas.stach@siemens-enterprise.com>; >Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; >mmusic@ietf.org <mmusic@ietf.org> >Subject: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Hi Andrew, > >This was also my understanding but it seems the current text >opens the door to signal an IPv4 and IPv6 address. > >If it is not allowed, then the text should be clear. > >Cheers, >Med > >________________________________________ >De : Andrew Allen [aallen@blackberry.com] Date d'envoi : >mercredi 13 mars 2013 19:37 À : BOUCADAIR Mohamed OLNC/OLN; >thomas.stach@siemens-enterprise.com; >Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : Re: >[MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >The main use of the CCAP parameter is to indicate the >capability to use CS SDP and E.164 numbers as a connection >address and is not intended for IPv4 vs IPv6 for which ICE is >the IETF defined mechanism. > > > >----- Original Message ----- >From: mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time >To: Stach, Thomas <thomas.stach@siemens-enterprise.com>; >Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; >mmusic@ietf.org <mmusic@ietf.org> >Subject: [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Re-, > >The wording you propose is better as it explicits this >behavior is about ICE and not something else. So, I'm fine >with that wording if this is the intent of the authors. BTW, >the altc draft already mentions that if altc and ccap are both >supported, then both are offered. > >In fact, I stopped to track this draft since the Anaheim >meeting when it seems the consensus of the wg was: ICE is to >solution to signal an IPv4 and IPv6 address. The misc draft >should specify ccap when distinct nettypes are in use. It >seems that consensus is not anymore valid. > >The current text of ccap is under-specified if it is to be >used to convey an IPv4 and IPv6 address. > >Cheers, >Med > >________________________________________ >De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >Date d'envoi : mercredi 13 mars 2013 19:17 À : BOUCADAIR >Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >Objet : AW: [MMUSIC] I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Mohammed, > >I think it is not acceptable to mention altc in the example. >If I recollect correctly, the intention of the text is to >specify that ICE MUST be preferred over 'ccap' for IPv4/v6 >address negotiation. > >If we add 'altc' as another example it basically means that >the proprietary 'altc' is preferred over 'ccap'. >I don't think that a standards track RFC should give the >message that proprietary is preferred. >Based on this issue I think the current text in the draft does >not work. >I would explicitly mention the relation of ICE and 'ccap'. >The relation to other mechanism such as 'altc' needs to be >treated in hte specification of that mechanism. > >Thus I propose to rephrase to: > >If an offerer has implemented Interactive Connectivity >Establishment (ICE) [RFC5245] and the 'ccap' attribute it MUST >use ICE to select between different connection addresses (e.g. > "IP4" and "IP6" or different IP addresses within the same IP >address family). > > >Regards >Thomas > >> -----Ursprüngliche Nachricht----- >> Von: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Gesendet: Mittwoch, 13. März 2013 13:40 >> An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> Betreff: RE : [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> Dear Thomas, >> >> I'm not proposing to change the existing behavior; I'm just asking >> whether it is acceptable to add an additional example to the one >> already cited in the text. >> Wouldn't that be acceptable? >> >> You can propose to add another example if you have any in mind. >> >> Cheers, >> Med >> >> ________________________________________ >> De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >> Date d'envoi : mercredi 13 mars 2013 17:57 À : BOUCADAIR Mohamed >> OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW: >> [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> Mohammed, >> >> I think you have draft-boucadair-mmusic-altc in mind. >> This is an individual submission intended to document some >> proporietary mechanism. >> I don't think we should make restrictions in a standards track >> document in support of proprietary mechanisms. >> Otherwise I could also think of additional proprietary stuff that >> could be mentioned as well. >> >> >> Regards >> Thomas >> >> > -----Ursprüngliche Nachricht----- >> > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im >> > Auftrag von mohamed.boucadair@orange.com >> > Gesendet: Mittwoch, 13. März 2013 11:20 >> > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> > Betreff: Re: [MMUSIC] I-D Action: >> > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > >> > Hi Simo, >> > >> > The document says: >> > >> > The 'ccap' attribute MUST NOT be used in >> > situations where an existing mechanism (such as Interactive >> > Connectivity Establishment (ICE) [RFC5245]) can be used >to select >> > between different connection addresses (e.g. "IP4" and "IP6" or >> > different IP addresses within the same IP address family). >> > >> > Would it be possible to change it to the following: >> > >> > NEW: >> > >> > The 'ccap' attribute MUST NOT be used in >> > situations where a mechanism (such as Interactive >> > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) >is used to >> > select >> > between different connection addresses (e.g. "IP4" and "IP6" or >> > different IP addresses within the same IP address family). >> > >> > >> > Thanks. >> > Cheers, >> > Med >> > >> > >> > >-----Message d'origine----- >> > >De : mmusic-bounces@ietf.org >[mailto:mmusic-bounces@ietf.org] De la >> > >part de Simo.Veikkolainen@nokia.com Envoyé : mercredi 13 >mars 2013 >> > >16:09 À : mmusic@ietf.org Objet : Re: [MMUSIC] I-D Action: >> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > > >> > >Hello, >> > > >> > >We just submitted a new version of the miscellaneous-caps draft, >> > >with text that states that if the connection data capability >> > >attribute (a=ccap) is used the port number in the resulting SDP >> > >MUST be the same as in the original "m=" line, except for >PSTN type >> > >bearers (when the port number used is 9). >> > > >> > >Regards, >> > >Simo >> > > >> > >-----Original Message----- >> > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> > >Behalf Of ext internet-drafts@ietf.org >> > >Sent: 13. maaliskuuta 2013 15:39 >> > >To: i-d-announce@ietf.org >> > >Cc: mmusic@ietf.org >> > >Subject: [MMUSIC] I-D Action: >> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > > >> > > >> > >A New Internet-Draft is available from the on-line >Internet-Drafts >> > >directories. >> > > This draft is a work item of the Multiparty Multimedia Session >> > >Control Working Group of the IETF. >> > > >> > > Title : Miscellaneous Capabilities >> > >Negotiation in the Session Description Protocol (SDP) >> > > Author(s) : Miguel A. Garcia-Martin >> > > Simo Veikkolainen >> > > Robert R. Gilman >> > > Filename : >> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > > Pages : 21 >> > > Date : 2013-03-13 >> > > >> > >Abstract: >> > > SDP has been extended with a capability negotiation mechanism >> > > framework that allows the endpoints to negotiate >> > transport protocols >> > > and attributes. This framework has been extended with a media >> > > capabilities negotiation mechanism that allows endpoints to >> > >negotiate >> > > additional media-related capabilities. This negotiation >> > is embedded >> > > into the widely-used SDP offer/answer procedures. >> > > >> > > This memo extends the SDP capability negotiation >> > framework to allow >> > > endpoints to negotiate three additional SDP capabilities. In >> > > particular, this memo provides a mechanism to negotiate >> bandwidth >> > > ('b=' line), connection data ('c=' line), and titles >> > ('i=' line for >> > > each session or media). >> > > >> > > >> > >The IETF datatracker status page for this draft is: >> > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella >> > >neous-caps >> > > >> > >There's also a htmlized version available at: >> > >>http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps >> > >-04 >> > > >> > >A diff from the previous version is available at: >> > >http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella >> > >neous-caps-04 >> > > >> > > >> > >Internet-Drafts are also available by anonymous FTP at: >> > >ftp://ftp.ietf.org/internet-drafts/ >> > > >> > >_______________________________________________ >> > >mmusic mailing list >> > >mmusic@ietf.org >> > >https://www.ietf.org/mailman/listinfo/mmusic >> > >_______________________________________________ >> > >mmusic mailing list >> > >mmusic@ietf.org >> > >https://www.ietf.org/mailman/listinfo/mmusic >> > > >> > _______________________________________________ >> > mmusic mailing list >> > mmusic@ietf.org >> > https://www.ietf.org/mailman/listinfo/mmusic >> > >> >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic > >--------------------------------------------------------------------- >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. > >--------------------------------------------------------------------- >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