From mmusic-bounces@ietf.org Thu Feb 01 05:39:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZLa-0004aw-Me; Thu, 01 Feb 2007 05:39:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZLZ-0004aJ-Fh for mmusic@ietf.org; Thu, 01 Feb 2007 05:39:17 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCZLT-0007vZ-UO for mmusic@ietf.org; Thu, 01 Feb 2007 05:39:17 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 11A972072F for ; Thu, 1 Feb 2007 11:38:02 +0100 (CET) X-AuditID: c1b4fb3c-b0fcabb0000007de-75-45c1c309cfec Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E91F720424 for ; Thu, 1 Feb 2007 11:38:01 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 11:38:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Date: Thu, 1 Feb 2007 11:38:00 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050455677E@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Thread-Index: AcdD55qUBatFalO2SUOJk5raDL6usgCBM+jw From: "Ingemar Johansson S \(LU/EAB\)" To: X-OriginalArrivalTime: 01 Feb 2007 10:38:01.0572 (UTC) FILETIME=[0C169240:01C745ED] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi I am currently reading and trying to understand the draft, as an example I take a SDP offer taken from 3GPP TS26.114 version 1.20 http://www.3gpp.org/ftp/Specs/html-info/26114.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D m=3Daudio 49152 RTP/AVP 97 98 99 100 a=3Drtpmap:97 AMR-WB/16000/1 a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 a=3Drtpmap:98 AMR-WB/16000/1 a=3Dfmtp:98 mode-change-capability=3D2; max-red=3D220; octet-align=3D1 a=3Drtpmap:99 AMR/8000/1 a=3Dfmtp:99 mode-change-capability=3D2; max-red=3D220 a=3Drtpmap:100 AMR/8000/1 a=3Dfmtp:100 mode-change-capability=3D2; max-red=3D220; octet-align=3D1 a=3Dptime:20 a=3Dmaxptime:240 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Using the sdp-capability-negotiation draft I manage to get as far as =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D m=3Daudio 49152 RTP/AVP 97 98=20 a=3Dcreq: v0=20 a=3Dcapar: 1 a=3Drtpmap:97 AMR-WB/16000/1 a=3Dcapar: 2 a=3Drtpmap:98 AMR-NB/8000/1 a=3Dcapar: 3 a=3Dmode-change-capability=3D2; max-red=3D220=20 a=3Dcapar: 4 a=3Dmode-change-capability=3D2; max-red=3D220; = octet-align=3D1 a=3Dptime:20 a=3Dmaxptime:240=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D I know this is wrong, for instance I don't manage to fit the a=3Dfmtp.. line anywhere, can soembody help ? Also, what would a response look like ? Regards Ingemar > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: den 29 januari 2007 21:50 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC]=20 > I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia=20 > Session Control Working Group of the IETF. >=20 > Title : SDP Capability Negotiation > Author(s) : F. Andreasen > Filename :=20 > draft-ietf-mmusic-sdp-capability-negotiation-01.txt > Pages : 29 > Date : 2007-1-29 > =09 > The Session Description Protocol (SDP) was intended for describing=20 > multimedia sessions for the purposes of session=20 > announcement, session=20 > invitation, and other forms of multimedia session=20 > initiation. SDP was=20 > not intended to provide capability indication or capability=20 > negotiation, however over the years, SDP has seen=20 > widespread adoption=20 > and as a result it has been gradually extended to=20 > provide limited=20 > support for these. SDP and its current extensions=20 > however do not have=20 > the ability to negotiate one or more alternative=20 > transport protocols=20 > (e.g. RTP profiles) which makes it particularly=20 > difficult to deploy=20 > new RTP profiles such as secure RTP or RTP with=20 > RTCP-based feedback. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capa > bility-negotiation-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-mmusic-sdp-capability-negotiation-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Feb 01 12:42:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfvw-0005do-M4; Thu, 01 Feb 2007 12:41:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfvv-0005dj-U5 for mmusic@ietf.org; Thu, 01 Feb 2007 12:41:15 -0500 Received: from 103.12.152.198.in-addr.arpa ([198.152.12.103] helo=nj300815-ier2.net.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCfvp-0005SD-Eg for mmusic@ietf.org; Thu, 01 Feb 2007 12:41:15 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l11Hf8XP009193 for ; Thu, 1 Feb 2007 12:41:08 -0500 Received: from [135.9.42.38] ([135.9.42.38]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Feb 2007 10:41:07 -0700 Message-ID: <45C2262B.8030204@avaya.com> Date: Thu, 01 Feb 2007 10:40:59 -0700 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ingemar Johansson S (LU/EAB)" Subject: Re: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt References: <026F8EEDAD2C4342A993203088C1FC050455677E@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050455677E@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 17:41:08.0024 (UTC) FILETIME=[2797BB80:01C74628] X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Ingemar- The current draft describes version 0 of the capability negotiation, and is intended only to satisfy the immediate need for a method to offer choices of STRP or unencrypted transports. Our intent is to let it stand alone so that it may be quickly reviewed, approved, and put into practice. You didn't say what you wanted to do with the cap negotiation, but, if the existing SDP is sufficient, then you don't have to do anything. However, if you're looking for a way to propose configurations that select a subset of the codecs declared on the m-line, the next docuement in the series (version 1) will include extensions to the pcfg: attribute to handle the definition of codecs and formats at the session level which can be referenced at the media level, along with the codecs declared in the media line. The syntax is defined along the lines of an earlier proposal I sent to the list. We hope to have an initial v1 draft available on this list by Monday. To speak to this example, assuming I want to propose configurations with only one of the codecs specified, the SDP might look like: a=creq:1 m=audio 49152 RTP/AVP 97 98 99 100 a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=rtpmap:98 AMR-WB/16000/1 a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-change-capability=2; max-red=220 a=rtpmap:100 AMR/8000/1 a=fmtp:100 mode-change-capability=2; max-red=220; octet-align=1 a=ptime:20 a=maxptime:240 a=pcfg:1 m=1/2/3/4 The m parameter in the pcfg: attribute specifies the codes by ordinal in the order they are declared. Commas are used to group codecs for simultaneous use, and slashes separate alternatives. This should all look familiar from the original -00 draft. BTW, v1 also includes a method to define codecs outside of the media line if it's desirable to exclude them from the "default" configuration implied by the media line itself. -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Ingemar Johansson S (LU/EAB) wrote: > Hi > > I am currently reading and trying to understand the draft, as an example > I take a SDP offer taken from 3GPP TS26.114 version 1.20 > http://www.3gpp.org/ftp/Specs/html-info/26114.htm > > =========================== > m=audio 49152 RTP/AVP 97 98 99 100 > a=rtpmap:97 AMR-WB/16000/1 > a=fmtp:97 mode-change-capability=2; max-red=220 > a=rtpmap:98 AMR-WB/16000/1 > a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 > a=rtpmap:99 AMR/8000/1 > a=fmtp:99 mode-change-capability=2; max-red=220 > a=rtpmap:100 AMR/8000/1 > a=fmtp:100 mode-change-capability=2; max-red=220; octet-align=1 > a=ptime:20 > a=maxptime:240 > =========================== > > Using the sdp-capability-negotiation draft I manage to get as far as > > =========================== > m=audio 49152 RTP/AVP 97 98 > a=creq: v0 > a=capar: 1 a=rtpmap:97 AMR-WB/16000/1 > a=capar: 2 a=rtpmap:98 AMR-NB/8000/1 > a=capar: 3 a=mode-change-capability=2; max-red=220 > a=capar: 4 a=mode-change-capability=2; max-red=220; octet-align=1 > a=ptime:20 > a=maxptime:240 > =========================== > > I know this is wrong, for instance I don't manage to fit the a=fmtp.. > line anywhere, can soembody help ? > > Also, what would a response look like ? > > Regards > Ingemar > > >>-----Original Message----- >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Sent: den 29 januari 2007 21:50 >>To: i-d-announce@ietf.org >>Cc: mmusic@ietf.org >>Subject: [MMUSIC] >>I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.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 : SDP Capability Negotiation >> Author(s) : F. Andreasen >> Filename : >>draft-ietf-mmusic-sdp-capability-negotiation-01.txt >> Pages : 29 >> Date : 2007-1-29 >> >>The Session Description Protocol (SDP) was intended for describing >> multimedia sessions for the purposes of session >>announcement, session >> invitation, and other forms of multimedia session >>initiation. SDP was >> not intended to provide capability indication or capability >> negotiation, however over the years, SDP has seen >>widespread adoption >> and as a result it has been gradually extended to >>provide limited >> support for these. SDP and its current extensions >>however do not have >> the ability to negotiate one or more alternative >>transport protocols >> (e.g. RTP profiles) which makes it particularly >>difficult to deploy >> new RTP profiles such as secure RTP or RTP with >>RTCP-based feedback. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capa >>bility-negotiation-01.txt >> >>To remove yourself from the I-D Announcement list, send a >>message to i-d-announce-request@ietf.org with the word >>unsubscribe in the body of the message. >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >>Internet-Drafts are also available by anonymous FTP. Login >>with the username "anonymous" and a password of your e-mail >>address. After logging in, type "cd internet-drafts" and then >>"get draft-ietf-mmusic-sdp-capability-negotiation-01.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html or >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE >>/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-01.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >>mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >>Below is the data which will enable a MIME compliant mail >>reader implementation to automatically retrieve the ASCII >>version of the Internet-Draft. >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Feb 02 04:45:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCuym-0008Gw-En; Fri, 02 Feb 2007 04:45:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCuyk-0008Fz-Mg for mmusic@ietf.org; Fri, 02 Feb 2007 04:45:10 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCuyb-00069E-Of for mmusic@ietf.org; Fri, 02 Feb 2007 04:45:10 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2F9C12070B; Fri, 2 Feb 2007 10:44:59 +0100 (CET) X-AuditID: c1b4fb3c-b0fcabb0000007de-02-45c3081b123c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0EFDF2099B; Fri, 2 Feb 2007 10:44:59 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 10:44:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Date: Fri, 2 Feb 2007 10:44:57 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05045952C2@esealmw109.eemea.ericsson.se> In-Reply-To: <45C2262B.8030204@avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Thread-Index: AcdGKCqE71HP19xKTeO4cV1c5WwDtQAgaj1g From: "Ingemar Johansson S \(LU/EAB\)" To: "Robert R. Gilman" X-OriginalArrivalTime: 02 Feb 2007 09:44:58.0823 (UTC) FILETIME=[CD6F5D70:01C746AE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi The problem that I (and others?) see is that given all the possible permutation of codec options, payload format options the SDP's easily become really huge. It is true that it is possible to compress the SDP e.g using SigComp but still I find it a bit peculiar. Ideally I would like to have the possibility to select the various parameters in the response, sort of like selecting from a "smorgasbord". As it is in the example below you essentially need to specify a payload type for each permutation while it should in the case below be enough with just two payload types at the most (one for AMR and one for AMR-WB). I don't know of how much use this is, just that find "these specify by means of permutations" a bit odd. Ingemar > -----Original Message----- > From: Robert R. Gilman [mailto:rrg@avaya.com]=20 > Sent: den 1 februari 2007 18:41 > To: Ingemar Johansson S (LU/EAB) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC]=20 > I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt >=20 > Ingemar- > The current draft describes version 0 of the capability=20 > negotiation, and is intended only to satisfy the immediate=20 > need for a method to offer choices of STRP or unencrypted=20 > transports. Our intent is to let it stand alone so that it=20 > may be quickly reviewed, approved, and put into practice. > You didn't say what you wanted to do with the cap=20 > negotiation, but, if the existing SDP is sufficient, then you=20 > don't have to do anything. However, if you're looking for a=20 > way to propose configurations that select a subset of the=20 > codecs declared on the m-line, the next docuement in the=20 > series (version 1) will include extensions to the pcfg:=20 > attribute to handle the definition of codecs and formats at=20 > the session level which can be referenced at the media level,=20 > along with the codecs declared in the media line. The syntax=20 > is defined along the lines of an earlier proposal I sent to the list. > We hope to have an initial v1 draft available on this list by Monday. > To speak to this example, assuming I want to propose=20 > configurations with only one of the codecs specified, the SDP=20 > might look like: >=20 > a=3Dcreq:1 > m=3Daudio 49152 RTP/AVP 97 98 99 100 > a=3Drtpmap:97 AMR-WB/16000/1 > a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > a=3Drtpmap:98 AMR-WB/16000/1 > a=3Dfmtp:98 mode-change-capability=3D2; max-red=3D220; = octet-align=3D1 > a=3Drtpmap:99 AMR/8000/1 > a=3Dfmtp:99 mode-change-capability=3D2; max-red=3D220 > a=3Drtpmap:100 AMR/8000/1 > a=3Dfmtp:100 mode-change-capability=3D2; max-red=3D220; = octet-align=3D1 > a=3Dptime:20 > a=3Dmaxptime:240 > a=3Dpcfg:1 m=3D1/2/3/4 >=20 > The m parameter in the pcfg: attribute specifies the codes by=20 > ordinal in the order they are declared. Commas are used to=20 > group codecs for simultaneous use, and slashes separate=20 > alternatives. This should all look familiar from the=20 > original -00 draft. BTW, v1 also includes a method to define=20 > codecs outside of the media line if it's desirable to exclude=20 > them from the "default" > configuration implied by the media line itself. > -Bob > ---------------------------------------------------- > Bob Gilman rrg@avaya.com +1 303 538 3868 >=20 > Ingemar Johansson S (LU/EAB) wrote: > > Hi > >=20 > > I am currently reading and trying to understand the draft, as an=20 > > example I take a SDP offer taken from 3GPP TS26.114 version 1.20=20 > > http://www.3gpp.org/ftp/Specs/html-info/26114.htm > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > m=3Daudio 49152 RTP/AVP 97 98 99 100 > > a=3Drtpmap:97 AMR-WB/16000/1 > > a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > > a=3Drtpmap:98 AMR-WB/16000/1 > > a=3Dfmtp:98 mode-change-capability=3D2; max-red=3D220; = octet-align=3D1 > > a=3Drtpmap:99 AMR/8000/1 > > a=3Dfmtp:99 mode-change-capability=3D2; max-red=3D220 a=3Drtpmap:100 = > > AMR/8000/1 a=3Dfmtp:100 mode-change-capability=3D2; max-red=3D220;=20 > > octet-align=3D1 a=3Dptime:20 a=3Dmaxptime:240 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >=20 > > Using the sdp-capability-negotiation draft I manage to get as far as > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > m=3Daudio 49152 RTP/AVP 97 98 > > a=3Dcreq: v0 > > a=3Dcapar: 1 a=3Drtpmap:97 AMR-WB/16000/1 > > a=3Dcapar: 2 a=3Drtpmap:98 AMR-NB/8000/1 > > a=3Dcapar: 3 a=3Dmode-change-capability=3D2; max-red=3D220 > > a=3Dcapar: 4 a=3Dmode-change-capability=3D2; max-red=3D220; = octet-align=3D1=20 > > a=3Dptime:20 a=3Dmaxptime:240 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >=20 > > I know this is wrong, for instance I don't manage to fit=20 > the a=3Dfmtp.. > > line anywhere, can soembody help ? > >=20 > > Also, what would a response look like ? > >=20 > > Regards > > Ingemar > >=20 > >=20 > >>-----Original Message----- > >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>Sent: den 29 januari 2007 21:50 > >>To: i-d-announce@ietf.org > >>Cc: mmusic@ietf.org > >>Subject: [MMUSIC] > >>I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts=20 > >>directories. > >>This draft is a work item of the Multiparty Multimedia=20 > Session Control=20 > >>Working Group of the IETF. > >> > >> Title : SDP Capability Negotiation > >> Author(s) : F. Andreasen > >> Filename :=20 > >>draft-ietf-mmusic-sdp-capability-negotiation-01.txt > >> Pages : 29 > >> Date : 2007-1-29 > >>=09 > >>The Session Description Protocol (SDP) was intended for describing=20 > >> multimedia sessions for the purposes of session=20 > announcement,=20 > >>session > >> invitation, and other forms of multimedia session=20 > initiation.=20 > >>SDP was > >> not intended to provide capability indication or capability=20 > >> negotiation, however over the years, SDP has seen=20 > widespread=20 > >>adoption > >> and as a result it has been gradually extended to provide=20 > >>limited > >> support for these. SDP and its current extensions=20 > however do=20 > >>not have > >> the ability to negotiate one or more alternative transport=20 > >>protocols > >> (e.g. RTP profiles) which makes it particularly=20 > difficult to=20 > >>deploy > >> new RTP profiles such as secure RTP or RTP with RTCP-based=20 > >>feedback. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capa > >>bility-negotiation-01.txt > >> > >>To remove yourself from the I-D Announcement list, send a=20 > message to=20 > >>i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > >>the message. > >>You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > >>to change your subscription settings. > >> > >>Internet-Drafts are also available by anonymous FTP. Login with the=20 > >>username "anonymous" and a password of your e-mail address. After=20 > >>logging in, type "cd internet-drafts" and then "get=20 > >>draft-ietf-mmusic-sdp-capability-negotiation-01.txt". > >> > >>A list of Internet-Drafts directories can be found in=20 > >>http://www.ietf.org/shadow.html or=20 > >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE > >>/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiatio n-01.txt". > >>=09 > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >>Below is the data which will enable a MIME compliant mail reader=20 > >>implementation to automatically retrieve the ASCII version of the=20 > >>Internet-Draft. > >> > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Feb 02 07:48:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCxq0-0007LZ-5S; Fri, 02 Feb 2007 07:48:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCxpy-0007LS-IO for mmusic@ietf.org; Fri, 02 Feb 2007 07:48:18 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCxpv-0007bE-9i for mmusic@ietf.org; Fri, 02 Feb 2007 07:48:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Date: Fri, 2 Feb 2007 14:44:05 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C730CCA@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Thread-Index: AcdGKCqE71HP19xKTeO4cV1c5WwDtQAgaj1gAAd/65s= References: <026F8EEDAD2C4342A993203088C1FC05045952C2@esealmw109.eemea.ericsson.se> From: "Even, Roni" To: "Ingemar Johansson S \(LU/EAB\)" , "Robert R. Gilman" X-Spam-Score: 0.1 (/) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0971862198==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0971862198== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C746C8.61EF4F27" This is a multi-part message in MIME format. ------_=_NextPart_001_01C746C8.61EF4F27 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, In the purposed work you can specify some configurations of capar=3Da = parmeters and only one payload if you wish so, and then use in the pcfg = this payload with diferent a=3D parameter for each alternative. pcfg:1 m=3D1 a=3D1/ m=3D1 a=3D2 .... =20 Roni Even ________________________________ =EE=E0=FA: Ingemar Johansson S (LU/EAB) = [mailto:ingemar.s.johansson@ericsson.com] =F0=F9=EC=E7: =E5 02/02/2007 11:44 =E0=EC: Robert R. Gilman =F2=E5=FA=F7 =EC=E9=E3=E9=F2=E4: mmusic@ietf.org =F0=E5=F9=E0: RE: [MMUSIC] = I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Hi The problem that I (and others?) see is that given all the possible permutation of codec options, payload format options the SDP's easily become really huge. It is true that it is possible to compress the SDP e.g using SigComp but still I find it a bit peculiar. Ideally I would like to have the possibility to select the various parameters in the response, sort of like selecting from a "smorgasbord". As it is in the example below you essentially need to specify a payload type for each permutation while it should in the case below be enough with just two payload types at the most (one for AMR and one for AMR-WB). I don't know of how much use this is, just that find "these specify by means of permutations" a bit odd. Ingemar > -----Original Message----- > From: Robert R. Gilman [mailto:rrg@avaya.com] > Sent: den 1 februari 2007 18:41 > To: Ingemar Johansson S (LU/EAB) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] > I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt > > Ingemar- > The current draft describes version 0 of the capability > negotiation, and is intended only to satisfy the immediate > need for a method to offer choices of STRP or unencrypted > transports. Our intent is to let it stand alone so that it > may be quickly reviewed, approved, and put into practice. > You didn't say what you wanted to do with the cap > negotiation, but, if the existing SDP is sufficient, then you > don't have to do anything. However, if you're looking for a > way to propose configurations that select a subset of the > codecs declared on the m-line, the next docuement in the > series (version 1) will include extensions to the pcfg: > attribute to handle the definition of codecs and formats at > the session level which can be referenced at the media level, > along with the codecs declared in the media line. The syntax > is defined along the lines of an earlier proposal I sent to the list. > We hope to have an initial v1 draft available on this list by Monday. > To speak to this example, assuming I want to propose > configurations with only one of the codecs specified, the SDP > might look like: > > a=3Dcreq:1 > m=3Daudio 49152 RTP/AVP 97 98 99 100 > a=3Drtpmap:97 AMR-WB/16000/1 > a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > a=3Drtpmap:98 AMR-WB/16000/1 > a=3Dfmtp:98 mode-change-capability=3D2; max-red=3D220; = octet-align=3D1 > a=3Drtpmap:99 AMR/8000/1 > a=3Dfmtp:99 mode-change-capability=3D2; max-red=3D220 > a=3Drtpmap:100 AMR/8000/1 > a=3Dfmtp:100 mode-change-capability=3D2; max-red=3D220; = octet-align=3D1 > a=3Dptime:20 > a=3Dmaxptime:240 > a=3Dpcfg:1 m=3D1/2/3/4 > > The m parameter in the pcfg: attribute specifies the codes by > ordinal in the order they are declared. Commas are used to > group codecs for simultaneous use, and slashes separate > alternatives. This should all look familiar from the > original -00 draft. BTW, v1 also includes a method to define > codecs outside of the media line if it's desirable to exclude > them from the "default" > configuration implied by the media line itself. > -Bob > ---------------------------------------------------- > Bob Gilman rrg@avaya.com +1 303 538 3868 > > Ingemar Johansson S (LU/EAB) wrote: > > Hi > > > > I am currently reading and trying to understand the draft, as an > > example I take a SDP offer taken from 3GPP TS26.114 version 1.20 > > http://www.3gpp.org/ftp/Specs/html-info/26114.htm > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > m=3Daudio 49152 RTP/AVP 97 98 99 100 > > a=3Drtpmap:97 AMR-WB/16000/1 > > a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > > a=3Drtpmap:98 AMR-WB/16000/1 > > a=3Dfmtp:98 mode-change-capability=3D2; max-red=3D220; = octet-align=3D1 > > a=3Drtpmap:99 AMR/8000/1 > > a=3Dfmtp:99 mode-change-capability=3D2; max-red=3D220 a=3Drtpmap:100 > > AMR/8000/1 a=3Dfmtp:100 mode-change-capability=3D2; max-red=3D220; > > octet-align=3D1 a=3Dptime:20 a=3Dmaxptime:240 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > > Using the sdp-capability-negotiation draft I manage to get as far as > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > m=3Daudio 49152 RTP/AVP 97 98 > > a=3Dcreq: v0 > > a=3Dcapar: 1 a=3Drtpmap:97 AMR-WB/16000/1 > > a=3Dcapar: 2 a=3Drtpmap:98 AMR-NB/8000/1 > > a=3Dcapar: 3 a=3Dmode-change-capability=3D2; max-red=3D220 > > a=3Dcapar: 4 a=3Dmode-change-capability=3D2; max-red=3D220; = octet-align=3D1 > > a=3Dptime:20 a=3Dmaxptime:240 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > > I know this is wrong, for instance I don't manage to fit > the a=3Dfmtp.. > > line anywhere, can soembody help ? > > > > Also, what would a response look like ? > > > > Regards > > Ingemar > > > > > >>-----Original Message----- > >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>Sent: den 29 januari 2007 21:50 > >>To: i-d-announce@ietf.org > >>Cc: mmusic@ietf.org > >>Subject: [MMUSIC] > >>I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.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 : SDP Capability Negotiation > >> Author(s) : F. Andreasen > >> Filename : > >>draft-ietf-mmusic-sdp-capability-negotiation-01.txt > >> Pages : 29 > >> Date : 2007-1-29 > >> =20 > >>The Session Description Protocol (SDP) was intended for describing > >> multimedia sessions for the purposes of session > announcement, > >>session > >> invitation, and other forms of multimedia session > initiation. > >>SDP was > >> not intended to provide capability indication or capability > >> negotiation, however over the years, SDP has seen > widespread > >>adoption > >> and as a result it has been gradually extended to provide > >>limited > >> support for these. SDP and its current extensions > however do > >>not have > >> the ability to negotiate one or more alternative transport > >>protocols > >> (e.g. RTP profiles) which makes it particularly > difficult to > >>deploy > >> new RTP profiles such as secure RTP or RTP with RTCP-based > >>feedback. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capa > >>bility-negotiation-01.txt > >> > >>To remove yourself from the I-D Announcement list, send a > message to > >>i-d-announce-request@ietf.org with the word unsubscribe in > the body of > >>the message. > >>You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > >>to change your subscription settings. > >> > >>Internet-Drafts are also available by anonymous FTP. Login with the > >>username "anonymous" and a password of your e-mail address. After > >>logging in, type "cd internet-drafts" and then "get > >>draft-ietf-mmusic-sdp-capability-negotiation-01.txt". > >> > >>A list of Internet-Drafts directories can be found in > >>http://www.ietf.org/shadow.html or > >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE > >>/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiatio n-01.txt". > >> =20 > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant > mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >>Below is the data which will enable a MIME compliant mail reader > >>implementation to automatically retrieve the ASCII version of the > >>Internet-Draft. > >> > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C746C8.61EF4F27 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] = I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt=0A= =0A= =0A= =0A=
Hi,
=0A=
In the purposed work you can = specify some configurations of capar=3Da parmeters and only one payload = if you wish so, and then use in the pcfg this payload with diferent = a=3D parameter for each alternative.
=0A=
pcfg:1 m=3D1 a=3D1/ m=3D1 = a=3D2 ....
=0A=
 
=0A=
Roni Even
=0A=

=0A=
=0A=
=0A=
=0A=
=EE=E0=FA: Ingemar = Johansson S (LU/EAB) = [mailto:ingemar.s.johansson@ericsson.com]
=F0=F9=EC=E7: =E5 = 02/02/2007 11:44
=E0=EC: Robert R. Gilman
=F2=E5=FA=F7 = =EC=E9=E3=E9=F2=E4: mmusic@ietf.org
=F0=E5=F9=E0: RE: = [MMUSIC] = I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt
<= BR>
=0A=
=0A=

Hi

The problem that I (and others?) see is that = given all the possible
permutation of codec options, payload format = options the SDP's easily
become really huge. It is true that it is = possible to compress the SDP
e.g using SigComp but still I find it a = bit peculiar.

Ideally I would like to have the possibility to = select the various
parameters in the response, sort of like selecting = from a "smorgasbord".
As it is in the example below you essentially = need to specify a payload
type for each permutation while it should = in the case below be enough
with just two payload types at the most = (one for AMR and one for
AMR-WB).
I don't know of how much use = this is, just that find "these specify by
means of permutations" a = bit odd.

Ingemar

> -----Original Message-----
> = From: Robert R. Gilman [mailto:rrg@avaya.com]
> Sent: = den 1 februari 2007 18:41
> To: Ingemar Johansson S = (LU/EAB)
> Cc: mmusic@ietf.org
> Subject: Re: = [MMUSIC]
> = I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt
>
= > Ingemar-
> The current draft describes version 0 of the = capability
> negotiation, and is intended only to satisfy the = immediate
> need for a method to offer choices of STRP or = unencrypted
> transports.  Our intent is to let it stand = alone so that it
> may be quickly reviewed, approved, and put into = practice.
> You didn't say what you wanted to do with the = cap
> negotiation, but, if the existing SDP is sufficient, then = you
> don't have to do anything. However, if you're looking for = a
> way to propose configurations that select a subset of = the
> codecs declared on the m-line, the next docuement in = the
> series (version 1) will include extensions to the = pcfg:
> attribute to handle the definition of codecs and formats = at
> the session level which can be referenced at the media = level,
> along with the codecs declared in the media line.  = The syntax
> is defined along the lines of an earlier proposal I = sent to the list.
> We hope to have an initial v1 draft available = on this list by Monday.
> To speak to this example, assuming I = want to propose
> configurations with only one of the codecs = specified, the SDP
> might look like:
>
>   = a=3Dcreq:1
>   m=3Daudio 49152 RTP/AVP 97 98 99 = 100
>   a=3Drtpmap:97 AMR-WB/16000/1
>   = a=3Dfmtp:97 mode-change-capability=3D2; = max-red=3D220
>   a=3Drtpmap:98 = AMR-WB/16000/1
>   a=3Dfmtp:98 = mode-change-capability=3D2; max-red=3D220; = octet-align=3D1
>   a=3Drtpmap:99 = AMR/8000/1
>   a=3Dfmtp:99 mode-change-capability=3D2; = max-red=3D220
>   a=3Drtpmap:100 = AMR/8000/1
>   a=3Dfmtp:100 mode-change-capability=3D2; = max-red=3D220; octet-align=3D1
>   = a=3Dptime:20
>   a=3Dmaxptime:240
>   = a=3Dpcfg:1 m=3D1/2/3/4
>
> The m parameter in the pcfg: = attribute specifies the codes by
> ordinal in the order they are = declared.  Commas are used to
> group codecs for simultaneous = use, and slashes separate
> alternatives.  This should all = look familiar from the
> original -00 draft.  BTW, v1 also = includes a method to define
> codecs outside of the media line if = it's desirable to exclude
> them from the "default"
> = configuration implied by the media line itself.
> -Bob
> = ----------------------------------------------------
> Bob = Gilman       = rrg@avaya.com      +1 303 538 = 3868
>
> Ingemar Johansson S (LU/EAB) wrote:
> > = Hi
> >
> > I am currently reading and trying to = understand the draft, as an
> > example I take a SDP offer = taken from 3GPP TS26.114 version 1.20
> > http://www.3gp= p.org/ftp/Specs/html-info/26114.htm
> >
> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
> > m=3Daudio 49152 RTP/AVP 97 98 99 100
> > = a=3Drtpmap:97 AMR-WB/16000/1
> > a=3Dfmtp:97 = mode-change-capability=3D2; max-red=3D220
> > a=3Drtpmap:98 = AMR-WB/16000/1
> > a=3Dfmtp:98 mode-change-capability=3D2; = max-red=3D220; octet-align=3D1
> > a=3Drtpmap:99 = AMR/8000/1
> > a=3Dfmtp:99 mode-change-capability=3D2; = max-red=3D220 a=3Drtpmap:100
> > AMR/8000/1 a=3Dfmtp:100 = mode-change-capability=3D2; max-red=3D220;
> > octet-align=3D1 = a=3Dptime:20 a=3Dmaxptime:240 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
> >
> > Using the sdp-capability-negotiation = draft I manage to get as far as
> >
> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
> > m=3Daudio 49152 RTP/AVP 97 98
> > a=3Dcreq: = v0
> > a=3Dcapar: 1 a=3Drtpmap:97 AMR-WB/16000/1
> > = a=3Dcapar: 2 a=3Drtpmap:98 AMR-NB/8000/1
> > a=3Dcapar: 3 = a=3Dmode-change-capability=3D2; max-red=3D220
> > a=3Dcapar: 4 = a=3Dmode-change-capability=3D2; max-red=3D220;  = octet-align=3D1
> > a=3Dptime:20 a=3Dmaxptime:240 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
> >
> > I know this is wrong, for instance I = don't manage to fit
> the a=3Dfmtp..
> > line anywhere, = can soembody help ?
> >
> > Also, what would a = response look like ?
> >
> > Regards
> > = Ingemar
> >
> >
> >>-----Original = Message-----
> >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org<= /A>]
> >>Sent: den 29 januari 2007 21:50
> >>To: = i-d-announce@ietf.org
> >>Cc: mmusic@ietf.org
> = >>Subject: [MMUSIC]
> = >>I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.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   =         : SDP Capability = Negotiation
> >>    = Author(s)       : F. Andreasen
> = >>    = Filename        :
> = >>draft-ietf-mmusic-sdp-capability-negotiation-01.txt
> = >>    Pages   =         : 29
> = >>    Date    =         : 2007-1-29
> = >>   
> >>The Session Description = Protocol (SDP) was intended for describing
> = >>        multimedia sessions = for the purposes of session
> announcement,
> = >>session
> = >>        invitation, and other = forms of multimedia session
> initiation.
> >>SDP = was
> >>        not = intended to provide capability indication or capability
> = >>        negotiation, however = over the years, SDP has seen
> widespread
> = >>adoption
> = >>        and as a result it = has been gradually extended to provide
> >>limited
> = >>        support for these. = SDP and its current extensions
> however do
> >>not = have
> >>        the = ability to negotiate one or more alternative transport
> = >>protocols
> = >>        (e.g. RTP profiles) = which makes it particularly
> difficult to
> = >>deploy
> = >>        new RTP profiles such = as secure RTP or RTP with RTCP-based
> >>feedback.
> = >>
> >>A URL for this Internet-Draft is:
> = >>h= ttp://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capa
>= >>bility-negotiation-01.txt
> >>
> >>To = remove yourself from the I-D Announcement list, send a
> message = to
> >>i-d-announce-request@ietf.org with the word = unsubscribe in
> the body of
> >>the message.
> = >>You can also visit
> https://www1= .ietf.org/mailman/listinfo/I-D-announce
> >>to change = your subscription settings.
> >>
> = >>Internet-Drafts are also available by anonymous FTP. Login with = the
> >>username "anonymous" and a password of your e-mail = address. After
> >>logging in, type "cd internet-drafts" and = then "get
> = >>draft-ietf-mmusic-sdp-capability-negotiation-01.txt".
> = >>
> >>A list of Internet-Drafts directories can be = found in
> >>http://www.ietf.org/shadow.html<= /A> or
> >>ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
> >>
> >>Internet-Drafts = can also be obtained by e-mail.
> >>
> >>Send a = message to:
> >>    = mailserv@ietf.org.
> >>In the body type:
> = >>    "FILE
> = >>/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiatio
n= -01.txt".
> >>   
> = >>NOTE:       The mail server at = ietf.org can return the document in
> >>    = MIME-encoded form by using the "mpack" utility.  To use = this
> >>    feature, insert the command = "ENCODING mime" before the "FILE"
> >>    = command.  To decode the response(s), you will need "munpack" = or
> >>    a MIME-compliant mail = reader.  Different MIME-compliant
> mail readers
> = >>    exhibit different behavior, especially when = dealing with
> >>    "multipart" MIME = messages (i.e. documents which have been split
> = >>    up into multiple messages), so check your = local documentation on
> >>    how to = manipulate these messages.
> >>
> >>Below is the = data which will enable a MIME compliant mail reader
> = >>implementation to automatically retrieve the ASCII version of = the
> >>Internet-Draft.
> >>
> = >
> >
> > = _______________________________________________
> > mmusic = mailing list
> > mmusic@ietf.org
> > https://www1.ietf.= org/mailman/listinfo/mmusic
>
>

__________________= _____________________________
mmusic mailing = list
mmusic@ietf.org
https://www1.ietf.= org/mailman/listinfo/mmusic

------_=_NextPart_001_01C746C8.61EF4F27-- --===============0971862198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0971862198==-- From mmusic-bounces@ietf.org Fri Feb 02 12:32:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2GZ-0005Nh-L3; Fri, 02 Feb 2007 12:32:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2GY-0005NX-8j for mmusic@ietf.org; Fri, 02 Feb 2007 12:32:02 -0500 Received: from 103.12.152.198.in-addr.arpa ([198.152.12.103] helo=nj300815-ier2.net.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD2GW-0005C3-LA for mmusic@ietf.org; Fri, 02 Feb 2007 12:32:02 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l12HVxNM024392 for ; Fri, 2 Feb 2007 12:31:59 -0500 Received: from [135.148.75.217] ([135.148.75.217]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Feb 2007 10:31:58 -0700 Message-ID: <45C37589.5000306@avaya.com> Date: Fri, 02 Feb 2007 10:31:53 -0700 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ingemar Johansson S (LU/EAB)" Subject: Re: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt References: <026F8EEDAD2C4342A993203088C1FC05045952C2@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05045952C2@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 17:31:58.0965 (UTC) FILETIME=[0ABDBA50:01C746F0] X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Ingemar- Now I understand your point (with Roni's help). Your example, which applies to both existing SDP and to our proposals, requires that the same rtpmap: and fmtp: lines be repeated for each coded/payload type to which they apply. You'd like some sort of late binding that could tie the rtpmap: and fmtp: lines in the pcfg: lines. Roni gave one example of how this might be done. We need to figure out how to group the codec/attribute associations in such a way that we can also specify multiple codecs in the same line. For example, we've talked about defining codecs with a cmed: attribute like a=cmed:1 audio PCMU G729 L16 events This attribute assigns numbers (1,2,3,4 in this case) to the mime subtypes listed. Then we define two additional attributes (much like the rtpmap and fmtp: attributes) to specify the encoding rates, etc. and any unique formatting parameters. Those attributes look like: a=cenc:3 16000/2 a=cfmt:2 annexb:no where we tied them to the subtype numbers. Your example would become something like a=cmed:1 audio AMR AMR AMR AMR a=cfmt:1 mode-change-capability=2; max-red=220 a=cfmt:2 mode-change-capability=2; max-red=220; octet-align=1 ... a=cenc:1 16000/1 a=cenc:2 16000/1 ... m=audio 49152 RTP/AVP 97 98 99 100 a=pcfg: m=1|2|3|4 which wouldn't save any space for us. (We could put the cenc: parameters up on the cenc: attribute with the mime subtype (e.g., AMR/16000/1) so the cenc: paramters look just like the rtpmap: parameters, but that's not much help.) You'd like to see something like: a=cmed:1 AMR a=cfmt:1 mode-change-capability=2; max-red=220 a=cfmt:2 mode-change-capability=2; max-red=220; octet-align=1 a=cenc:1 16000/1 a=cenc:2 8000/1 m=audio 49152 RTP/AVP 97 a=rtpmap:97 AMR/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220 pcfg:1 m=(1 f=2 e=1 pt=98)/(1 f=1 e=2 pt=99)/(1 f=2 e=2 pt=100) where the f= and e= parameters tie cfmt and cenc lines, respectively, to a media codec specified in a cmed: line, and the pt= parameter is the associated payload type. I've include a default case for those endpoints (or middleboxes) that don't understand the cap negotiation. Is this more like what you had in mind? -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Ingemar Johansson S (LU/EAB) wrote: > Hi > > The problem that I (and others?) see is that given all the possible > permutation of codec options, payload format options the SDP's easily > become really huge. It is true that it is possible to compress the SDP > e.g using SigComp but still I find it a bit peculiar. > > Ideally I would like to have the possibility to select the various > parameters in the response, sort of like selecting from a "smorgasbord". > As it is in the example below you essentially need to specify a payload > type for each permutation while it should in the case below be enough > with just two payload types at the most (one for AMR and one for > AMR-WB). > I don't know of how much use this is, just that find "these specify by > means of permutations" a bit odd. > > Ingemar > > >>-----Original Message----- >>From: Robert R. Gilman [mailto:rrg@avaya.com] >>Sent: den 1 februari 2007 18:41 >>To: Ingemar Johansson S (LU/EAB) >>Cc: mmusic@ietf.org >>Subject: Re: [MMUSIC] >>I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt >> >>Ingemar- >>The current draft describes version 0 of the capability >>negotiation, and is intended only to satisfy the immediate >>need for a method to offer choices of STRP or unencrypted >>transports. Our intent is to let it stand alone so that it >>may be quickly reviewed, approved, and put into practice. >>You didn't say what you wanted to do with the cap >>negotiation, but, if the existing SDP is sufficient, then you >>don't have to do anything. However, if you're looking for a >>way to propose configurations that select a subset of the >>codecs declared on the m-line, the next docuement in the >>series (version 1) will include extensions to the pcfg: >>attribute to handle the definition of codecs and formats at >>the session level which can be referenced at the media level, >>along with the codecs declared in the media line. The syntax >>is defined along the lines of an earlier proposal I sent to the list. >>We hope to have an initial v1 draft available on this list by Monday. >>To speak to this example, assuming I want to propose >>configurations with only one of the codecs specified, the SDP >>might look like: >> >> a=creq:1 >> m=audio 49152 RTP/AVP 97 98 99 100 >> a=rtpmap:97 AMR-WB/16000/1 >> a=fmtp:97 mode-change-capability=2; max-red=220 >> a=rtpmap:98 AMR-WB/16000/1 >> a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 >> a=rtpmap:99 AMR/8000/1 >> a=fmtp:99 mode-change-capability=2; max-red=220 >> a=rtpmap:100 AMR/8000/1 >> a=fmtp:100 mode-change-capability=2; max-red=220; octet-align=1 >> a=ptime:20 >> a=maxptime:240 >> a=pcfg:1 m=1/2/3/4 >> >>The m parameter in the pcfg: attribute specifies the codes by >>ordinal in the order they are declared. Commas are used to >>group codecs for simultaneous use, and slashes separate >>alternatives. This should all look familiar from the >>original -00 draft. BTW, v1 also includes a method to define >>codecs outside of the media line if it's desirable to exclude >>them from the "default" >>configuration implied by the media line itself. >>-Bob >>---------------------------------------------------- >>Bob Gilman rrg@avaya.com +1 303 538 3868 >> >>Ingemar Johansson S (LU/EAB) wrote: >> >>>Hi >>> >>>I am currently reading and trying to understand the draft, as an >>>example I take a SDP offer taken from 3GPP TS26.114 version 1.20 >>>http://www.3gpp.org/ftp/Specs/html-info/26114.htm >>> >>>=========================== >>>m=audio 49152 RTP/AVP 97 98 99 100 >>>a=rtpmap:97 AMR-WB/16000/1 >>>a=fmtp:97 mode-change-capability=2; max-red=220 >>>a=rtpmap:98 AMR-WB/16000/1 >>>a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 >>>a=rtpmap:99 AMR/8000/1 >>>a=fmtp:99 mode-change-capability=2; max-red=220 a=rtpmap:100 >>>AMR/8000/1 a=fmtp:100 mode-change-capability=2; max-red=220; >>>octet-align=1 a=ptime:20 a=maxptime:240 =========================== >>> >>>Using the sdp-capability-negotiation draft I manage to get as far as >>> >>>=========================== >>>m=audio 49152 RTP/AVP 97 98 >>>a=creq: v0 >>>a=capar: 1 a=rtpmap:97 AMR-WB/16000/1 >>>a=capar: 2 a=rtpmap:98 AMR-NB/8000/1 >>>a=capar: 3 a=mode-change-capability=2; max-red=220 >>>a=capar: 4 a=mode-change-capability=2; max-red=220; octet-align=1 >>>a=ptime:20 a=maxptime:240 =========================== >>> >>>I know this is wrong, for instance I don't manage to fit >> >>the a=fmtp.. >> >>>line anywhere, can soembody help ? >>> >>>Also, what would a response look like ? >>> >>>Regards >>>Ingemar >>> >>> >>> >>>>-----Original Message----- >>>>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>>Sent: den 29 januari 2007 21:50 >>>>To: i-d-announce@ietf.org >>>>Cc: mmusic@ietf.org >>>>Subject: [MMUSIC] >>>>I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.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 : SDP Capability Negotiation >>>> Author(s) : F. Andreasen >>>> Filename : >>>>draft-ietf-mmusic-sdp-capability-negotiation-01.txt >>>> Pages : 29 >>>> Date : 2007-1-29 >>>> >>>>The Session Description Protocol (SDP) was intended for describing >>>> multimedia sessions for the purposes of session >> >>announcement, >> >>>>session >>>> invitation, and other forms of multimedia session >> >>initiation. >> >>>>SDP was >>>> not intended to provide capability indication or capability >>>> negotiation, however over the years, SDP has seen >> >>widespread >> >>>>adoption >>>> and as a result it has been gradually extended to provide >>>>limited >>>> support for these. SDP and its current extensions >> >>however do >> >>>>not have >>>> the ability to negotiate one or more alternative transport >>>>protocols >>>> (e.g. RTP profiles) which makes it particularly >> >>difficult to >> >>>>deploy >>>> new RTP profiles such as secure RTP or RTP with RTCP-based >>>>feedback. >>>> >>>>A URL for this Internet-Draft is: >>>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capa >>>>bility-negotiation-01.txt >>>> >>>>To remove yourself from the I-D Announcement list, send a >> >>message to >> >>>>i-d-announce-request@ietf.org with the word unsubscribe in >> >>the body of >> >>>>the message. >>>>You can also visit >> >>https://www1.ietf.org/mailman/listinfo/I-D-announce >> >>>>to change your subscription settings. >>>> >>>>Internet-Drafts are also available by anonymous FTP. Login with the >>>>username "anonymous" and a password of your e-mail address. After >>>>logging in, type "cd internet-drafts" and then "get >>>>draft-ietf-mmusic-sdp-capability-negotiation-01.txt". >>>> >>>>A list of Internet-Drafts directories can be found in >>>>http://www.ietf.org/shadow.html or >>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>>Internet-Drafts can also be obtained by e-mail. >>>> >>>>Send a message to: >>>> mailserv@ietf.org. >>>>In the body type: >>>> "FILE >>>>/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiatio > > n-01.txt". > >>>> >>>>NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant >> >>mail readers >> >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>>Below is the data which will enable a MIME compliant mail reader >>>>implementation to automatically retrieve the ASCII version of the >>>>Internet-Draft. >>>> >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >> >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 05 08:15:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3fo-0001Fq-7Z; Mon, 05 Feb 2007 08:14:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3fm-0001Fl-JQ for mmusic@ietf.org; Mon, 05 Feb 2007 08:14:18 -0500 Received: from web59203.mail.re1.yahoo.com ([66.196.101.29]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HE3fg-0001Wz-BS for mmusic@ietf.org; Mon, 05 Feb 2007 08:14:18 -0500 Received: (qmail 58261 invoked by uid 60001); 5 Feb 2007 13:14:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=OyJsemRFNxVmqf3m3sOv8NPAEHpY2kkR2LfI1TrcW6KcVmc8fN0+FhL1ZFcqOm9oB3FXqKuQ5Eb10T5KaomEs5Dsnfni50WOXEQRbL/jkZOd9Ypz3KSrkeuy+3D3NDzLHVJ9n8NHzeLCUcNbrDR14PpbEPvxEhuoNXG6MGvAXgY=; X-YMail-OSG: XWwDJ.oVM1mLGUq4ZoAn3JUONoStJO_PnREUvnZXoQWlgofsvLV3vYsWK3IN6m34GxcxkTzHv_1px1ovYop8U4h3pH4JXd2yN_m1bORx5n_.ND6V15ilxg-- Received: from [194.200.65.239] by web59203.mail.re1.yahoo.com via HTTP; Mon, 05 Feb 2007 05:14:12 PST Date: Mon, 5 Feb 2007 05:14:12 -0800 (PST) From: Fabrice Triboix To: mmusic@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <176645.57385.qm@web59203.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [MMUSIC] What happens to RTP timestamps after an RTSP PAUSE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hello, I am currently working on an RTSP/RTP implementation, and I wonder what a streaming server is meant to do with RTP timestamps after an RTSP PAUSE followed (after a few seconds, for example), by a PLAY. There are 2 possibilities for the first RTP packet after the PLAY: - Its timestamp is the last RTP packet's timestamp + duration of the last RTP packet - Or: the previous value + duration in "real time" between PAUSE and PLAY I tried to find some information on the internet, and apparently the second option is more likely. The problem is that I can't find any RFC or other standard documents elaborating on this situation... Thank you very much for your help! Fabrice Triboix ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 05 08:59:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4NK-0000ff-Jl; Mon, 05 Feb 2007 08:59:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4NJ-0000fW-1m for mmusic@ietf.org; Mon, 05 Feb 2007 08:59:17 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE4NH-00012v-Oc for mmusic@ietf.org; Mon, 05 Feb 2007 08:59:17 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62159 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HE4NH-0003U5-3w; Mon, 05 Feb 2007 13:59:15 +0000 In-Reply-To: <176645.57385.qm@web59203.mail.re1.yahoo.com> References: <176645.57385.qm@web59203.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78D9A3F2-B102-4ED5-843D-F2E7B1853EA0@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] What happens to RTP timestamps after an RTSP PAUSE? Date: Mon, 5 Feb 2007 13:59:16 +0000 To: Fabrice Triboix X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 5 Feb 2007, at 13:14, Fabrice Triboix wrote: > I am currently working on an RTSP/RTP implementation, > and I wonder what a streaming server is meant to do > with RTP timestamps after an RTSP PAUSE followed > (after a few seconds, for example), by a PLAY. > > There are 2 possibilities for the first RTP packet > after the PLAY: > - Its timestamp is the last RTP packet's timestamp + > duration of the last RTP packet > - Or: the previous value + duration in "real time" > between PAUSE and PLAY > > I tried to find some information on the internet, and > apparently the second option is more likely. The > problem is that I can't find any RFC or other standard > documents elaborating on this situation... The second option is correct. RFC 3550 section 5.1. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 05 11:37:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6pX-0003qH-EP; Mon, 05 Feb 2007 11:36:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6pW-0003ol-SA for mmusic@ietf.org; Mon, 05 Feb 2007 11:36:34 -0500 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE6pV-0005W3-MW for mmusic@ietf.org; Mon, 05 Feb 2007 11:36:34 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1646984wxd for ; Mon, 05 Feb 2007 08:36:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=T3hwJ24ikRr7WyoYAmLdgQWlSbeNw5IW191WScCi/a+UKPFdx6vR7cNGZ6cgT5/7gan999ZPXt8WY+Yv90hICLM9WAzJKMfPP/L13bb9z5tymcnyPNkbMbAv3DlBgjN3G2jbvAWx1CR5/UfLU3G+RKKDzESnSty5bDeKtQp+SHE= Received: by 10.90.94.2 with SMTP id r2mr8991959agb.1170693393206; Mon, 05 Feb 2007 08:36:33 -0800 (PST) Received: by 10.90.98.17 with HTTP; Mon, 5 Feb 2007 08:36:33 -0800 (PST) Message-ID: <458913680702050836m14b65f59p646de02336e64743@mail.gmail.com> Date: Mon, 5 Feb 2007 17:36:33 +0100 From: "Xavier Marjou" To: "Fabrice Triboix" Subject: Re: [MMUSIC] What happens to RTP timestamps after an RTSP PAUSE? In-Reply-To: <78D9A3F2-B102-4ED5-843D-F2E7B1853EA0@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <176645.57385.qm@web59203.mail.re1.yahoo.com> <78D9A3F2-B102-4ED5-843D-F2E7B1853EA0@csperkins.org> X-Google-Sender-Auth: bd18b42c37a19aec X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is also documented in the annex "B.2.4 Handling RTP Timestamps after PAUSE" of draft-ietf-mmusic-rfc2326bis-14. Xavier _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 05 20:13:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEEso-0005zI-5E; Mon, 05 Feb 2007 20:12:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEEsm-0005yw-N8 for mmusic@ietf.org; Mon, 05 Feb 2007 20:12:28 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEEsl-0006Fu-7b for mmusic@ietf.org; Mon, 05 Feb 2007 20:12:28 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Feb 2007 17:12:26 -0800 X-IronPort-AV: i="4.13,285,1167638400"; d="scan'208"; a="109292391:sNHT43354134" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l161CQNb029518 for ; Mon, 5 Feb 2007 17:12:26 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l161CQUw000663 for ; Mon, 5 Feb 2007 17:12:26 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 17:12:25 -0800 Received: from [171.70.247.41] ([171.70.247.41]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 17:12:25 -0800 Message-ID: <45C7D5F9.1010907@cisco.com> Date: Mon, 05 Feb 2007 20:12:25 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2007 01:12:25.0938 (UTC) FILETIME=[DCF08320:01C7498B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2516; t=1170724346; x=1171588346; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotation=3A=20Minutes=20of=201/30/07=20d esign=20team=20conference=0A=20call |Sender:=20; bh=GeyQdKPGqD91T5Pw0G/YCLvwbJWlm5DrGt18XKHv188=; b=eZvVSg+MjBYtBMCjG342ndF7wHWwLQfPT5pTQ0gUk8NDMTRdjOIQPBl0EjY+MjB1FD9fJvPz rwUKW2fMUlSu/vaJLxm07MVIF8Y2mUgHH1UyKC5ByqoVAhrdSMyRojzH; Authentication-Results: sj-dkim-3; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [MMUSIC] SDP Capability Negotation: Minutes of 1/30/07 design team conference call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Greetings The SDP Capability Negotiation Design team had a conference call on 1/30/07. The attendees were: Flemming Andreasen Thomas Stach Roni Even Bob Gilman Colin Perkins Joerg Ott The SDP capability negotiation document has been split in two and the initial core framework document has been published in draft-ietf-mmusic-sdp-capability-negotiation-01.txt. The document notes an issue related to potential configurations, where the semantics currently differ between the session and the media level, yet the same attribute is used for this. The design team agreed to the different semantics (latent capability at session-level and actual offer at the media level), however the team also felt there should be two different attributes for this. Colin noted that the core framework does not actully use latent potential configuration at the session-level, so we can leave this out of the core and instead include it in the media capabilities document, which is being worked separately. The team agreed with this. Transport capabilities are currently numbered from 1, and the transport capability from the "m=" line must be included explicitly as a capability. It would be more efficient to say that transport capability 0 is the transport protocol from the "m=" line. The reason this is not done however is due to concerns with middle-boxes changing "m=" lines (e.g. to translate between RTP and SRTP) while allowing unknown attributes to pass through, in which case the implicitly referenced transport capability has now been changed with potential errors and inconsistencies as a result. The document will clarify this reasoning. Media Processing before answer was discussed as well. When a potential configuration is selected by the answerer, the offerer may not be able to process media correctly before receiving the answer. Previously, it was possible to e.g. assign different payload types to RTP and SRTP and then differentiate based on that (although keying may still be an issue). The core document does not enable this functionality; instead media capabilities will be needed (or alternative heuristics or methods employed). Joerg had provided an extensive review of the document as well, and the comments (as well as other comments received subsequently) will be addressed in the next version of the document. Work is also ongoing on the media capabilities document. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 06 08:26:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQKT-0006Us-F6; Tue, 06 Feb 2007 08:25:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQKR-0006Un-QZ for mmusic@ietf.org; Tue, 06 Feb 2007 08:25:47 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEQKJ-00018M-Pm for mmusic@ietf.org; Tue, 06 Feb 2007 08:25:47 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 08BAA20F23; Tue, 6 Feb 2007 14:25:35 +0100 (CET) X-AuditID: c1b4fb3e-aeed1bb0000007e1-49-45c881cefc4a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DDFA220248; Tue, 6 Feb 2007 14:25:34 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 14:25:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Date: Tue, 6 Feb 2007 14:25:32 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05045D01AF@esealmw109.eemea.ericsson.se> In-Reply-To: <45C37589.5000306@avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Thread-Index: AcdG8HVjt0erjdUVQxKV3wEzGvk+/gC9T9hg From: "Ingemar Johansson S \(LU/EAB\)" To: "Robert R. Gilman" X-OriginalArrivalTime: 06 Feb 2007 13:25:34.0653 (UTC) FILETIME=[4841BED0:01C749F2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi I believe that your example below is pretty much in line with what I am looking for.=20 The purpose is to be able to avoid the numerous repeating of rtpmap and fmtp. In some cases this may lead to=20 One aditional example with the AMR codecs interacting with a media gateway is that one can select between several mode-sets and the different mode-sets must be connected to repeated rtpmap/fmtp like in the example below possibly there are different combinations between different mode-sets and mode-change-periods and mode-change-neighbor leading to a bunch of permutations. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D m=3Daudio 49152 RTP/AVP 97 98 a=3Drtpmap:97 AMR/8000/1 a=3Dfmtp:97 mode-set=3D0,2,4,7; mode-change-period=3D2, \ mode-change-neighbor=3D1; mode-change-capability=3D2; max-red=3D20 a=3Drtpmap:98 AMR/8000/1 a=3Dfmtp:98 mode-set=3D0,3,5,6; mode-change-period=3D2, \ mode-change-neighbor=3D1; mode-change-capability=3D2; max-red=3D20 a=3Dptime:20 a=3Dmaxptime:80 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D That said it is difficult to say how interesting the options below are, after all one will need to have some backwards compatibility and that may easily eat up the gain with the "compressed SDP syntax" below. Regards Ingemar=20 > -----Original Message----- > From: Robert R. Gilman [mailto:rrg@avaya.com]=20 > Sent: den 2 februari 2007 18:32 > To: Ingemar Johansson S (LU/EAB) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC]=20 > I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt >=20 > Ingemar- > Now I understand your point (with Roni's help). Your=20 > example, which applies to both existing SDP and to our=20 > proposals, requires that the same rtpmap: and fmtp: lines be=20 > repeated for each coded/payload type to which they apply. =20 > You'd like some sort of late binding that could tie the=20 > rtpmap: and fmtp: lines in the pcfg: lines. Roni gave one=20 > example of how this might be done. We need to figure out how=20 > to group the codec/attribute associations in such a way that=20 > we can also specify multiple codecs in the same line. For=20 > example, we've talked about defining codecs with a cmed:=20 > attribute like > a=3Dcmed:1 audio PCMU G729 L16 events > This attribute assigns numbers (1,2,3,4 in this case) to the=20 > mime subtypes listed. Then we define two additional=20 > attributes (much like the rtpmap and fmtp: attributes) to=20 > specify the encoding rates, etc. and any unique formatting=20 > parameters. Those attributes look like: > a=3Dcenc:3 16000/2 > a=3Dcfmt:2 annexb:no > where we tied them to the subtype numbers. > Your example would become something like > a=3Dcmed:1 audio AMR AMR AMR AMR > a=3Dcfmt:1 mode-change-capability=3D2; max-red=3D220 > a=3Dcfmt:2 mode-change-capability=3D2; max-red=3D220; octet-align=3D1 > ... > a=3Dcenc:1 16000/1 > a=3Dcenc:2 16000/1 > ... > m=3Daudio 49152 RTP/AVP 97 98 99 100 > a=3Dpcfg: m=3D1|2|3|4 >=20 > which wouldn't save any space for us. (We could put the=20 > cenc: parameters up on the cenc: attribute with the mime=20 > subtype (e.g., AMR/16000/1) so the > cenc: paramters look just like the rtpmap: parameters, but=20 > that's not much > help.) You'd like to see something like: >=20 > a=3Dcmed:1 AMR > a=3Dcfmt:1 mode-change-capability=3D2; max-red=3D220 > a=3Dcfmt:2 mode-change-capability=3D2; max-red=3D220; octet-align=3D1 > a=3Dcenc:1 16000/1 > a=3Dcenc:2 8000/1 > m=3Daudio 49152 RTP/AVP 97 > a=3Drtpmap:97 AMR/16000/1 > a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > pcfg:1 m=3D(1 f=3D2 e=3D1 pt=3D98)/(1 f=3D1 e=3D2 pt=3D99)/(1 f=3D2 = e=3D2 pt=3D100) >=20 > where the f=3D and e=3D parameters tie cfmt and cenc lines,=20 > respectively, to a media codec specified in a cmed: line, and=20 > the pt=3D parameter is the associated payload type. I've=20 > include a default case for those endpoints (or middleboxes)=20 > that don't understand the cap negotiation. > Is this more like what you had in mind? > -Bob > ---------------------------------------------------- > Bob Gilman rrg@avaya.com +1 303 538 3868 >=20 > Ingemar Johansson S (LU/EAB) wrote: > > Hi > >=20 > > The problem that I (and others?) see is that given all the possible=20 > > permutation of codec options, payload format options the=20 > SDP's easily=20 > > become really huge. It is true that it is possible to=20 > compress the SDP=20 > > e.g using SigComp but still I find it a bit peculiar. > >=20 > > Ideally I would like to have the possibility to select the various=20 > > parameters in the response, sort of like selecting from a=20 > "smorgasbord". > > As it is in the example below you essentially need to specify a=20 > > payload type for each permutation while it should in the=20 > case below be=20 > > enough with just two payload types at the most (one for AMR and one=20 > > for AMR-WB). > > I don't know of how much use this is, just that find "these=20 > specify by=20 > > means of permutations" a bit odd. > >=20 > > Ingemar > >=20 > >=20 > >>-----Original Message----- > >>From: Robert R. Gilman [mailto:rrg@avaya.com] > >>Sent: den 1 februari 2007 18:41 > >>To: Ingemar Johansson S (LU/EAB) > >>Cc: mmusic@ietf.org > >>Subject: Re: [MMUSIC] > >>I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt > >> > >>Ingemar- > >>The current draft describes version 0 of the capability=20 > negotiation,=20 > >>and is intended only to satisfy the immediate need for a method to=20 > >>offer choices of STRP or unencrypted transports. Our=20 > intent is to let=20 > >>it stand alone so that it may be quickly reviewed,=20 > approved, and put=20 > >>into practice. > >>You didn't say what you wanted to do with the cap=20 > negotiation, but, if=20 > >>the existing SDP is sufficient, then you don't have to do anything.=20 > >>However, if you're looking for a way to propose configurations that=20 > >>select a subset of the codecs declared on the m-line, the next=20 > >>docuement in the series (version 1) will include extensions to the=20 > >>pcfg: > >>attribute to handle the definition of codecs and formats at the=20 > >>session level which can be referenced at the media level,=20 > along with=20 > >>the codecs declared in the media line. The syntax is defined along=20 > >>the lines of an earlier proposal I sent to the list. > >>We hope to have an initial v1 draft available on this list=20 > by Monday. > >>To speak to this example, assuming I want to propose configurations=20 > >>with only one of the codecs specified, the SDP might look like: > >> > >> a=3Dcreq:1 > >> m=3Daudio 49152 RTP/AVP 97 98 99 100 > >> a=3Drtpmap:97 AMR-WB/16000/1 > >> a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > >> a=3Drtpmap:98 AMR-WB/16000/1 > >> a=3Dfmtp:98 mode-change-capability=3D2; max-red=3D220; = octet-align=3D1 > >> a=3Drtpmap:99 AMR/8000/1 > >> a=3Dfmtp:99 mode-change-capability=3D2; max-red=3D220 = a=3Drtpmap:100=20 > >> AMR/8000/1 a=3Dfmtp:100 mode-change-capability=3D2; max-red=3D220; = > >> octet-align=3D1 a=3Dptime:20 a=3Dmaxptime:240 > >> a=3Dpcfg:1 m=3D1/2/3/4 > >> > >>The m parameter in the pcfg: attribute specifies the codes=20 > by ordinal=20 > >>in the order they are declared. Commas are used to group=20 > codecs for=20 > >>simultaneous use, and slashes separate alternatives. This=20 > should all=20 > >>look familiar from the original -00 draft. BTW, v1 also includes a=20 > >>method to define codecs outside of the media line if it's=20 > desirable to=20 > >>exclude them from the "default" > >>configuration implied by the media line itself. > >>-Bob > >>---------------------------------------------------- > >>Bob Gilman rrg@avaya.com +1 303 538 3868 > >> > >>Ingemar Johansson S (LU/EAB) wrote: > >> > >>>Hi > >>> > >>>I am currently reading and trying to understand the draft, as an=20 > >>>example I take a SDP offer taken from 3GPP TS26.114 version 1.20=20 > >>>http://www.3gpp.org/ftp/Specs/html-info/26114.htm > >>> > = >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >>>m=3Daudio 49152 RTP/AVP 97 98 99 100 > >>>a=3Drtpmap:97 AMR-WB/16000/1 > >>>a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > >>>a=3Drtpmap:98 AMR-WB/16000/1 > >>>a=3Dfmtp:98 mode-change-capability=3D2; max-red=3D220; = octet-align=3D1 > >>>a=3Drtpmap:99 AMR/8000/1 > >>>a=3Dfmtp:99 mode-change-capability=3D2; max-red=3D220 = a=3Drtpmap:100 > >>>AMR/8000/1 a=3Dfmtp:100 mode-change-capability=3D2; max-red=3D220; > >>>octet-align=3D1 a=3Dptime:20 a=3Dmaxptime:240 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >>> > >>>Using the sdp-capability-negotiation draft I manage to get=20 > as far as > >>> > = >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >>>m=3Daudio 49152 RTP/AVP 97 98 > >>>a=3Dcreq: v0 > >>>a=3Dcapar: 1 a=3Drtpmap:97 AMR-WB/16000/1 > >>>a=3Dcapar: 2 a=3Drtpmap:98 AMR-NB/8000/1 > >>>a=3Dcapar: 3 a=3Dmode-change-capability=3D2; max-red=3D220 > >>>a=3Dcapar: 4 a=3Dmode-change-capability=3D2; max-red=3D220; = octet-align=3D1=20 > >>>a=3Dptime:20 a=3Dmaxptime:240 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >>> > >>>I know this is wrong, for instance I don't manage to fit > >> > >>the a=3Dfmtp.. > >> > >>>line anywhere, can soembody help ? > >>> > >>>Also, what would a response look like ? > >>> > >>>Regards > >>>Ingemar > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>>>Sent: den 29 januari 2007 21:50 > >>>>To: i-d-announce@ietf.org > >>>>Cc: mmusic@ietf.org > >>>>Subject: [MMUSIC] > >>>>I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt > >>>> > >>>>A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > >>>>directories. > >>>>This draft is a work item of the Multiparty Multimedia > >> > >>Session Control > >> > >>>>Working Group of the IETF. > >>>> > >>>> Title : SDP Capability Negotiation > >>>> Author(s) : F. Andreasen > >>>> Filename :=20 > >>>>draft-ietf-mmusic-sdp-capability-negotiation-01.txt > >>>> Pages : 29 > >>>> Date : 2007-1-29 > >>>>=09 > >>>>The Session Description Protocol (SDP) was intended for=20 > describing=20 > >>>> multimedia sessions for the purposes of session > >> > >>announcement, > >> > >>>>session > >>>> invitation, and other forms of multimedia session > >> > >>initiation.=20 > >> > >>>>SDP was > >>>> not intended to provide capability indication or=20 > capability=20 > >>>> negotiation, however over the years, SDP has seen > >> > >>widespread > >> > >>>>adoption > >>>> and as a result it has been gradually extended to provide=20 > >>>>limited > >>>> support for these. SDP and its current extensions > >> > >>however do > >> > >>>>not have > >>>> the ability to negotiate one or more alternative transport=20 > >>>>protocols > >>>> (e.g. RTP profiles) which makes it particularly > >> > >>difficult to > >> > >>>>deploy > >>>> new RTP profiles such as secure RTP or RTP with RTCP-based=20 > >>>>feedback. > >>>> > >>>>A URL for this Internet-Draft is: > >>>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capa > >>>>bility-negotiation-01.txt > >>>> > >>>>To remove yourself from the I-D Announcement list, send a > >> > >>message to > >> > >>>>i-d-announce-request@ietf.org with the word unsubscribe in > >> > >>the body of > >> > >>>>the message. > >>>>You can also visit > >> > >>https://www1.ietf.org/mailman/listinfo/I-D-announce > >> > >>>>to change your subscription settings. > >>>> > >>>>Internet-Drafts are also available by anonymous FTP.=20 > Login with the=20 > >>>>username "anonymous" and a password of your e-mail address. After=20 > >>>>logging in, type "cd internet-drafts" and then "get=20 > >>>>draft-ietf-mmusic-sdp-capability-negotiation-01.txt". > >>>> > >>>>A list of Internet-Drafts directories can be found in=20 > >>>>http://www.ietf.org/shadow.html or=20 > >>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>> > >>>>Internet-Drafts can also be obtained by e-mail. > >>>> > >>>>Send a message to: > >>>> mailserv@ietf.org. > >>>>In the body type: > >>>> "FILE > >>>>/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiatio > >=20 > > n-01.txt". > >=20 > >>>>=09 > >>>>NOTE: The mail server at ietf.org can return the document in > >>>> MIME-encoded form by using the "mpack" utility. To use this > >>>> feature, insert the command "ENCODING mime" before the "FILE" > >>>> command. To decode the response(s), you will need "munpack" or > >>>> a MIME-compliant mail reader. Different MIME-compliant > >> > >>mail readers > >> > >>>> exhibit different behavior, especially when dealing with > >>>> "multipart" MIME messages (i.e. documents which have been split > >>>> up into multiple messages), so check your local documentation on > >>>> how to manipulate these messages. > >>>> > >>>>Below is the data which will enable a MIME compliant mail reader=20 > >>>>implementation to automatically retrieve the ASCII version of the=20 > >>>>Internet-Draft. > >>>> > >>> > >>> > >>>_______________________________________________ > >>>mmusic mailing list > >>>mmusic@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/mmusic > >> > >> > >=20 >=20 >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 06 09:29:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERJx-0004Pt-I1; Tue, 06 Feb 2007 09:29:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERJw-0004J1-9I for mmusic@ietf.org; Tue, 06 Feb 2007 09:29:20 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERJj-0004jk-8p for mmusic@ietf.org; Tue, 06 Feb 2007 09:29:20 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by atvies1zqx.siemens.at with ESMTP id l16EPjXq001768 for ; Tue, 6 Feb 2007 15:25:45 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l16ESxLb026659 for ; Tue, 6 Feb 2007 15:28:59 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 15:28:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Feb 2007 15:28:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDP Capability Negotation: Should the scope of a=capar: narrowed down to transport protocol negotiation? Thread-Index: AcdJ+yM09AKBDotETzOAMLOXW111Tw== From: "Stach, Thomas" To: X-OriginalArrivalTime: 06 Feb 2007 14:28:59.0760 (UTC) FILETIME=[2446FF00:01C749FB] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070206152545-0A8C5BB0-1DA69879/0-0/0-15 X-purgate-size: 3347/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar: narrowed down to transport protocol negotiation? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi all, =20 in the context of SDP media capability negotiation it is currently = discussed to define new SDP attributes like=20 a=3Dcmed:, a=3Dcenc:, a=3Dcfmt:, a=3Dcptmap: that negotiate parameters = that usually go into the a=3Drtpmap:, a=3Dfmtp:, a=3Dptime, etc. In draft-ietf-mmusic-sdp-capability-negotiation-01 the new SDP attribute = a=3Dcapar: is going to be defined. It is basically a container that can carry everything that is specified = as an SDP attribute. Hence it could carry e.g. a=3Drtpmap as well, which will introduce some = ambiguity and unclear semantics in combination with media capability = negotiation. Now, I wonder if it would be useful to restrict the number of allowed = values in the a=3Dcapar: attribute when negotiating transport protocol = using the a=3Dctrpr attribute to the necessary subset of attributes. =20 Scanning through IANA the following values are assigned for the = field in the m-line. =20 proto RTP/AVP [RFC4566] vat [historic] rtp [historic] udptl [ITU-T Rec. T.38 (Section = 9)] =20 TCP [RFC4145] RTP/AVPF [RFC4585.txt] TCP/RTP/AVP [RFC4571] RTP/SAVP [RFC3711] TCP/BFCP [RFC4583] TCP/TLS/BFCP [RFC4583] TCP/TLS [RFC4572] FLUTE/UDP = [RFC-mehta-rmt-flute-sdp-05.txt] Until now we just considered RTP/AVP(F) and RTP/SAVP(F) for best effort = SRTP.=20 The related attributes are a=3Dkmgmt:, a=3Dcrypto:, a=3Drtcp-fb: with = their specific values. Others might be specified in the future. I think that TCP/RTP/AVP, TCP and TCP/TLS are worth considering as well = for e.g. for T.38 fax. The related attributes are a=3Dsetup:, a=3Dconnection:, a=3Dfingerprint: = What about TCP/BFCP and TCP/TLS/BFCP, which have a completely different = context . The related attributes are a=3Dconfid:, a=3Duserid:, a=3Dfloorctrl: and = a=3Dfloorid: Flute introduces the attributes flute-tsi","flute-ch", = "FEC-declaration", "FEC", "FEC-OTI-extension"=20 and "content-desc". As the main driver for this initiative is best-effort SRTP and as we = already received complaints about complexity, I wonder if we should not lay the hurdle for implementation even lower = by defining 4 clearly separate modules for basic SDP capability negotiation, namely "best-effort srtp", "comedia", = "bfcp" and "flute".=20 Support for each could be indicated using 4 option tags for = a=3Dcsup/creq:.=20 Replacing the a=3Dcapar by 4 specifc attributes would also be something = to consider in this context. The modules could be separately implemented as needed for the specific = application of the capabilitiy negotiation framework. Comments? mit freundlichen Gr=FC=DFen/Kind Regards Dr.-Ing. Thomas Stach=20 PSE KB B1=20 Siemens Austria AG=20 Gudrunstr. 11 Tel: +43-51707-47364=20 A-1100 Vienna Fax: +43-51707-56992=20 mailto:thomas.stach@siemens.com =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Feb 08 20:47:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKrC-00036N-Sc; Thu, 08 Feb 2007 20:47:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKr9-00034f-4I; Thu, 08 Feb 2007 20:47:19 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFKr7-0005Tg-Nu; Thu, 08 Feb 2007 20:47:19 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l191lHfA010937; Thu, 8 Feb 2007 17:47:17 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l191lHDk010936; Thu, 8 Feb 2007 17:47:17 -0800 Date: Thu, 8 Feb 2007 17:47:17 -0800 Message-Id: <200702090147.l191lHDk010936@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 4796 on The Session Description Protocol (SDP) Content Attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4796 Title: The Session Description Protocol (SDP) Content Attribute Author: J. Hautakorpi, G. Camarillo Status: Standards Track Date: February 2007 Mailbox: Jani.Hautakorpi@ericsson.com, Gonzalo.Camarillo@ericsson.com Pages: 11 Characters: 22886 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-sdp-media-content-06.txt URL: http://www.rfc-editor.org/rfc/rfc4796.txt This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. [STANDARDS TRACK] This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Feb 09 05:50:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTK8-0006y1-5H; Fri, 09 Feb 2007 05:49:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTK6-0006xn-To for mmusic@ietf.org; Fri, 09 Feb 2007 05:49:46 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFTK4-0000C1-Hs for mmusic@ietf.org; Fri, 09 Feb 2007 05:49:46 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l19AktI0002330 for ; Fri, 9 Feb 2007 12:47:16 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 12:49:37 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 12:49:13 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l19AkXAR030590 for ; Fri, 9 Feb 2007 12:46:33 +0200 Received: from [172.21.41.59] (esdhcp04159.research.nokia.com [172.21.41.59]) by kusti.research.nokia.com (Postfix) with ESMTP id 2C49093B77; Fri, 9 Feb 2007 12:49:36 +0200 (EET) Message-ID: <45CC51BF.2040301@nokia.com> Date: Fri, 09 Feb 2007 12:49:35 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: ext Miguel Garcia Subject: Re: [MMUSIC] [Fwd: I-D ACTION:draft-ietf-mmusic-file-transfer-mech-00.txt] References: <45879AAD.5080607@nokia.com> In-Reply-To: <45879AAD.5080607@nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2007 10:49:13.0440 (UTC) FILETIME=[EFDB7E00:01C74C37] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070209124716-08F68BB0-7D7B8955/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Miguel, Skimming through the draft, the MSRP usage caught my attention. Currently, at least in the examples in Section 9, the MSRP usage defines a synchronous scheme for sending chunks over MSRP. It appears this scheme will have quite poor performance. This is because you need to wait a round-trip between consecutive chunks, which means that the overall transfer rate will in most cases be poor, depending of course on the network latency. The way file transfers should work is that the requests are pipelined much like in HTTP/1.1, i.e., a certain number of SENDs are sent without first waiting for a response. However, I'm not sure MSRP actually supports this. The MSRP draft seems to be silent on this issue. Anyway, I think it should be said somewhere, that for MSRP file transfers, pipelining SEND requests is RECOMMENDED. Maybe even throw in a recommended number of SENDs to have outstanding at a time in such pipelining bursts. Cheers, Aki ext Miguel Garcia wrote: > As you can see, there is a new version of the SDP O/A for file transfer > draft. There are no technical changes in this version of the spec, just > the IANA considerations section got updated. > > /Miguel > > ------------------------------------------------------------------------ > > Subject: > I-D ACTION:draft-ietf-mmusic-file-transfer-mech-00.txt > From: > "ext i-d-announce-bounces@ietf.org" > Date: > Mon, 18 Dec 2006 15:50:01 -0500 > To: > i-d-announce@ietf.org > > To: > i-d-announce@ietf.org > CC: > mmusic@ietf.org > > > 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 : A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer > Author(s) : M. Garcia-Martin, et al. > Filename : draft-ietf-mmusic-file-transfer-mech-00.txt > Pages : 35 > Date : 2006-12-18 > > This document provides a mechanism to negotiate the transfer of one > or more files between two endpoints by using the Session Description > Protocol (SDP) offer/answer model specified in RFC 3264. SDP is > extended to describe the attributes of the files to be transferred. > The offerer can either describe the files it wants to send, or the > files it would like to receive. The answerer can either accept or > reject the offer separately for each individual file . The transfer > of one or more files is initiated after a successful negotiation. > The Message Session Relay Protocol (MSRP) is defined as the default > mechanism to actually carry the files between the endpoints. The > conventions on how to use MSRP for file transfer are also provided in > this document. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-mmusic-file-transfer-mech-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mmusic-file-transfer-mech-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Feb 09 06:29:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTwQ-0005Fz-K8; Fri, 09 Feb 2007 06:29:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTwP-0005FR-Lq for mmusic@ietf.org; Fri, 09 Feb 2007 06:29:21 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFTwO-0007qE-Vy for mmusic@ietf.org; Fri, 09 Feb 2007 06:29:21 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l19BQ2M9014850 for ; Fri, 9 Feb 2007 13:26:04 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 13:29:07 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 13:28:43 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 13:28:44 +0200 Message-ID: <45CC5AEA.4090702@nokia.com> Date: Fri, 09 Feb 2007 13:28:42 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [MMUSIC] [Fwd: I-D ACTION:draft-ietf-mmusic-file-transfer-mech-00.txt] References: <45879AAD.5080607@nokia.com> <45CC51BF.2040301@nokia.com> In-Reply-To: <45CC51BF.2040301@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2007 11:28:44.0137 (UTC) FILETIME=[74E72590:01C74C3D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070209132604-398ECBB0-2E1C2D2F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Aki: Yes, I agree with you, the MSRP SEND request should be sent one after each other. Bear in mind, also, that the idea of the draft is to use MSRP "as is", with no changes. The examples section is inspired in the Examples Section 11 in the MSRP draft, http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-18.txt Somehow, we got confused by the examples in there... So, can you please point out if there are any suggestions for the file transfer draft, or are those suggestions for MSRP? Especially, I wouldn't dare to recommend to pipeline MSRP send requests or how many of them, because as I said, we want to use off-the-shelf MSRP. But perhaps you should post something in SIMPLE and to the MSRP authors. We can still change the example to show pipelined MSRP SEND requests. /Miguel Aki Niemi wrote: > Hi Miguel, > > Skimming through the draft, the MSRP usage caught my attention. > Currently, at least in the examples in Section 9, the MSRP usage defines > a synchronous scheme for sending chunks over MSRP. It appears this > scheme will have quite poor performance. This is because you need to > wait a round-trip between consecutive chunks, which means that the > overall transfer rate will in most cases be poor, depending of course on > the network latency. > > The way file transfers should work is that the requests are pipelined > much like in HTTP/1.1, i.e., a certain number of SENDs are sent without > first waiting for a response. However, I'm not sure MSRP actually > supports this. The MSRP draft seems to be silent on this issue. > > Anyway, I think it should be said somewhere, that for MSRP file > transfers, pipelining SEND requests is RECOMMENDED. Maybe even throw in > a recommended number of SENDs to have outstanding at a time in such > pipelining bursts. > > Cheers, > Aki > > ext Miguel Garcia wrote: >> As you can see, there is a new version of the SDP O/A for file transfer >> draft. There are no technical changes in this version of the spec, just >> the IANA considerations section got updated. >> >> /Miguel >> >> ------------------------------------------------------------------------ >> >> Subject: >> I-D ACTION:draft-ietf-mmusic-file-transfer-mech-00.txt >> From: >> "ext i-d-announce-bounces@ietf.org" >> Date: >> Mon, 18 Dec 2006 15:50:01 -0500 >> To: >> i-d-announce@ietf.org >> >> To: >> i-d-announce@ietf.org >> CC: >> mmusic@ietf.org >> >> >> 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 : A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer >> Author(s) : M. Garcia-Martin, et al. >> Filename : draft-ietf-mmusic-file-transfer-mech-00.txt >> Pages : 35 >> Date : 2006-12-18 >> >> This document provides a mechanism to negotiate the transfer of one >> or more files between two endpoints by using the Session Description >> Protocol (SDP) offer/answer model specified in RFC 3264. SDP is >> extended to describe the attributes of the files to be transferred. >> The offerer can either describe the files it wants to send, or the >> files it would like to receive. The answerer can either accept or >> reject the offer separately for each individual file . The transfer >> of one or more files is initiated after a successful negotiation. >> The Message Session Relay Protocol (MSRP) is defined as the default >> mechanism to actually carry the files between the endpoints. The >> conventions on how to use MSRP for file transfer are also provided in >> this document. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-ietf-mmusic-file-transfer-mech-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-mmusic-file-transfer-mech-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Feb 09 09:57:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXBR-0004a7-HM; Fri, 09 Feb 2007 09:57:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXBP-0004YH-PL for mmusic@ietf.org; Fri, 09 Feb 2007 09:57:03 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFXBL-0005YZ-TE for mmusic@ietf.org; Fri, 09 Feb 2007 09:57:03 -0500 Received: from [10.0.1.3] (adsl-68-94-18-186.dsl.rcsntx.swbell.net [68.94.18.186]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l19EuwVR008754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Feb 2007 08:56:59 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <45CC5AEA.4090702@nokia.com> References: <45879AAD.5080607@nokia.com> <45CC51BF.2040301@nokia.com> <45CC5AEA.4090702@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [MMUSIC] [Fwd: I-D ACTION:draft-ietf-mmusic-file-transfer-mech-00.txt] Date: Fri, 9 Feb 2007 06:56:58 -0800 To: Miguel Garcia X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 68.94.18.186 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: Aki Niemi , mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org To my knowledge, there is no prohibition against pipelining in MSRP. (I say to my knowledge because we have been working on that draft so long I sometimes forget what is in there--please point it out to me if you find one :-) ) I'm not sure pipelining will have as big of an impact as you might think, since you are recommended to keep chunks as large as reasonably possible. The 2048 limit on chunks is not a limit as to how big a chunk can be, it's a limit on how large a chunk can be without being interruptible. The idea is you send as big of a chunk as you can, then interrupt it if needed. So in the file transfer scenario, assuming chunks don't get interrupted very often, a file transfer may have a fairly small number of chunks. On Feb 9, 2007, at 3:28 AM, Miguel Garcia wrote: > Aki: > > Yes, I agree with you, the MSRP SEND request should be sent one > after each other. Bear in mind, also, that the idea of the draft is > to use MSRP "as is", with no changes. > > The examples section is inspired in the Examples Section 11 in the > MSRP draft, > > http://www.ietf.org/internet-drafts/draft-ietf-simple-message- > sessions-18.txt > > Somehow, we got confused by the examples in there... > > So, can you please point out if there are any suggestions for the > file transfer draft, or are those suggestions for MSRP? Especially, > I wouldn't dare to recommend to pipeline MSRP send requests or how > many of them, because as I said, we want to use off-the-shelf MSRP. > But perhaps you should post something in SIMPLE and to the MSRP > authors. > > We can still change the example to show pipelined MSRP SEND requests. > > /Miguel > > Aki Niemi wrote: >> Hi Miguel, >> Skimming through the draft, the MSRP usage caught my attention. >> Currently, at least in the examples in Section 9, the MSRP usage >> defines >> a synchronous scheme for sending chunks over MSRP. It appears this >> scheme will have quite poor performance. This is because you need to >> wait a round-trip between consecutive chunks, which means that the >> overall transfer rate will in most cases be poor, depending of >> course on >> the network latency. >> The way file transfers should work is that the requests are pipelined >> much like in HTTP/1.1, i.e., a certain number of SENDs are sent >> without >> first waiting for a response. However, I'm not sure MSRP actually >> supports this. The MSRP draft seems to be silent on this issue. >> Anyway, I think it should be said somewhere, that for MSRP file >> transfers, pipelining SEND requests is RECOMMENDED. Maybe even >> throw in >> a recommended number of SENDs to have outstanding at a time in such >> pipelining bursts. >> Cheers, >> Aki >> ext Miguel Garcia wrote: >>> As you can see, there is a new version of the SDP O/A for file >>> transfer >>> draft. There are no technical changes in this version of the >>> spec, just >>> the IANA considerations section got updated. >>> >>> /Miguel >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> Subject: >>> I-D ACTION:draft-ietf-mmusic-file-transfer-mech-00.txt >>> From: >>> "ext i-d-announce-bounces@ietf.org" >>> Date: >>> Mon, 18 Dec 2006 15:50:01 -0500 >>> To: >>> i-d-announce@ietf.org >>> >>> To: >>> i-d-announce@ietf.org >>> CC: >>> mmusic@ietf.org >>> >>> >>> 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 : A Session Description Protocol (SDP) Offer/Answer >>> Mechanism to Enable File Transfer >>> Author(s) : M. Garcia-Martin, et al. >>> Filename : draft-ietf-mmusic-file-transfer-mech-00.txt >>> Pages : 35 >>> Date : 2006-12-18 >>> >>> This document provides a mechanism to negotiate the transfer >>> of one >>> or more files between two endpoints by using the Session >>> Description >>> Protocol (SDP) offer/answer model specified in RFC 3264. SDP is >>> extended to describe the attributes of the files to be >>> transferred. >>> The offerer can either describe the files it wants to send, or >>> the >>> files it would like to receive. The answerer can either >>> accept or >>> reject the offer separately for each individual file . The >>> transfer >>> of one or more files is initiated after a successful negotiation. >>> The Message Session Relay Protocol (MSRP) is defined as the >>> default >>> mechanism to actually carry the files between the endpoints. The >>> conventions on how to use MSRP for file transfer are also >>> provided in >>> this document. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file- >>> transfer-mech-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message >>> to i-d-announce-request@ietf.org with the word unsubscribe in the >>> body of the message. You can also visit https://www1.ietf.org/ >>> mailman/listinfo/I-D-announce to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with >>> the username "anonymous" and a password of your e-mail address. >>> After logging in, type "cd internet-drafts" and then "get draft- >>> ietf-mmusic-file-transfer-mech-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ >>> 1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-mmusic-file-transfer- >>> mech-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >>> readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/i-d-announce > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.garcia@neonsite.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 12 09:47:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGcS6-0007eK-Ta; Mon, 12 Feb 2007 09:46:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGcS6-0007ds-33 for mmusic@ietf.org; Mon, 12 Feb 2007 09:46:46 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGcS4-0002s6-4s for mmusic@ietf.org; Mon, 12 Feb 2007 09:46:45 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Feb 2007 06:46:44 -0800 X-IronPort-AV: i="4.13,314,1167638400"; d="scan'208"; a="762554327:sNHT54582056" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1CEkhoi005360; Mon, 12 Feb 2007 06:46:43 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1CEkhUw012550; Mon, 12 Feb 2007 06:46:43 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 06:46:43 -0800 Received: from [10.21.153.201] ([10.21.153.201]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 06:46:42 -0800 Message-ID: <45D07DD0.10409@cisco.com> Date: Mon, 12 Feb 2007 09:46:40 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2007 14:46:42.0630 (UTC) FILETIME=[9C469660:01C74EB4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7212; t=1171291603; x=1172155603; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20I-D=20ACTION=3Adraft-ietf-mmusic-sdp-capab ility-negotiation-01.txt |Sender:=20 |To:=20Colin=20Perkins=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowe d |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=YAXHhUP/7fgM2rtKHbWN5ll7F4/5awp4ahENwjuj+LE=; b=QpPGal71lSGT61OoNRtMbj+4iUZWDTWYypfGILDxWRzXTUd0MNLa8omhXXYYni7a4vZX6Xyg eT6qy1xWA3lXU/MoYJaVfw5hUs5+1gbafmtt23paHci6kxhrYdj/KgNKuTYuG9NoS0LzC9VvH3 mcD3x+klMoX3Yv6KB0atRye/Y=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: MMusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Thanks for the comments Colin - responses below. Colin Perkins wrote: > On 29 Jan 2007, at 20:50, Internet-Drafts@ietf.org wrote: >> 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 : SDP Capability Negotiation >> Author(s) : F. Andreasen >> Filename : draft-ietf-mmusic-sdp-capability-negotiation-01.txt >> Pages : 29 >> Date : 2007-1-29 >> >> The Session Description Protocol (SDP) was intended for describing >> multimedia sessions for the purposes of session announcement, >> session >> invitation, and other forms of multimedia session initiation. >> SDP was >> not intended to provide capability indication or capability >> negotiation, however over the years, SDP has seen widespread >> adoption >> and as a result it has been gradually extended to provide >> limited >> support for these. SDP and its current extensions however do >> not have >> the ability to negotiate one or more alternative transport >> protocols >> (e.g. RTP profiles) which makes it particularly difficult to >> deploy >> new RTP profiles such as secure RTP or RTP with RTCP-based >> feedback. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-01.txt >> > > This draft is in very good shape. I do have some minor and editorial > comments, though, to follow on from the discussions in the conference > call yesterday: > > The "Conventions Used in this Document" section needs to be located > after the Introduction, before the current Section 2. > Fixed. > As I mentioned in the call, I find "a=ctrpr" difficult to read and > remember. It would be easier if all capability attributes had a common > style, perhaps "a=capar" for attributes, "a=ctpar" for transport, and > "a=cmpar" for media; or maybe "a=acap", "a=tcap", and "a=mcap"? > Changed to "acap" and "tcap" ("mcap" should be used in the media capabilities document). > I was surprised white space was permitted before the > in "a=csup:" and "a=creq". That seems inconsistent with typical SDP > practice. I know, however I've never understood why you should choke on white-space in a text-based protocol, so I prefer to leave it as-is. > > In Section 2.2.2 the paragraph starting "When an entity generates an > SDP..." says the "a=creq" attribute "MUST be included..., unless". > Maybe "SHOULD be included..., unless" is intended? I believe MUST is correct. > > In Section 2.3.1, it would be helpful if the grammar for "a=capar:" > could be expressed as ABNF, presumably referencing the "attribute" > element from RFC 4566. Similar comments apply to Section 2.3.2 and 2.4.1. Added proper ABNF throughout > > In Section 2.3.1, is white space allowed between "a=capar:" and the > field? I recommend not, for consistency with other SDP > attributes. This will mean the examples later in the draft need to be > updated. Similar comments apply for the other new attributes, and the > later examples. White space is allowed - I don't understand why you would want to choke on that in a text-based protocol (two wrongs don't make a right) > > In Section 2.3.1, can we make the range of be 1...2^31-1 > (both included)? That's still more space than we'll need, and it makes > things more efficient for users of a certain programming language. > Also in Section 2.3.2 and 2.4.1. Sure - done. Which programming language are we talking about btw ? > > In Section 2.3.1, second paragraph on page 12, should be > ? fixed > > In Section 2.3.1, note that the lines of the examples have been > wrapped to fit the page, and are single lines in SDP. added note > > In Section 2.4.1, the "|" character is invalid ABNF, "/" is used to > specify alternatives. Similar in Section 2.4.2. > fixed (2.4.2 as well) > In Section 3.1, I suggest the example omit the second potential > configuration, to show the simplest case, and have a second example > with both configurations listed. ok > More examples in general would be helpful. Agreed - will be added. > > The idnits tool also finds a number of nits (the boilerplate will > presumably need fixing, or the secretariat will bounce the next version). Most of the nits have been fixed at this point - remaining ones will be fixed before final submission. Thanks -- Flemming > > idnits 1.124 > > draft-ietf-mmusic-sdp-capability-negotiation-01.txt: > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > Checking conformance with RFC 3978/3979 boilerplate... > > - This document has ISOC Copyright according to RFC 3978, instead of > the > newer IETF Trust Copyright according to RFC 4748. You should > consider > updating it; the new Copyright statement will be required from > February 1st, > 2007 > - This document has an original RFC 3978 Section 5.5 Disclaimer, > instead of > the newer disclaimer which includes the IETF Trust according to > RFC 4748. > You should consider updating it; the new disclaimer will be > required from > February 1st, 2007 > * There are 463 instances of too long lines in the document, the > longest one > being 5 characters in excess of 72. > * There are 16 instances of lines with non-RFC3330-compliant IPv4 > addresses > in the document. If these are example addresses, they should be > changed. > > Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: > - The page length should not exceed 58 lines per page, but there was 29 > longer pages, the longest (page 1) being 60 lines > > Miscellaneous warnings: > None. > > Experimental warnings: > - Missing Reference: 'Section 8' is mentioned on line 930, but not > defined > - Missing Reference: ' doing so is' is mentioned on line 930, but > not defined > - Unused Reference: 'RFC2234' is defined on line 1138, but not > referenced > - Unused Reference: 'RFC3407' is defined on line 1146, but not > referenced > - Unused Reference: 'RFC3605' is defined on line 1149, but not > referenced > - Unused Reference: 'RFC2046' is defined on line 1161, but not > referenced > - Unused Reference: 'RFC2327' is defined on line 1165, but not > referenced > - Unused Reference: 'RFC3388' is defined on line 1172, but not > referenced > - Unused Reference: 'RFC3851' is defined on line 1184, but not > referenced > - Unused Reference: 'RFC4091' is defined on line 1188, but not > referenced > - Unused Reference: 'BESRTP' is defined on line 1212, but not > referenced > - Unused Reference: 'SDPCapNegRqts' is defined on line 1221, but not > referenced > - Unused Reference: 'MIKEY' is defined on line 1228, but not referenced > > > --Colin Perkins > http://csperkins.org/ > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 12 10:40:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGdHh-00030r-Qd; Mon, 12 Feb 2007 10:40:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGdHg-00030m-9Q for mmusic@ietf.org; Mon, 12 Feb 2007 10:40:04 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGdHf-0000lk-0D for mmusic@ietf.org; Mon, 12 Feb 2007 10:40:04 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:59264) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HGdHe-0003MU-GG; Mon, 12 Feb 2007 15:40:02 +0000 In-Reply-To: <45D07DD0.10409@cisco.com> References: <45D07DD0.10409@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Date: Mon, 12 Feb 2007 15:40:10 +0000 To: Flemming Andreasen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: MMusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 12 Feb 2007, at 14:46, Flemming Andreasen wrote: ... >> I was surprised white space was permitted before the > list> in "a=csup:" and "a=creq". That seems inconsistent with >> typical SDP practice. > I know, however I've never understood why you should choke on white- > space in a text-based protocol, so I prefer to leave it as-is. Okay, but at least note the inconsistency, otherwise implementations will trip up on it. >> In Section 2.2.2 the paragraph starting "When an entity generates >> an SDP..." says the "a=creq" attribute "MUST be included..., >> unless". Maybe "SHOULD be included..., unless" is intended? > I believe MUST is correct. Maybe we interpret RFC 2119 differently, but I consider MUST is unconditional, and a SHOULD is "MUST... unless". >> In Section 2.3.1, can we make the range of be >> 1...2^31-1 (both included)? That's still more space than we'll >> need, and it makes things more efficient for users of a certain >> programming language. Also in Section 2.3.2 and 2.4.1. > Sure - done. Which programming language are we talking about btw ? int is 32 bit signed in Java, for example. Cheers, Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 12 11:28:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGe25-0003ub-UQ; Mon, 12 Feb 2007 11:28:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGe24-0003uV-Kb for mmusic@ietf.org; Mon, 12 Feb 2007 11:28:00 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGe1p-0003Tb-7Z for mmusic@ietf.org; Mon, 12 Feb 2007 11:28:00 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zqx.siemens.at with ESMTP id l1CGOFeK031942 for ; Mon, 12 Feb 2007 17:24:15 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l1CGRc0M013385 for ; Mon, 12 Feb 2007 17:27:39 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 17:27:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar:narrowed down to transport protocol negotiation? Date: Mon, 12 Feb 2007 17:27:37 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar:narrowed down to transport protocol negotiation? Thread-Index: AcdJ+yM09AKBDotETzOAMLOXW111TwExtBoA References: From: "Stach, Thomas" To: "Stach, Thomas" , X-OriginalArrivalTime: 12 Feb 2007 16:27:39.0135 (UTC) FILETIME=[B63BE8F0:01C74EC2] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070212172415-0A8CFBB0-28583D86/0-0/0-15 X-purgate-size: 16134/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi,=20 as a follow-up here is a proposal for an ABNF that restricts the = defined/allowed values for "a=3Dcapar" to those necessary for transport = protocol negotiation.=20 a=3Dcapar: =3D rtcp-fb-syntax / ; from RFC 4585 crypto-syntax / key-mgmt-syntax / =20 setup-attr / ; from RFC 4145 connection-attr / ; from RFC 4145 fingerprint-syntax /=20 floor-control-attribute / ; from RFC 4583 confid-attribute / ; from RFC 4583 userid-attribute / ; from RFC 4583 flute-tsi-line / ; from = RFC-mehta-rmt-flute-sdp-05.txt flute-channel-line / ; from = RFC-mehta-rmt-flute-sdp-05.txt fec-declaration-line / ; from = RFC-mehta-rmt-flute-sdp-05.txt fec-line / ; from RFC-mehta-rmt-flute-sdp-05.txt content-desc-line / ; from = RFC-mehta-rmt-flute-sdp-05.txt fec-oti-extension-line / ; from = RFC-mehta-rmt-flute-sdp-05.txt attpar-extension=20 crypto-syntax =3D "a=3Dcrypto:" tag 1*WSP = crypto-suite 1*WSP key-params *(1*WSP session-param) ; from = RFC 4568 key-mgmt-syntax =3D "a=3D" key-mgmt-attribute ; = from RFC 4567 fingerprint-syntax =3D "a=3D" = fingerprint-attribute / ; from RFC 4572 attpar-extension =3D token=20 is an integer between 1 and 2^32-1 (both included) used to = number the attribute capability=20 It is extensible for yet to be defined attributes for yet to be defined = transport protocols. Any extension to the capability negotiation framework should then define = its own new attribute that carries attributes specific to that extension = like its is currently done for media capabilites. Any thoughts? Beware: Even more boring content follows! The following is the complete IANA list for SDP parameters that I used = to produce the ABNF above Type SDP Name Reference ---- ------------------ --------- att-field (session level) cat [RFC4566] keywds [RFC4566] type [RFC4566] type:broadcast [RFC4566] type:H332 [ITU Recommendation H.332] type:meeting [RFC4566] type:moderated [RFC4566] type:test [RFC4566] charset [RFC4566] charset:iso8895-1 [RFC4566] tool [RFC4566] ipbcp [ITU-T Q.1970] group [RFC3388] TS:--> None of the above has to be negotiated together with a specifc = transport protocol Type SDP Name Reference ---- ------------------ --------- att-field (both session and media level) recvonly [RFC4566] sendrecv [RFC4566] sendonly [RFC4566] sdplang [RFC4566] lang [RFC4566] TS:--> None of the above must be negotiated for a specific transport. h248item [ITU-T H.248.15] TS:--> The above does not seem to be negotiated for a specific = transport. sqn [RFC3407] cdsc [RFC3407] =09 cpar [RFC3407] cparmin [RFC3407] cparmax [RFC3407] TS:--> The above is out of scope for SDP transport protocol negotiation. rtcp-xr = [RFC-ietf-avt-rtcp-report-extns-06.txt] ---> already 3611 TS:--> The above does not seem to be negotiated for a specific = transport. Who can confirm? TS:--> The reference above should be RFC3611, this seems to an error in = IANA. maxprate [RFC3890] TS:--> The above is related to media and should be considered for media = capability negotiation setup [RFC4145] connection [RFC4145] TS:--> The above are transport protocol specific and must be included as = attributes=20 key-mgmt [RFC4567] TS:--> The above are transport protocol specific and must be included as = attribute=20 source-filter [RFC4570] TS:--> The above is out of scope for SDP transport protocol negotiation. inactive [RFC4566] TS:--> The above is out of scope for SDP transport protocol negotiation. fingerprint [RFC4572] flute-tsi = [RFC-mehta-rmt-flute-sdp-05.txt] flute-ch = [RFC-mehta-rmt-flute-sdp-05.txt] FEC-declaration = [RFC-mehta-rmt-flute-sdp-05.txt] FEC-OTI-extension = [RFC-mehta-rmt-flute-sdp-05.txt] content-desc = [RFC-mehta-rmt-flute-sdp-05.txt] TS:--> The above are transport protocol specific and must be included as = attribute=20 Type SDP Name Reference ---- ------------------ --------- att-field (media level only) ptime [RFC4566] TS:--> The above is related to media and should be considered for media = capability negotiation orient [RFC4566] orient:portrait [RFC4566] orient:landscape [RFC4566] orient:seascape [RFC4566] TS:--> The above are transport protocol specific and must be included as = attribute=20 framerate [RFC4566] quality [RFC4566] rtpmap [RFC4566] fmtp [RFC4566] TS:--> The above is related to media and should be considered for media = capability negotiation rtpred1 [historic; use fmtp as per = RFC2198] rtpred2 [historic; use fmtp as per = RFC2198] TS:--> The above is out of scope for SDP transport protocol negotiation. T38FaxVersion [ITU-T Rec. T.38 Annex D] T38MaxBitRate [ITU-T Rec. T.38 Annex D] T38FaxFillBitRemoval [ITU-T Rec. T.38 Annex D] T38FaxTranscodingMMR [ITU-T Rec. T.38 Annex D] T38FaxTranscodingJBIG [ITU-T Rec. T.38 Annex D] T38FaxRateManagement [ITU-T Rec. T.38 Annex D]=20 T38FaxMaxBuffer [ITU-T Rec. T.38 Annex D]=20 T38FaxMaxDatagram [ITU-T Rec. T.38 Annex D] T38FaxUdpEC [ITU-T Rec. T.38 Annex D]=20 TS:--> The above is related to media and should be considered for media = capability negotiation maxptime [RFC4566] TS:--> The above is out of scope for SDP transport protocol negotiation. des [RFC3312] curr [RFC3312] conf [RFC3312] TS:--> The above is for precondition and out of scope for SDP transport = protocol negotiation. mid [RFC3388] TS:--> The above is for grouping and out of scope for SDP transport = protocol negotiation. rtcp [RFC3605] TS:--> The above (explicit RTCP port assignment) is out of scope for SDP = transport protocol negotiation. rtcp-fb [RFC4585] TS:--> The above are transport protocol specific and must be included as = attribute=20 label [RFC4574] TS:--> The above is out of scope for SDP transport protocol negotiation. T38VendorInfo [ITU-T Rec. T.38 Annex D] TS:--> The above is related to media and should be considered for media = capability negotiation crypto [RFC4568] TS:--> The above are transport protocol specific and must be included as = attribute=20 eecid [RFC3108] aalType [RFC3108]=20 capability [RFC3108] qosClass [RFC3108] bcob [RFC3108] stc [RFC3108] upcc [RFC3108] atmQOSparms [RFC3108] atmTrfcDesc [RFC3108] abrParms [RFC3108] abrSetup [RFC3108] bearerType [RFC3108] lij [RFC3108] anycast [RFC3108] cache [RFC3108] bearerSigIE [RFC3108] aalApp [RFC3108] cbrRate [RFC3108] sbc [RFC3108] clkrec [RFC3108] fec [RFC3108] prtfl [RFC3108] structure [RFC3108] cpsSDUsize [RFC3108] aal2CPS [RFC3108] aal2CPSSDUrate [RFC3108] aal2sscs3661unassured [RFC3108] aal2sscs3661assured [RFC3108] aal2sscs3662 [RFC3108] aal5sscop [RFC3108] atmmap [RFC3108] silenceSupp [RFC3108] ecan [RFC3108] gc [RFC3108] profileDesc [RFC3108] vsel [RFC3108] dsel [RFC3108] fsel [RFC3108] onewaySel [RFC3108] codecconfig [RFC3108] isup_usi [RFC3108] uiLayer1_Prot [RFC3108] chain [RFC3108] TS:--> The above (ATM Bearer Connections) is out of scope for SDP = transport protocol negotiation. floorctrl [RFC4583] confid [RFC4583] userid [RFC4583] floorid [RFC4583] TS:--> The above are transport protocol specific and must be included as = attribute=20 FEC = [RFC-mehta-rmt-flute-sdp-05.txt] TS:--> The above are transport protocol specific and must be included as = attribute=20 Kind Regards Thomas=20 > -----Original Message----- > From: Stach, Thomas=20 > Sent: Tuesday, February 06, 2007 3:29 PM > To: mmusic@ietf.org > Subject: [MMUSIC] SDP Capability Negotation: Should the scope=20 > of a=3Dcapar:narrowed down to transport protocol negotiation? >=20 > Hi all, > =20 > in the context of SDP media capability negotiation it is=20 > currently discussed to define new SDP attributes like=20 > a=3Dcmed:, a=3Dcenc:, a=3Dcfmt:, a=3Dcptmap: that negotiate=20 > parameters that usually go into the a=3Drtpmap:, a=3Dfmtp:, a=3Dptime, = etc. >=20 > In draft-ietf-mmusic-sdp-capability-negotiation-01 the new=20 > SDP attribute a=3Dcapar: is going to be defined. > It is basically a container that can carry everything that is=20 > specified as an SDP attribute. > Hence it could carry e.g. a=3Drtpmap as well, which will=20 > introduce some ambiguity and unclear semantics in combination=20 > with media capability negotiation. >=20 > Now, I wonder if it would be useful to restrict the number of=20 > allowed values in the a=3Dcapar: attribute when negotiating=20 > transport protocol using the a=3Dctrpr attribute to the=20 > necessary subset of attributes. > =20 > Scanning through IANA the following values are assigned for=20 > the field in the m-line. > =20 > proto RTP/AVP [RFC4566] > vat [historic] > rtp [historic] > udptl [ITU-T Rec. T.38=20 > (Section 9)] =20 > TCP [RFC4145] > RTP/AVPF [RFC4585.txt] > TCP/RTP/AVP [RFC4571] > RTP/SAVP [RFC3711] > TCP/BFCP [RFC4583] > TCP/TLS/BFCP [RFC4583] > TCP/TLS [RFC4572] > FLUTE/UDP =20 > [RFC-mehta-rmt-flute-sdp-05.txt] >=20 > Until now we just considered RTP/AVP(F) and RTP/SAVP(F) for=20 > best effort SRTP.=20 > The related attributes are a=3Dkmgmt:, a=3Dcrypto:, a=3Drtcp-fb:=20 > with their specific values. > Others might be specified in the future. >=20 > I think that TCP/RTP/AVP, TCP and TCP/TLS are worth=20 > considering as well for e.g. for T.38 fax. > The related attributes are a=3Dsetup:, a=3Dconnection:, = a=3Dfingerprint:=20 >=20 > What about TCP/BFCP and TCP/TLS/BFCP, which have a completely=20 > different context . > The related attributes are a=3Dconfid:, a=3Duserid:, a=3Dfloorctrl:=20 > and a=3Dfloorid: >=20 > Flute introduces the attributes flute-tsi","flute-ch",=20 > "FEC-declaration", "FEC", "FEC-OTI-extension"=20 > and "content-desc". >=20 > As the main driver for this initiative is best-effort SRTP=20 > and as we already received complaints about complexity, > I wonder if we should not lay the hurdle for implementation=20 > even lower by defining 4 clearly separate modules for basic > SDP capability negotiation, namely "best-effort srtp",=20 > "comedia", "bfcp" and "flute".=20 > Support for each could be indicated using 4 option tags for=20 > a=3Dcsup/creq:.=20 > Replacing the a=3Dcapar by 4 specifc attributes would also be=20 > something to consider in this context. >=20 > The modules could be separately implemented as needed for the=20 > specific application of the capabilitiy negotiation framework. >=20 > Comments? >=20 > mit freundlichen Gr=FC=DFen/Kind Regards >=20 > Dr.-Ing. Thomas Stach=20 > PSE KB B1=20 > Siemens Austria AG=20 > Gudrunstr. 11 Tel: +43-51707-47364=20 > A-1100 Vienna Fax: +43-51707-56992=20 > mailto:thomas.stach@siemens.com =20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 12 14:09:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGgYC-00086E-Rj; Mon, 12 Feb 2007 14:09:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGgYB-00085v-01 for mmusic@ietf.org; Mon, 12 Feb 2007 14:09:19 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGgY8-0006tw-Lf for mmusic@ietf.org; Mon, 12 Feb 2007 14:09:18 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HGgY8-00020C-4D for mmusic@ietf.org; Mon, 12 Feb 2007 14:09:16 -0500 Message-ID: <45D0BB5B.9060400@bbn.com> Date: Mon, 12 Feb 2007 14:09:15 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [MMUSIC] Session Attributes in Capability Negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I was reading through the -01 version of the Capability Negotiation draft and I wanted to make sure that I understand the current semantics for session level attributes. I've included some examples which seem reasonable (to me). Please let me know if my understanding of the current semantics is incorrect. (Note: As per Flemming's email dated 02/12/07, I am using "acap" instead of "capar" and "tcap" instead of "ctrpr" --- which is much easier for me to keep straight when writing SDP by hand.) Example 1: I believe the following SDP will offer a single audio stream using "Best-Effort" SRTP and Mikey (at the session level). v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 1 a=creq: v0 a=acap:1 a=key-mgmt:mikey ABAC... m=audio 3456 RTP/AVP 0 a=tcap:1 RTP/SAVP RTP/AVP a=pcfg:1 t=1 a=1 (Note: I think we had discussed at some point whether I need to include "a=pcfg:2 t=2" to indicate that I prefer SAVP over AVP ... I think the consensus was that I don't need the second "pcfg" line, but I'm not certain). Example 2: The following is an offer for a single "Best-Effort" SRTP audio stream where Mikey is preferred (e.g. offerer would like to do a Diffie-Hellman exchange), but the use of SDP Security Descriptions is acceptable. v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 2 a=creq: v0 a=acap:1 a=key-mgmt:mikey ABAC... m=audio 3456 RTP/AVP 0 a=tcap:1 RTP/SAVP RTP/AVP a=acap:2 a=crypto:1 AES_CM_128... a=pcfg:1 t=1 a=1 a=pcfg:2 t=1 a=2 Example 3: Where this gets interesting is if I want to offer two "Best-Effort" SRTP audio streams. v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 3 a=creq: v0 a=acap:1 a=key-mgmt:mikey ABAC... a=tcap:1 RTP/SAVP RTP/AVP m=audio 3456 RTP/AVP 0 a=acap:2 a=crypto:1 AES_CM_128... a=pcfg:1 t=1 a=1 a=pcfg:2 t=1 a=2 m=audio 4680 RTP/AVP 0 18 a=acap:3 a=crypto:1 AES_CM_128... a=pcfg:1 t=1 a=1 a=pcfg:2 t=1 a=3 (Note: I think we discussed at some point whether I needed to repeat the "a=tcap" line once for each media stream and I believe the consensus was that it is acceptable to avoid repetition by placing the "a=tcap" line at the session level) My understanding of the semantics is that if the answerer selected potential configuration #1 (pcfg:1) for each media stream, then this is equivalent to case where the offerer provided the following offer: v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 3 a=key-mgmt:mikey ABAC... m=audio 3456 RTP/AVP 0 m=audio 4680 RTP/AVP 0 18 Similarly, if the answerer selected pcfg:1 for the first media stream and pcfg:2 for the second media stream, then this is equivalent to the case where the offerer provided the following offer: v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 3 a=key-mgmt:mikey ABAC... m=audio 3456 RTP/AVP 0 m=audio 4680 RTP/AVP 0 18 a=crypto:1 AES_CM_128... Now it's possible that this latter case is undesirable (if the answerer supports Mikey, why isn't he willing to use Mikey for both streams???). My understanding is that in a future extension to the Capability Negotiation framework we might have the ability to prohibit certain combinations of pcfg lines (e.g. don't accept pcfg:1 for the first stream and pcfg:2 for the second stream). However, my understanding is that for the time being it is the responsibility of the answerer not to select "bad" combinations of session and media stream attributes. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 12 17:23:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGjZB-0000XW-CW; Mon, 12 Feb 2007 17:22:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGjZ9-0000XJ-MW for mmusic@ietf.org; Mon, 12 Feb 2007 17:22:31 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGjZ8-000251-2k for mmusic@ietf.org; Mon, 12 Feb 2007 17:22:31 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 12 Feb 2007 14:22:30 -0800 X-IronPort-AV: i="4.14,160,1170662400"; d="scan'208"; a="360578493:sNHT52553144" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1CMMTDF014106; Mon, 12 Feb 2007 14:22:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1CMMTUw006909; Mon, 12 Feb 2007 14:22:29 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 14:22:29 -0800 Received: from [10.21.153.201] ([10.21.153.201]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 14:22:28 -0800 Message-ID: <45D0E8A2.4090805@cisco.com> Date: Mon, 12 Feb 2007 17:22:26 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Stach, Thomas" Subject: Re: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar: narrowed down to transport protocol negotiation? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Feb 2007 22:22:28.0454 (UTC) FILETIME=[47A83060:01C74EF4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4229; t=1171318949; x=1172182949; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotation=3A=20Should= 20the=20scope=20of=20a=3Dcapar=3A=0A=20narrowed=20down=20to=20transport=20 protocol=20negotiation? |Sender:=20 |To:=20=22Stach,=20Thomas=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowe d |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=Sq3ieZHSmf3uoQ/oVI8ekVWieNmOgpR+l3EMNMXOILo=; b=OYwQw556Q+XhFIqjmeZRcMoBqVuQUTZUWhZ1THnZBoHZ6UGf8mljNS0tuwT5oQNNwUVSOMd3 ScThPY67Ji+MM1Py0VWKVnHQVFw54h8nL1cr4uXcbe7mOtHkXn++4XCBbqZBtocvfqxYn0z+DU K4ubC3H4YbBPzBOdTUSks5AsY=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Stach, Thomas wrote: > Hi all, > > in the context of SDP media capability negotiation it is currently discussed to define new SDP attributes like > a=cmed:, a=cenc:, a=cfmt:, a=cptmap: that negotiate parameters that usually go into the a=rtpmap:, a=fmtp:, a=ptime, etc. > > In draft-ietf-mmusic-sdp-capability-negotiation-01 the new SDP attribute a=capar: is going to be defined. > It is basically a container that can carry everything that is specified as an SDP attribute. > Hence it could carry e.g. a=rtpmap as well, which will introduce some ambiguity and unclear semantics in combination with media capability negotiation. > Why is that ? It's just one of several building blocks that can be used to piece together a potential configuration - it really doesn't matter whether it's done with one or the other. > Now, I wonder if it would be useful to restrict the number of allowed values in the a=capar: attribute when negotiating transport protocol using the a=ctrpr attribute to the necessary subset of attributes. > > Scanning through IANA the following values are assigned for the field in the m-line. > > proto RTP/AVP [RFC4566] > vat [historic] > rtp [historic] > udptl [ITU-T Rec. T.38 (Section 9)] > TCP [RFC4145] > RTP/AVPF [RFC4585.txt] > TCP/RTP/AVP [RFC4571] > RTP/SAVP [RFC3711] > TCP/BFCP [RFC4583] > TCP/TLS/BFCP [RFC4583] > TCP/TLS [RFC4572] > FLUTE/UDP [RFC-mehta-rmt-flute-sdp-05.txt] > > Until now we just considered RTP/AVP(F) and RTP/SAVP(F) for best effort SRTP. > The related attributes are a=kmgmt:, a=crypto:, a=rtcp-fb: with their specific values. > Others might be specified in the future. > > I think that TCP/RTP/AVP, TCP and TCP/TLS are worth considering as well for e.g. for T.38 fax. > The related attributes are a=setup:, a=connection:, a=fingerprint: > > What about TCP/BFCP and TCP/TLS/BFCP, which have a completely different context . > The related attributes are a=confid:, a=userid:, a=floorctrl: and a=floorid: > > Flute introduces the attributes flute-tsi","flute-ch", "FEC-declaration", "FEC", "FEC-OTI-extension" > and "content-desc". > > As the main driver for this initiative is best-effort SRTP and as we already received complaints about complexity, > I wonder if we should not lay the hurdle for implementation even lower by defining 4 clearly separate modules for basic > SDP capability negotiation, namely "best-effort srtp", "comedia", "bfcp" and "flute". > Support for each could be indicated using 4 option tags for a=csup/creq:. > Replacing the a=capar by 4 specifc attributes would also be something to consider in this context. > > The modules could be separately implemented as needed for the specific application of the capabilitiy negotiation framework. > > Comments? > It looks like the SDP equivalent of coming up with specific feature definition and identification in SIP as opposed to producing and using a general framework. We received AD guidance to come up with a general framework that could be used for things beyond best-effort SRTP and althought you could argue that your proposal still allows for that, it doesn't encourage any kind of generality in an actual implementation and we might as well define point solutions for each of these instead. You can register me as opposed. -- Flemming > mit freundlichen Grüßen/Kind Regards > > Dr.-Ing. Thomas Stach > PSE KB B1 > Siemens Austria AG > Gudrunstr. 11 Tel: +43-51707-47364 > A-1100 Vienna Fax: +43-51707-56992 > mailto:thomas.stach@siemens.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 12 17:27:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGjdp-0003dh-2L; Mon, 12 Feb 2007 17:27:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGjdn-0003dU-Jr for mmusic@ietf.org; Mon, 12 Feb 2007 17:27:19 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGjdm-00031B-6k for mmusic@ietf.org; Mon, 12 Feb 2007 17:27:19 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 12 Feb 2007 14:27:17 -0800 X-IronPort-AV: i="4.14,160,1170662400"; d="scan'208,217"; a="38953840:sNHT141755571" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1CMRHks027082; Mon, 12 Feb 2007 14:27:17 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1CMRHnF009542; Mon, 12 Feb 2007 14:27:17 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 14:27:17 -0800 Received: from [10.21.153.201] ([10.21.153.201]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 14:27:16 -0800 Message-ID: <45D0E9C3.2050909@cisco.com> Date: Mon, 12 Feb 2007 17:27:15 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Stach, Thomas" Subject: Re: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar:narrowed down to transport protocol negotiation? References: In-Reply-To: X-OriginalArrivalTime: 12 Feb 2007 22:27:16.0541 (UTC) FILETIME=[F35EC6D0:01C74EF4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=34383; t=1171319237; x=1172183237; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotation=3A=20Should= 20the=20scope=20of=09a=3Dcapar=3Anarrowed=0A=20down=20to=20transport=20pro tocol=20negotiation? |Sender:=20; bh=Li/jTneblmr8fTtRFzYEd5aDVTGY4C+JMAYRqjQ+9bs=; b=RQCqdMSMbE+br4HSepadckoKR5w80kcOsaU22syJE/fJUxtp7SOZXSJ+2tEJ8xnnVsnCCagh +rtlxy8I1hI/aRPcXEbss1pX6seLDhVqs6V6Oym5xR4vQOPWKh1s9G7g; Authentication-Results: sj-dkim-5; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: c343632e7d969f32683dd165d9d1aa55 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1996939386==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1996939386== Content-Type: multipart/alternative; boundary="------------080402000502020904060601" This is a multi-part message in MIME format. --------------080402000502020904060601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Stach, Thomas wrote: > Hi, > > as a follow-up here is a proposal for an ABNF that restricts the defined/allowed values for "a=capar" to those necessary for transport protocol negotiation. > > a=capar: > = rtcp-fb-syntax / ; from RFC 4585 > crypto-syntax / > key-mgmt-syntax / > setup-attr / ; from RFC 4145 > connection-attr / ; from RFC 4145 > fingerprint-syntax / > floor-control-attribute / ; from RFC 4583 > confid-attribute / ; from RFC 4583 > userid-attribute / ; from RFC 4583 > flute-tsi-line / ; from RFC-mehta-rmt-flute-sdp-05.txt > flute-channel-line / ; from RFC-mehta-rmt-flute-sdp-05.txt > fec-declaration-line / ; from RFC-mehta-rmt-flute-sdp-05.txt > fec-line / ; from RFC-mehta-rmt-flute-sdp-05.txt > content-desc-line / ; from RFC-mehta-rmt-flute-sdp-05.txt > fec-oti-extension-line / ; from RFC-mehta-rmt-flute-sdp-05.txt > attpar-extension > > crypto-syntax = "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params > *(1*WSP session-param) ; from RFC 4568 > key-mgmt-syntax = "a=" key-mgmt-attribute ; from RFC 4567 > fingerprint-syntax = "a=" fingerprint-attribute / ; from RFC 4572 > > attpar-extension = token > > is an integer between 1 and 2^32-1 (both included) used to number the attribute capability > > It is extensible for yet to be defined attributes for yet to be defined transport protocols. > Any extension to the capability negotiation framework should then define its own new attribute that carries attributes specific to that extension like its is currently done for media capabilites. > Any thoughts? > > If I understand your proposal correctly, it has zero forward compatibility with new or changed attributes that may be of relevance, and that seems like a rather undesirable property for a general framework. Let's say we define a "crypto_v2" attribute tomorrow - how will that work ? -- Flemming > > Beware: Even more boring content follows! > The following is the complete IANA list for SDP parameters that I used to produce the ABNF above > > Type SDP Name Reference > ---- ------------------ --------- > att-field (session level) > cat [RFC4566] > keywds [RFC4566] > type [RFC4566] > type:broadcast [RFC4566] > type:H332 [ITU Recommendation H.332] > type:meeting [RFC4566] > type:moderated [RFC4566] > type:test [RFC4566] > charset [RFC4566] > charset:iso8895-1 [RFC4566] > tool [RFC4566] > ipbcp [ITU-T Q.1970] > group [RFC3388] > TS:--> None of the above has to be negotiated together with a specifc transport protocol > > Type SDP Name Reference > ---- ------------------ --------- > att-field (both session and media level) > recvonly [RFC4566] > sendrecv [RFC4566] > sendonly [RFC4566] > sdplang [RFC4566] > lang [RFC4566] > TS:--> None of the above must be negotiated for a specific transport. > h248item [ITU-T H.248.15] > TS:--> The above does not seem to be negotiated for a specific transport. > sqn [RFC3407] > cdsc [RFC3407] > cpar [RFC3407] > cparmin [RFC3407] > cparmax [RFC3407] > TS:--> The above is out of scope for SDP transport protocol negotiation. > rtcp-xr [RFC-ietf-avt-rtcp-report-extns-06.txt] ---> already 3611 > TS:--> The above does not seem to be negotiated for a specific transport. Who can confirm? > TS:--> The reference above should be RFC3611, this seems to an error in IANA. > maxprate [RFC3890] > TS:--> The above is related to media and should be considered for media capability negotiation > setup [RFC4145] > connection [RFC4145] > TS:--> The above are transport protocol specific and must be included as attributes > key-mgmt [RFC4567] > TS:--> The above are transport protocol specific and must be included as attribute > source-filter [RFC4570] > TS:--> The above is out of scope for SDP transport protocol negotiation. > inactive [RFC4566] > TS:--> The above is out of scope for SDP transport protocol negotiation. > fingerprint [RFC4572] > flute-tsi [RFC-mehta-rmt-flute-sdp-05.txt] > flute-ch [RFC-mehta-rmt-flute-sdp-05.txt] > FEC-declaration [RFC-mehta-rmt-flute-sdp-05.txt] > FEC-OTI-extension [RFC-mehta-rmt-flute-sdp-05.txt] > content-desc [RFC-mehta-rmt-flute-sdp-05.txt] > TS:--> The above are transport protocol specific and must be included as attribute > > Type SDP Name Reference > ---- ------------------ --------- > att-field (media level only) > ptime [RFC4566] > TS:--> The above is related to media and should be considered for media capability negotiation > orient [RFC4566] > orient:portrait [RFC4566] > orient:landscape [RFC4566] > orient:seascape [RFC4566] > TS:--> The above are transport protocol specific and must be included as attribute > framerate [RFC4566] > quality [RFC4566] > rtpmap [RFC4566] > fmtp [RFC4566] > TS:--> The above is related to media and should be considered for media capability negotiation > rtpred1 [historic; use fmtp as per RFC2198] > rtpred2 [historic; use fmtp as per RFC2198] > TS:--> The above is out of scope for SDP transport protocol negotiation. > T38FaxVersion [ITU-T Rec. T.38 Annex D] > T38MaxBitRate [ITU-T Rec. T.38 Annex D] > T38FaxFillBitRemoval [ITU-T Rec. T.38 Annex D] > T38FaxTranscodingMMR [ITU-T Rec. T.38 Annex D] > T38FaxTranscodingJBIG [ITU-T Rec. T.38 Annex D] > T38FaxRateManagement [ITU-T Rec. T.38 Annex D] > T38FaxMaxBuffer [ITU-T Rec. T.38 Annex D] > T38FaxMaxDatagram [ITU-T Rec. T.38 Annex D] > T38FaxUdpEC [ITU-T Rec. T.38 Annex D] > TS:--> The above is related to media and should be considered for media capability negotiation > maxptime [RFC4566] > TS:--> The above is out of scope for SDP transport protocol negotiation. > des [RFC3312] > curr [RFC3312] > conf [RFC3312] > TS:--> The above is for precondition and out of scope for SDP transport protocol negotiation. > mid [RFC3388] > TS:--> The above is for grouping and out of scope for SDP transport protocol negotiation. > rtcp [RFC3605] > TS:--> The above (explicit RTCP port assignment) is out of scope for SDP transport protocol negotiation. > rtcp-fb [RFC4585] > TS:--> The above are transport protocol specific and must be included as attribute > label [RFC4574] > TS:--> The above is out of scope for SDP transport protocol negotiation. > T38VendorInfo [ITU-T Rec. T.38 Annex D] > TS:--> The above is related to media and should be considered for media capability negotiation > crypto [RFC4568] > TS:--> The above are transport protocol specific and must be included as attribute > eecid [RFC3108] > aalType [RFC3108] > capability [RFC3108] > qosClass [RFC3108] > bcob [RFC3108] > stc [RFC3108] > upcc [RFC3108] > atmQOSparms [RFC3108] > atmTrfcDesc [RFC3108] > abrParms [RFC3108] > abrSetup [RFC3108] > bearerType [RFC3108] > lij [RFC3108] > anycast [RFC3108] > cache [RFC3108] > bearerSigIE [RFC3108] > aalApp [RFC3108] > cbrRate [RFC3108] > sbc [RFC3108] > clkrec [RFC3108] > fec [RFC3108] > prtfl [RFC3108] > structure [RFC3108] > cpsSDUsize [RFC3108] > aal2CPS [RFC3108] > aal2CPSSDUrate [RFC3108] > aal2sscs3661unassured [RFC3108] > aal2sscs3661assured [RFC3108] > aal2sscs3662 [RFC3108] > aal5sscop [RFC3108] > atmmap [RFC3108] > silenceSupp [RFC3108] > ecan [RFC3108] > gc [RFC3108] > profileDesc [RFC3108] > vsel [RFC3108] > dsel [RFC3108] > fsel [RFC3108] > onewaySel [RFC3108] > codecconfig [RFC3108] > isup_usi [RFC3108] > uiLayer1_Prot [RFC3108] > chain [RFC3108] > TS:--> The above (ATM Bearer Connections) is out of scope for SDP transport protocol negotiation. > floorctrl [RFC4583] > confid [RFC4583] > userid [RFC4583] > floorid [RFC4583] > TS:--> The above are transport protocol specific and must be included as attribute > FEC [RFC-mehta-rmt-flute-sdp-05.txt] > TS:--> The above are transport protocol specific and must be included as attribute > > > > Kind Regards > > Thomas > > >> -----Original Message----- >> From: Stach, Thomas >> Sent: Tuesday, February 06, 2007 3:29 PM >> To: mmusic@ietf.org >> Subject: [MMUSIC] SDP Capability Negotation: Should the scope >> of a=capar:narrowed down to transport protocol negotiation? >> >> Hi all, >> >> in the context of SDP media capability negotiation it is >> currently discussed to define new SDP attributes like >> a=cmed:, a=cenc:, a=cfmt:, a=cptmap: that negotiate >> parameters that usually go into the a=rtpmap:, a=fmtp:, a=ptime, etc. >> >> In draft-ietf-mmusic-sdp-capability-negotiation-01 the new >> SDP attribute a=capar: is going to be defined. >> It is basically a container that can carry everything that is >> specified as an SDP attribute. >> Hence it could carry e.g. a=rtpmap as well, which will >> introduce some ambiguity and unclear semantics in combination >> with media capability negotiation. >> >> Now, I wonder if it would be useful to restrict the number of >> allowed values in the a=capar: attribute when negotiating >> transport protocol using the a=ctrpr attribute to the >> necessary subset of attributes. >> >> Scanning through IANA the following values are assigned for >> the field in the m-line. >> >> proto RTP/AVP [RFC4566] >> vat [historic] >> rtp [historic] >> udptl [ITU-T Rec. T.38 >> (Section 9)] >> TCP [RFC4145] >> RTP/AVPF [RFC4585.txt] >> TCP/RTP/AVP [RFC4571] >> RTP/SAVP [RFC3711] >> TCP/BFCP [RFC4583] >> TCP/TLS/BFCP [RFC4583] >> TCP/TLS [RFC4572] >> FLUTE/UDP >> [RFC-mehta-rmt-flute-sdp-05.txt] >> >> Until now we just considered RTP/AVP(F) and RTP/SAVP(F) for >> best effort SRTP. >> The related attributes are a=kmgmt:, a=crypto:, a=rtcp-fb: >> with their specific values. >> Others might be specified in the future. >> >> I think that TCP/RTP/AVP, TCP and TCP/TLS are worth >> considering as well for e.g. for T.38 fax. >> The related attributes are a=setup:, a=connection:, a=fingerprint: >> >> What about TCP/BFCP and TCP/TLS/BFCP, which have a completely >> different context . >> The related attributes are a=confid:, a=userid:, a=floorctrl: >> and a=floorid: >> >> Flute introduces the attributes flute-tsi","flute-ch", >> "FEC-declaration", "FEC", "FEC-OTI-extension" >> and "content-desc". >> >> As the main driver for this initiative is best-effort SRTP >> and as we already received complaints about complexity, >> I wonder if we should not lay the hurdle for implementation >> even lower by defining 4 clearly separate modules for basic >> SDP capability negotiation, namely "best-effort srtp", >> "comedia", "bfcp" and "flute". >> Support for each could be indicated using 4 option tags for >> a=csup/creq:. >> Replacing the a=capar by 4 specifc attributes would also be >> something to consider in this context. >> >> The modules could be separately implemented as needed for the >> specific application of the capabilitiy negotiation framework. >> >> Comments? >> >> mit freundlichen Grüßen/Kind Regards >> >> Dr.-Ing. Thomas Stach >> PSE KB B1 >> Siemens Austria AG >> Gudrunstr. 11 Tel: +43-51707-47364 >> A-1100 Vienna Fax: +43-51707-56992 >> mailto:thomas.stach@siemens.com >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > --------------080402000502020904060601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Stach, Thomas wrote: 
Hi, 

as a follow-up here is a proposal for an ABNF that restricts the defined/allowed values for "a=capar" to those necessary for transport protocol negotiation. 

           a=capar: <att-tr-num> <att-par>
           <att-par> = rtcp-fb-syntax / ; from RFC 4585
                       crypto-syntax /
                       key-mgmt-syntax /  
                       setup-attr / ; from RFC 4145
                       connection-attr / ; from RFC 4145
                       fingerprint-syntax / 
                       floor-control-attribute / ; from RFC 4583
                       confid-attribute / ; from RFC 4583
                       userid-attribute / ; from RFC 4583
                       flute-tsi-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       flute-channel-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       fec-declaration-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       fec-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       content-desc-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       fec-oti-extension-line /  ; from RFC-mehta-rmt-flute-sdp-05.txt
                       attpar-extension 

                       crypto-syntax = "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
                                           *(1*WSP session-param) ; from RFC 4568
                       key-mgmt-syntax = "a=" key-mgmt-attribute  ; from RFC 4567
                       fingerprint-syntax = "a=" fingerprint-attribute / ; from RFC 4572

                       attpar-extension =  token 

<att-cap-num> is an integer between 1 and 2^32-1 (both included) used to number the attribute capability 

It is extensible for yet to be defined attributes for yet to be defined transport protocols.
Any extension to the capability negotiation framework should then define its own new attribute that carries attributes specific to that extension like its is currently done for media capabilites.
Any thoughts?
If I understand your proposal correctly, it has zero forward compatibility with new or changed attributes that may be of relevance, and that seems like a rather undesirable property for a general framework. Let's say we define a "crypto_v2" attribute tomorrow - how will that work ?

-- Flemming 


Beware: Even more boring content follows!
The following is the complete IANA list for SDP parameters that I used to produce the ABNF above

Type            SDP Name                     Reference
----            ------------------           ---------
att-field (session level)
                cat                          [RFC4566]
                keywds                       [RFC4566]
                type                         [RFC4566]
                type:broadcast               [RFC4566]
                type:H332                    [ITU Recommendation H.332]
                type:meeting                 [RFC4566]
                type:moderated               [RFC4566]
                type:test                    [RFC4566]
                charset                      [RFC4566]
                charset:iso8895-1            [RFC4566]
                tool                         [RFC4566]
                ipbcp                        [ITU-T Q.1970]
                group                        [RFC3388]
TS:--> None of the above has to be negotiated together with a specifc transport protocol

Type            SDP Name                     Reference
----            ------------------           ---------
att-field (both session and media level)
                recvonly                     [RFC4566]
                sendrecv                     [RFC4566]
                sendonly                     [RFC4566]
                sdplang                      [RFC4566]
                lang                         [RFC4566]
TS:--> None of the above must be negotiated for a specific transport.
                h248item                     [ITU-T H.248.15]
TS:--> The above does not seem to be negotiated for a specific transport.
                sqn                          [RFC3407]
                cdsc                         [RFC3407]				
                cpar                         [RFC3407]
                cparmin                      [RFC3407]
                cparmax                      [RFC3407]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                rtcp-xr                      [RFC-ietf-avt-rtcp-report-extns-06.txt]  ---> already 3611
TS:--> The above does not seem to be negotiated for a specific transport. Who can confirm?
TS:--> The reference above should be RFC3611, this seems to an error in IANA.
                maxprate                     [RFC3890]
TS:--> The above is related to media and should be considered for media capability negotiation
                setup                        [RFC4145]
                connection                   [RFC4145]
TS:--> The above are transport protocol specific and must be included as attributes 
                key-mgmt                     [RFC4567]
TS:--> The above are transport protocol specific and must be included as attribute 
                source-filter                [RFC4570]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                inactive                     [RFC4566]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                fingerprint                  [RFC4572]
                flute-tsi                    [RFC-mehta-rmt-flute-sdp-05.txt]
                flute-ch                     [RFC-mehta-rmt-flute-sdp-05.txt]
                FEC-declaration              [RFC-mehta-rmt-flute-sdp-05.txt]
                FEC-OTI-extension            [RFC-mehta-rmt-flute-sdp-05.txt]
                content-desc                 [RFC-mehta-rmt-flute-sdp-05.txt]
TS:--> The above are transport protocol specific and must be included as attribute 

Type            SDP Name                     Reference
----            ------------------           ---------
att-field (media level only)
                ptime                        [RFC4566]
TS:--> The above is related to media and should be considered for media capability negotiation
                orient                       [RFC4566]
                orient:portrait              [RFC4566]
                orient:landscape             [RFC4566]
                orient:seascape              [RFC4566]
TS:--> The above are transport protocol specific and must be included as attribute 
                framerate                    [RFC4566]
                quality                      [RFC4566]
                rtpmap                       [RFC4566]
                fmtp                         [RFC4566]
TS:--> The above is related to media and should be considered for media capability negotiation
                rtpred1                      [historic; use fmtp as per RFC2198]
                rtpred2                      [historic; use fmtp as per RFC2198]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                T38FaxVersion                [ITU-T Rec. T.38 Annex D]
                T38MaxBitRate                [ITU-T Rec. T.38 Annex D]
                T38FaxFillBitRemoval         [ITU-T Rec. T.38 Annex D]
                T38FaxTranscodingMMR         [ITU-T Rec. T.38 Annex D]
                T38FaxTranscodingJBIG        [ITU-T Rec. T.38 Annex D]
                T38FaxRateManagement         [ITU-T Rec. T.38 Annex D] 
                T38FaxMaxBuffer              [ITU-T Rec. T.38 Annex D] 
                T38FaxMaxDatagram            [ITU-T Rec. T.38 Annex D]
                T38FaxUdpEC                  [ITU-T Rec. T.38 Annex D] 
TS:--> The above is related to media and should be considered for media capability negotiation
                maxptime                     [RFC4566]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                des                          [RFC3312]
                curr                         [RFC3312]
                conf                         [RFC3312]
TS:--> The above is for precondition and out of scope for SDP transport protocol negotiation.
                mid                          [RFC3388]
TS:--> The above is for grouping and out of scope for SDP transport protocol negotiation.
                rtcp                         [RFC3605]
TS:--> The above (explicit RTCP port assignment) is out of scope for SDP transport protocol negotiation.
                rtcp-fb                      [RFC4585]
TS:--> The above are transport protocol specific and must be included as attribute 
                label                        [RFC4574]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                T38VendorInfo                [ITU-T Rec. T.38 Annex D]
TS:--> The above is related to media and should be considered for media capability negotiation
                crypto                       [RFC4568]
TS:--> The above are transport protocol specific and must be included as attribute 
                eecid                        [RFC3108]
                aalType                      [RFC3108] 
                capability                   [RFC3108]
                qosClass                     [RFC3108]
                bcob                         [RFC3108]
                stc                          [RFC3108]
                upcc                         [RFC3108]
                atmQOSparms                  [RFC3108]
                atmTrfcDesc                  [RFC3108]
                abrParms                     [RFC3108]
                abrSetup                     [RFC3108]
                bearerType                   [RFC3108]
                lij                          [RFC3108]
                anycast                      [RFC3108]
                cache                        [RFC3108]
                bearerSigIE                  [RFC3108]
                aalApp                       [RFC3108]
                cbrRate                      [RFC3108]
                sbc                          [RFC3108]
                clkrec                       [RFC3108]
                fec                          [RFC3108]
                prtfl                        [RFC3108]
                structure                    [RFC3108]
                cpsSDUsize                   [RFC3108]
                aal2CPS                      [RFC3108]
                aal2CPSSDUrate               [RFC3108]
                aal2sscs3661unassured        [RFC3108]
                aal2sscs3661assured          [RFC3108]
                aal2sscs3662                 [RFC3108]
                aal5sscop                    [RFC3108]
                atmmap                       [RFC3108]
                silenceSupp                  [RFC3108]
                ecan                         [RFC3108]
                gc                           [RFC3108]
                profileDesc                  [RFC3108]
                vsel                         [RFC3108]
                dsel                         [RFC3108]
                fsel                         [RFC3108]
                onewaySel                    [RFC3108]
                codecconfig                  [RFC3108]
                isup_usi                     [RFC3108]
                uiLayer1_Prot                [RFC3108]
                chain                        [RFC3108]
TS:--> The above (ATM Bearer Connections) is out of scope for SDP transport protocol negotiation.
                floorctrl                    [RFC4583]
                confid                       [RFC4583]
                userid                       [RFC4583]
                floorid                      [RFC4583]
TS:--> The above are transport protocol specific and must be included as attribute 
                FEC                          [RFC-mehta-rmt-flute-sdp-05.txt]
TS:--> The above are transport protocol specific and must be included as attribute 



Kind Regards

Thomas 

  
-----Original Message-----
From: Stach, Thomas 
Sent: Tuesday, February 06, 2007 3:29 PM
To: mmusic@ietf.org
Subject: [MMUSIC] SDP Capability Negotation: Should the scope 
of a=capar:narrowed down to transport protocol negotiation?

Hi all,
 
in the context of SDP media capability negotiation it is 
currently discussed to define new SDP attributes like 
a=cmed:, a=cenc:, a=cfmt:, a=cptmap: that negotiate 
parameters that usually go into the a=rtpmap:, a=fmtp:, a=ptime, etc.

In draft-ietf-mmusic-sdp-capability-negotiation-01 the new 
SDP attribute a=capar: is going to be defined.
It is basically a container that can carry everything that is 
specified as an SDP attribute.
Hence it could carry e.g. a=rtpmap as well, which will 
introduce some ambiguity and unclear semantics in combination 
with media capability negotiation.

Now, I wonder if it would be useful to restrict the number of 
allowed values in the a=capar: attribute when negotiating 
transport protocol using the a=ctrpr attribute to the 
necessary subset of attributes.
 
Scanning through IANA the following values are assigned for 
the <proto> field in the m-line.
 
proto           RTP/AVP                      [RFC4566]
                vat                          [historic]
                rtp                          [historic]
                udptl                        [ITU-T Rec. T.38 
(Section 9)]  
                TCP                          [RFC4145]
                RTP/AVPF                     [RFC4585.txt]
                TCP/RTP/AVP                  [RFC4571]
                RTP/SAVP                     [RFC3711]
                TCP/BFCP                     [RFC4583]
                TCP/TLS/BFCP                 [RFC4583]
                TCP/TLS                      [RFC4572]
                FLUTE/UDP                    
[RFC-mehta-rmt-flute-sdp-05.txt]

Until now we just considered RTP/AVP(F) and RTP/SAVP(F) for 
best effort SRTP. 
The related attributes are a=kmgmt:, a=crypto:, a=rtcp-fb: 
with their specific values.
Others might be specified in the future.

I think  that TCP/RTP/AVP, TCP and TCP/TLS are worth 
considering as well for e.g. for T.38 fax.
The related attributes are a=setup:, a=connection:, a=fingerprint: 

What about TCP/BFCP and TCP/TLS/BFCP, which have a completely 
different context .
The related attributes are a=confid:, a=userid:, a=floorctrl: 
and a=floorid:

Flute introduces the attributes flute-tsi","flute-ch", 
"FEC-declaration", "FEC", "FEC-OTI-extension" 
and "content-desc".

As the main driver for this initiative is best-effort SRTP 
and as we already received complaints about complexity,
I wonder if we should not lay the hurdle for implementation 
even lower by defining 4 clearly separate modules for basic
SDP capability negotiation, namely  "best-effort srtp", 
"comedia", "bfcp" and "flute". 
Support for each could be indicated using 4 option tags for 
a=csup/creq:. 
Replacing the a=capar by 4 specifc attributes would also be 
something to consider in this context.

The modules could be separately implemented as needed for the 
specific application of the capabilitiy negotiation framework.

Comments?

mit freundlichen Grüßen/Kind Regards

Dr.-Ing. Thomas Stach 
PSE KB B1 
Siemens Austria AG 
Gudrunstr. 11 Tel: +43-51707-47364 
A-1100 Vienna Fax: +43-51707-56992 
mailto:thomas.stach@siemens.com <mailto:thomas.stach@siemens.com> 



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

    

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
--------------080402000502020904060601-- --===============1996939386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1996939386==-- From mmusic-bounces@ietf.org Mon Feb 12 17:32:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGjiv-0006Y6-O3; Mon, 12 Feb 2007 17:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGjiu-0006Y0-Pf for mmusic@ietf.org; Mon, 12 Feb 2007 17:32:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGjis-0003g2-SF for mmusic@ietf.org; Mon, 12 Feb 2007 17:32:36 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 12 Feb 2007 14:32:34 -0800 X-IronPort-AV: i="4.14,160,1170662400"; d="scan'208"; a="388309415:sNHT51278868" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1CMWYJd030528; Mon, 12 Feb 2007 14:32:34 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1CMWOi4009849; Mon, 12 Feb 2007 14:32:33 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 14:32:33 -0800 Received: from [10.21.153.201] ([10.21.153.201]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 14:32:31 -0800 Message-ID: <45D0EAFD.2080809@cisco.com> Date: Mon, 12 Feb 2007 17:32:29 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Matt Lepinski Subject: Re: [MMUSIC] Session Attributes in Capability Negotiation References: <45D0BB5B.9060400@bbn.com> In-Reply-To: <45D0BB5B.9060400@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2007 22:32:31.0187 (UTC) FILETIME=[AEE9F230:01C74EF5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4218; t=1171319554; x=1172183554; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20Session=20Attributes=20in=20Capability=20N egotiation |Sender:=20; bh=Bx7QkXP1QgS0sxQ+ZhziQWzUEC1YC8bzU7FYt6nzokg=; b=JEu4X1ZU6VXK3uWTzNqYd8O2WkPcGnETM3Mc+giY3psiO4TESp9mZRzBeCsYRS3D4MJdI/fb XF+BNA6/rywnUim0Es6yC0OOHxA5QF8H0ScE/73WMrPMl1Uf2u8rnqhT; Authentication-Results: sj-dkim-7; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Matt Lepinski wrote: > I was reading through the -01 version of the Capability Negotiation > draft and I wanted to make sure that I understand the current > semantics for session level attributes. I've included some examples > which seem reasonable (to me). Please let me know if my understanding > of the current semantics is incorrect. > > (Note: As per Flemming's email dated 02/12/07, I am using "acap" > instead of "capar" and "tcap" instead of "ctrpr" --- which is much > easier for me to keep straight when writing SDP by hand.) > > Example 1: I believe the following SDP will offer a single audio > stream using "Best-Effort" SRTP and Mikey (at the session level). > > v=0 > o=jdoe 12345 67890 IN IP4 10.0.0.1 > c=IN IP4 10.0.0.2 > t=0 0 > s=Example 1 > a=creq: v0 > a=acap:1 a=key-mgmt:mikey ABAC... > m=audio 3456 RTP/AVP 0 > a=tcap:1 RTP/SAVP RTP/AVP > a=pcfg:1 t=1 a=1 > > (Note: I think we had discussed at some point whether I need to > include "a=pcfg:2 t=2" to indicate that I prefer SAVP over AVP ... I > think the consensus was that I don't need the second "pcfg" line, but > I'm not certain). That's correct. > > Example 2: The following is an offer for a single "Best-Effort" SRTP > audio stream where Mikey is preferred (e.g. offerer would like to do a > Diffie-Hellman exchange), but the use of SDP Security Descriptions is > acceptable. > > v=0 > o=jdoe 12345 67890 IN IP4 10.0.0.1 > c=IN IP4 10.0.0.2 > t=0 0 > s=Example 2 > a=creq: v0 > a=acap:1 a=key-mgmt:mikey ABAC... > m=audio 3456 RTP/AVP 0 > a=tcap:1 RTP/SAVP RTP/AVP > a=acap:2 a=crypto:1 AES_CM_128... > a=pcfg:1 t=1 a=1 > a=pcfg:2 t=1 a=2 > Looks good. > Example 3: Where this gets interesting is if I want to offer two > "Best-Effort" SRTP audio streams. > > v=0 > o=jdoe 12345 67890 IN IP4 10.0.0.1 > c=IN IP4 10.0.0.2 > t=0 0 > s=Example 3 > a=creq: v0 > a=acap:1 a=key-mgmt:mikey ABAC... > a=tcap:1 RTP/SAVP RTP/AVP > m=audio 3456 RTP/AVP 0 > a=acap:2 a=crypto:1 AES_CM_128... > a=pcfg:1 t=1 a=1 > a=pcfg:2 t=1 a=2 > m=audio 4680 RTP/AVP 0 18 > a=acap:3 a=crypto:1 AES_CM_128... > a=pcfg:1 t=1 a=1 > a=pcfg:2 t=1 a=3 > > (Note: I think we discussed at some point whether I needed to repeat > the "a=tcap" line once for each media stream and I believe the > consensus was that it is acceptable to avoid repetition by placing the > "a=tcap" line at the session level) Correct. > > My understanding of the semantics is that if the answerer selected > potential configuration #1 (pcfg:1) for each media stream, then this > is equivalent to case where the offerer provided the following offer: > > v=0 > o=jdoe 12345 67890 IN IP4 10.0.0.1 > c=IN IP4 10.0.0.2 > t=0 0 > s=Example 3 > a=key-mgmt:mikey ABAC... > m=audio 3456 RTP/AVP 0 > m=audio 4680 RTP/AVP 0 18 > Right (except you have to replace "RTP/AVP" with "RTP/SAVP" in both "m=" lines) > Similarly, if the answerer selected pcfg:1 for the first media stream > and pcfg:2 for the second media stream, then this is equivalent to the > case where the offerer provided the following offer: > > v=0 > o=jdoe 12345 67890 IN IP4 10.0.0.1 > c=IN IP4 10.0.0.2 > t=0 0 > s=Example 3 > a=key-mgmt:mikey ABAC... > m=audio 3456 RTP/AVP 0 > m=audio 4680 RTP/AVP 0 18 > a=crypto:1 AES_CM_128... > Right (except you have to replace "RTP/AVP" with "RTP/SAVP" in both "m=" lines) > Now it's possible that this latter case is undesirable (if the > answerer supports Mikey, why isn't he willing to use Mikey for both > streams???). My understanding is that in a future extension to the > Capability Negotiation framework we might have the ability to prohibit > certain combinations of pcfg lines (e.g. don't accept pcfg:1 for the > first stream and pcfg:2 for the second stream). However, my > understanding is that for the time being it is the responsibility of > the answerer not to select "bad" combinations of session and media > stream attributes. > That's correct, although I'm not sure this particular example is "bad" (at least I don't see anything forbidden in it, unless there is some MIKEY rule I'm not aware of). -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 13 00:20:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGq57-0001C2-Gt; Tue, 13 Feb 2007 00:19:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGq55-0001Ad-U5 for mmusic@ietf.org; Tue, 13 Feb 2007 00:19:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGq22-0001CC-Mt for mmusic@ietf.org; Tue, 13 Feb 2007 00:16:47 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 12 Feb 2007 21:16:45 -0800 X-IronPort-AV: i="4.14,161,1170662400"; d="scan'208"; a="388426845:sNHT42088252" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1D5GkPs029270 for ; Mon, 12 Feb 2007 21:16:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1D5GfnN025723 for ; Mon, 12 Feb 2007 21:16:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 21:16:44 -0800 Received: from [10.21.153.201] ([10.21.153.201]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 21:16:44 -0800 Message-ID: <45D149BB.3070802@cisco.com> Date: Tue, 13 Feb 2007 00:16:43 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2007 05:16:44.0436 (UTC) FILETIME=[26FA0D40:01C74F2E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=645; t=1171343806; x=1172207806; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotiation=3A=20Updated=20solution=20docu ment=20(-02) |Sender:=20; bh=waDYFQPMs8yMWQ+dTB9e4PzF9o9kolkmeVZ/TSrYxuI=; b=StCdlPvdfsJ+kXvveakSIxiHJvqr4lauSXyy49rV/p8s+qKyKvXsRacAFDkbuLn5Tfvp9pet 7gXKz4VfZg88SKO5cn48rlSNpQeGwVN/NrbvC+F6uFFNgypr7hrpViuB; Authentication-Results: sj-dkim-5; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [MMUSIC] SDP Capability Negotiation: Updated solution document (-02) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Greetings I have just submitted an updated solution document as draft-ietf-mmusic-sdp-capability-negotiation-02.txt, which you can retrieve from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-02.txt until it appears in the archives. Please refer to Section 9.1 for a list of changes. There is still some work left in the document, notably in firming up the offer/answer procedures, adding additional examples, and providing proper Security and IANA considerations sections. The rest of the document should be fairly solid at this point (or so I hope at least). Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 13 06:09:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvWm-0005Fh-NO; Tue, 13 Feb 2007 06:08:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvWk-0005Bg-Uh for mmusic@ietf.org; Tue, 13 Feb 2007 06:08:51 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGvWa-0006uS-CW for mmusic@ietf.org; Tue, 13 Feb 2007 06:08:50 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zqx.siemens.at with ESMTP id l1DB53Kb018487; Tue, 13 Feb 2007 12:05:03 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l1DB8GdL008408; Tue, 13 Feb 2007 12:08:27 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 12:08:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar:narrowed down to transport protocol negotiation? Date: Tue, 13 Feb 2007 12:08:26 +0100 Message-ID: In-Reply-To: <45D0E9C3.2050909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar:narrowed down to transport protocol negotiation? Thread-Index: AcdO9PbjBdF/SNObR8mFQn+sTDkW6QAUoMJA References: <45D0E9C3.2050909@cisco.com> From: "Stach, Thomas" To: "Flemming Andreasen" X-OriginalArrivalTime: 13 Feb 2007 11:08:27.0688 (UTC) FILETIME=[497EC280:01C74F5F] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070213120503-0A8CEBB0-30E52615/0-0/0-15 X-purgate-size: 10491/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0730214331==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0730214331== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74F5F.48B5BC7F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74F5F.48B5BC7F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fleming, =20 again I try to clarify my proposal inline. ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: Monday, February 12, 2007 11:27 PM To: Stach, Thomas Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SDP Capability Negotation: Should the scope of a=3Dcapar:narrowed down to transport protocol negotiation? =09 =09 =09 =09 Stach, Thomas wrote:=20 Hi,=20 =09 as a follow-up here is a proposal for an ABNF that restricts the defined/allowed values for "a=3Dcapar" to those necessary for transport protocol negotiation.=20 =09 a=3Dcapar: =3D rtcp-fb-syntax / ; from RFC 4585 crypto-syntax / From mmusic-bounces@ietf.org Tue Feb 13 06:09:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvWm-0005Fh-NO; Tue, 13 Feb 2007 06:08:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvWk-0005Bg-Uh for mmusic@ietf.org; Tue, 13 Feb 2007 06:08:51 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGvWa-0006uS-CW for mmusic@ietf.org; Tue, 13 Feb 2007 06:08:50 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zqx.siemens.at with ESMTP id l1DB53Kb018487; Tue, 13 Feb 2007 12:05:03 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l1DB8GdL008408; Tue, 13 Feb 2007 12:08:27 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 12:08:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar:narrowed down to transport protocol negotiation? Date: Tue, 13 Feb 2007 12:08:26 +0100 Message-ID: In-Reply-To: <45D0E9C3.2050909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar:narrowed down to transport protocol negotiation? Thread-Index: AcdO9PbjBdF/SNObR8mFQn+sTDkW6QAUoMJA References: <45D0E9C3.2050909@cisco.com> From: "Stach, Thomas" To: "Flemming Andreasen" X-OriginalArrivalTime: 13 Feb 2007 11:08:27.0688 (UTC) FILETIME=[497EC280:01C74F5F] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070213120503-0A8CEBB0-30E52615/0-0/0-15 X-purgate-size: 10491/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0730214331==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0730214331== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74F5F.48B5BC7F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74F5F.48B5BC7F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fleming, =20 again I try to clarify my proposal inline. ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: Monday, February 12, 2007 11:27 PM To: Stach, Thomas Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SDP Capability Negotation: Should the scope of a=3Dcapar:narrowed down to transport protocol negotiation? =09 =09 =09 =09 Stach, Thomas wrote:=20 Hi,=20 =09 as a follow-up here is a proposal for an ABNF that restricts the defined/allowed values for "a=3Dcapar" to those necessary for transport protocol negotiation.=20 =09 a=3Dcapar: =3D rtcp-fb-syntax / ; from RFC 4585 crypto-syntax / key-mgmt-syntax / =20 setup-attr / ; from RFC 4145 connection-attr / ; from RFC 4145 fingerprint-syntax /=20 floor-control-attribute / ; from RFC 4583 confid-attribute / ; from RFC 4583 userid-attribute / ; from RFC 4583 flute-tsi-line / ; from RFC-mehta-rmt-flute-sdp-05.txt flute-channel-line / ; from RFC-mehta-rmt-flute-sdp-05.txt fec-declaration-line / ; from RFC-mehta-rmt-flute-sdp-05.txt fec-line / ; from RFC-mehta-rmt-flute-sdp-05.txt content-desc-line / ; from RFC-mehta-rmt-flute-sdp-05.txt fec-oti-extension-line / ; from RFC-mehta-rmt-flute-sdp-05.txt attpar-extension=20 =09 crypto-syntax =3D "a=3Dcrypto:" tag 1*WSP crypto-suite 1*WSP key-params *(1*WSP session-param) ; from RFC 4568 key-mgmt-syntax =3D "a=3D" key-mgmt-attribute ; from RFC 4567 fingerprint-syntax =3D "a=3D" fingerprint-attribute / ; from RFC 4572 =09 attpar-extension =3D token=20 =09 is an integer between 1 and 2^32-1 (both included) used to number the attribute capability=20 =09 It is extensible for yet to be defined attributes for yet to be defined transport protocols. Any extension to the capability negotiation framework should then define its own new attribute that carries attributes specific to that extension like its is currently done for media capabilites. Any thoughts? =09 =20 If I understand your proposal correctly, it has zero forward compatibility with new or changed attributes that may be of relevance, and that seems like a rather undesirable property for a general framework.=20 [Stach Thomas] Maybe the proposal above some improvement, but the syntax above is meant to be extensible using the contruct "attpar-extension=3D token".=20 I assumed that unknown attributes in the "a=3Dcapar:" lines are ignored. This needs to be specified in the document.=20 Another case appears, when attributes are received, that are defined above but are related to transport protocols that are not implemented by the answerer.=20 Based on the content of creq/csup they should be ignored or fallback to plain SDP should happen. Let's say we define a "crypto_v2" attribute tomorrow - how will that work ?=20 [Stach Thomas] In this case the above ABNF must be extended by the usual means (definition of an additional token, IANA registry) =09 Does this make sense?=20 =09 Regards, Thomas=20 =09 -- Flemming=20 =09 [Stach Thomas] =20 ------_=_NextPart_001_01C74F5F.48B5BC7F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Fleming,
 
again I try to clarify my proposal=20 inline.

From: Flemming Andreasen=20 [mailto:fandreas@cisco.com]
Sent: Monday, February 12, 2007 = 11:27=20 PM
To:< key-mgmt-syntax / =20 setup-attr / ; from RFC 4145 connection-attr / ; from RFC 4145 fingerprint-syntax /=20 floor-control-attribute / ; from RFC 4583 confid-attribute / ; from RFC 4583 userid-attribute / ; from RFC 4583 flute-tsi-line / ; from RFC-mehta-rmt-flute-sdp-05.txt flute-channel-line / ; from RFC-mehta-rmt-flute-sdp-05.txt fec-declaration-line / ; from RFC-mehta-rmt-flute-sdp-05.txt fec-line / ; from RFC-mehta-rmt-flute-sdp-05.txt content-desc-line / ; from RFC-mehta-rmt-flute-sdp-05.txt fec-oti-extension-line / ; from RFC-mehta-rmt-flute-sdp-05.txt attpar-extension=20 =09 crypto-syntax =3D "a=3Dcrypto:" tag 1*WSP crypto-suite 1*WSP key-params *(1*WSP session-param) ; from RFC 4568 key-mgmt-syntax =3D "a=3D" key-mgmt-attribute ; from RFC 4567 fingerprint-syntax =3D "a=3D" fingerprint-attribute / ; from RFC 4572 =09 attpar-extension =3D token=20 =09 is an integer between 1 and 2^32-1 (both included) used to number the attribute capability=20 =09 It is extensible for yet to be defined attributes for yet to be defined transport protocols. Any extension to the capability negotiation framework should then define its own new attribute that carries attributes specific to that extension like its is currently done for media capabilites. Any thoughts? =09 =20 If I understand your proposal correctly, it has zero forward compatibility with new or changed attributes that may be of relevance, and that seems like a rather undesirable property for a general framework.=20 [Stach Thomas] Maybe the proposal above some improvement, but the syntax above is meant to be extensible using the contruct "attpar-extension=3D token".=20 I assumed that unknown attributes in the "a=3Dcapar:" lines are ignored. This needs to be specified in the document.=20 Another case appears, when attributes are received, that are defined above but are related to transport protocols that are not implemented by the answerer.=20 Based on the content of creq/csup they should be ignored or fallback to plain SDP should happen. Let's say we define a "crypto_v2" attribute tomorrow - how will that work ?=20 [Stach Thomas] In this case the above ABNF must be extended by the usual means (definition of an additional token, IANA registry) =09 Does this make sense?=20 =09 Regards, Thomas=20 =09 -- Flemming=20 =09 [Stach Thomas] =20 ------_=_NextPart_001_01C74F5F.48B5BC7F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Fleming,
 
again I try to clarify my proposal=20 inline.

From: Flemming Andreasen=20 [mailto:fandreas@cisco.com]
Sent: Monday, February 12, 2007 = 11:27=20 PM
To: Stach, Thomas
Cc:=20 mmusic@ietf.org
Subject: Re: [MMUSIC] SDP Capability = Negotation:=20 Should the scope of a=3Dcapar:narrowed down to transport protocol=20 negotiation?



Stach, Thomas=20 wrote:=20 
Hi,=20

as a follow-up here is a proposal for an ABNF that restricts the =
defined/allowed values for "a=3Dcapar" to those necessary for transport =
protocol negotiation.=20

           a=3Dcapar: <att-tr-num> <att-par>
           <att-par> =3D rtcp-fb-syntax / ; from RFC 4585
                       crypto-syntax /
                       key-mgmt-syntax / =20
                       setup-attr / ; from RFC 4145
                       connection-attr / ; from RFC 4145
                       fingerprint-syntax /=20
                       floor-control-attribute / ; from RFC 4583
                       confid-attribute / ; from RFC 4583
                       userid-attribute / ; from RFC 4583
                       flute-tsi-line / ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       flute-channel-line / ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       fec-declaration-line / ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       fec-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       content-desc-line / ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       fec-oti-extension-line /  ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       attpar-extension=20

                       crypto-syntax =3D "a=3Dcrypto:" tag 1*WSP =
crypto-suite 1*WSP key-params
                                           *(1*WSP session-param) ; from =
RFC 4568
                       key-mgmt-syntax =3D "a=3D" key-mgmt-attribute  ; =
from RFC 4567
                       fingerprint-syntax =3D "a=3D" =
fingerprint-attribute / ; from RFC 4572

                       attpar-extension =3D  token=20

<att-cap-num> is an integer between 1 and 2^32-1 (both included) =
used to number the attribute capability=20

It is extensible for yet to be defined attributes for yet to be defined =
transport protocols.
Any extension to the capability negotiation framework should then define =
its own new attribute that carries attributes specific to that extension =
like its is currently done for media capabilites.
Any thoughts?
If I understand your proposal correctly, it has zero forward=20 compatibility with new or changed attributes that may be of relevance, = and=20 that seems like a rather undesirable property for a general framework. =
[Stach Thomas] Maybe the proposal above some = improvement, but the=20 syntax above is meant to be extensible using the = contruct=20 "attpar-extension=3D token". 
I=20 assumed that unknown attributes in the "a=3Dcapar:" lines are=20 ignored. This needs to be specified in the document.=20
Another case appears, when attributes are received, that = are=20 defined above but are related to transport protocols that are not = implemented=20 by the answerer.
Based on the content of creq/csup they should be ignored=20 or fallback to plain SDP should happen.
 /B> Stach, Thomas
Cc:=20 mmusic@ietf.org
Subject: Re: [MMUSIC] SDP Capability = Negotation:=20 Should the scope of a=3Dcapar:narrowed down to transport protocol=20 negotiation?



Stach, Thomas=20 wrote:=20 
Hi,=20

as a follow-up here is a proposal for an ABNF that restricts the =
defined/allowed values for "a=3Dcapar" to those necessary for transport =
protocol negotiation.=20

           a=3Dcapar: <att-tr-num> <att-par>
           <att-par> =3D rtcp-fb-syntax / ; from RFC 4585
                       crypto-syntax /
                       key-mgmt-syntax / =20
                       setup-attr / ; from RFC 4145
                       connection-attr / ; from RFC 4145
                       fingerprint-syntax /=20
                       floor-control-attribute / ; from RFC 4583
                       confid-attribute / ; from RFC 4583
                       userid-attribute / ; from RFC 4583
                       flute-tsi-line / ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       flute-channel-line / ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       fec-declaration-line / ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       fec-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       content-desc-line / ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       fec-oti-extension-line /  ; from =
RFC-mehta-rmt-flute-sdp-05.txt
                       attpar-extension=20

                       crypto-syntax =3D "a=3Dcrypto:" tag 1*WSP =
crypto-suite 1*WSP key-params
                                           *(1*WSP session-param) ; from =
RFC 4568
                       key-mgmt-syntax =3D "a=3D" key-mgmt-attribute  ; =
from RFC 4567
                       fingerprint-syntax =3D "a=3D" =
fingerprint-attribute / ; from RFC 4572

                       attpar-extension =3D  token=20

<att-cap-num> is an integer between 1 and 2^32-1 (both included) =
used to number the attribute capability=20

It is extensible for yet to be defined attributes for yet to be defined =
transport protocols.
Any extension to the capability negotiation framework should then define =
its own new attribute that carries attributes specific to that extension =
like its is currently done for media capabilites.
Any thoughts?
If I understand your proposal correctly, it has zero forward=20 compatibility with new or changed attributes that may be of relevance, = and=20 that seems like a rather undesirable property for a general framework. =
[Stach Thomas] Maybe the proposal above some = improvement, but the=20 syntax above is meant to be extensible using the = contruct=20 "attpar-extension=3D token". 
I=20 assumed that unknown attributes in the "a=3Dcapar:" lines are=20 ignored. This needs to be specified in the document.=20
Another case appears, when attributes are received, that = are=20 defined above but are related to transport protocols that are not = implemented=20 by the answerer.
Based on the content of creq/csup they should be ignored=20 or fallback to plain SDP should happen.
 Let's say we define = a=20 "crypto_v2" attribute tomorrow - how will that work ?
[Stach=20 Thomas] In this case the above ABNF must be extended by the usual = means=20 (definition of an additional token, IANA = registry)
Does=20 this make sense? 

Regards,
Thomas 

-- Flemming

[Stach=20 = Thomas] <snip> 
------_=_NextPart_001_01C74F5F.48B5BC7F-- --===============0730214331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0730214331==-- From mmusic-bounces@ietf.org Tue Feb 13 06:09:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvWn-0005Fm-0x; Tue, 13 Feb 2007 06:08:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvWk-0005Bh-VI for mmusic@ietf.org; Tue, 13 Feb 2007 06:08:51 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGvWa-0006uT-CW for mmusic@ietf.org; Tue, 13 Feb 2007 06:08:50 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by atvies1zqx.siemens.at with ESMTP id l1DB542R018502; Tue, 13 Feb 2007 12:05:04 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l1DB816D012262; Tue, 13 Feb 2007 12:08:29 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 12:08:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar: narrowed down to transport protocol negotiation? Date: Tue, 13 Feb 2007 12:08:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar: narrowed down to transport protocol negotiation? Thread-Index: AcdO9Eo8EjEmbAEfR+eZrjscLG8egwAU8EwwAASuh5A= From: "Stach, Thomas" To: "Flemming Andreasen" X-OriginalArrivalTime: 13 Feb 2007 11:08:08.0735 (UTC) FILETIME=[3E32C2F0:01C74F5F] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070213120504-0A8CABB0-26714542/0-0/0-15 X-purgate-size: 6036/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: Let's say we define = a=20 "crypto_v2" attribute tomorrow - how will that work ?
[Stach=20 Thomas] In this case the above ABNF must be extended by the usual = means=20 (definition of an additional token, IANA = registry)
Does=20 this make sense? 

Regards,
Thomas 

-- Flemming

[Stach=20 = Thomas] <snip> 
------_=_NextPart_001_01C74F5F.48B5BC7F-- --===============0730214331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0730214331==-- From mmusic-bounces@ietf.org Tue Feb 13 06:09:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvWn-0005Fm-0x; Tue, 13 Feb 2007 06:08:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvWk-0005Bh-VI for mmusic@ietf.org; Tue, 13 Feb 2007 06:08:51 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGvWa-0006uT-CW for mmusic@ietf.org; Tue, 13 Feb 2007 06:08:50 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by atvies1zqx.siemens.at with ESMTP id l1DB542R018502; Tue, 13 Feb 2007 12:05:04 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l1DB816D012262; Tue, 13 Feb 2007 12:08:29 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 12:08:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar: narrowed down to transport protocol negotiation? Date: Tue, 13 Feb 2007 12:08:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar: narrowed down to transport protocol negotiation? Thread-Index: AcdO9Eo8EjEmbAEfR+eZrjscLG8egwAU8EwwAASuh5A= From: "Stach, Thomas" To: "Flemming Andreasen" X-OriginalArrivalTime: 13 Feb 2007 11:08:08.0735 (UTC) FILETIME=[3E32C2F0:01C74F5F] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070213120504-0A8CABB0-26714542/0-0/0-15 X-purgate-size: 6036/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Fleming,=20 maybe my reasoning wasn't clear enough, I try to explain inline. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 > Sent: Monday, February 12, 2007 11:22 PM > To: Stach, Thomas > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] SDP Capability Negotation: Should the=20 > scope of a=3Dcapar: narrowed down to transport protocol negotiation? >=20 >=20 >=20 > Stach, Thomas wrote: > > Hi all, > > =20 > > in the context of SDP media capability negotiation it is=20 > currently discussed to define new SDP attributes like=20 > > a=3Dcmed:, a=3Dcenc:, a=3Dcfmt:, a=3Dcptmap: that negotiate=20 > parameters that usually go into the a=3Drtpmap:, a=3Dfmtp:, a=3Dptime, = etc. > > > > In draft-ietf-mmusic-sdp-capability-negotiation-01 the new=20 > SDP attribute a=3Dcapar: is going to be defined. > > It is basically a container that can carry everything that=20 > is specified as an SDP attribute. > > Hence it could carry e.g. a=3Drtpmap as well, which will=20 > introduce some ambiguity and unclear semantics in combination=20 > with media capability negotiation. > > =20 > Why is that ? It's just one of several building blocks that=20 > can be used=20 > to piece together a potential configuration - it really=20 > doesn't matter=20 > whether it's done with one or the other. I think it does matter.=20 In my view, the scope of draft-ietf-mmusic-sdp-capability-negotiation-01 = is the basic=20 framework and negotiation of transport protocols.=20 Dependend on the transport protocol various transport-specific = attributes must be negotiated.=20 This is done using the "a=3Dcapar:" attribute. I think the the corresponding semantics for attribute received in an = "a=3Dcapar:" line must be defined as well.=20 Currently "a=3Dcapar:" allows for transport of attributes that are not = needed to fulfill the task above. However, we cannot spell out the semantics for each attribute that can = potentially be found in the "a=3Dcapar:" line. Therefore I'd like to restrict the number of attributes that can be = included after "a=3Dcapar:". Another concern that I have is that already the base spec could be used = for a poor man's media capability negotiation. For the sake of discussion, I could build the following offer. v=3D0 o=3D- 25678 753849 IN IP4 128.96.41.1 s=3D c=3DIN IP4 128.96.41.1 t=3D0 0 m=3Daudio 3456 RTP/AVP 96 a=3Drtpmap:96 iLBC/8000 a=3Dcreq: v0 a=3Dctrpr:1 RTP/SAVP a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 = inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=3Dcapar:2 a=3Drtpmap:96 pcmu a=3Dcapar:3 a=3Dptime:20 a=3Dcapar:4 a=3Drtpmap:96 g729 a=3Dpcfg: t=3D1 a=3D1,2,3 a=3Dpcfg: t=3D1 a=3D1,4 Currently draft 01 of the base spec does not define the semantics for = such an offer.=20 This gives way for different interpretations. My interpretation would be that in this example payload type 96 has = different meaning whether the media stream is encrypted or not = (encrypted G711 with 20ms packets or encrypted G.729 vs. unencrypted = ILBC). =20 Such an interpretation could be expressed using the media capability = negotiation extension as follows: v=3D0 o=3D- 25678 753849 IN IP4 192.0.2.1/24 s=3D c=3DIN IP4 192.0.2.1/24 t=3D0 0 a=3Dcreq:v1 a=3Dcmed:1 audio pcmu g729=20 a=3Dctrpr:1 RTP/SAVP m=3Daudio 3456 RTP/AVP 96 a=3Drtpmap:96 iLBC/8000 a=3Dmcap:3 a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 = inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=3Dcapar:2 a=3Dptime:20 a=3Dpcfg:1 m=3D1 t=3D1 a=3D2=20 a=3Dpcfg:2 m=3D2 t=3D1=20 We would have two different ways to express the same information (modulo = different interpretations of the first offer).=20 This introduces more complexity for the parser at the receiving side.=20 I think that should be avoided. Additionally, I'd like to avoid that an = implementation of the base spec has to be prepared for something like = the first offer.=20 > > > > As the main driver for this initiative is best-://www1.ietf.org/mailman/listinfo/mmusic>, Errors-To: mmusic-bounces@ietf.org Fleming,=20 maybe my reasoning wasn't clear enough, I try to explain inline. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 > Sent: Monday, February 12, 2007 11:22 PM > To: Stach, Thomas > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] SDP Capability Negotation: Should the=20 > scope of a=3Dcapar: narrowed down to transport protocol negotiation? >=20 >=20 >=20 > Stach, Thomas wrote: > > Hi all, > > =20 > > in the context of SDP media capability negotiation it is=20 > currently discussed to define new SDP attributes like=20 > > a=3Dcmed:, a=3Dcenc:, a=3Dcfmt:, a=3Dcptmap: that negotiate=20 > parameters that usually go into the a=3Drtpmap:, a=3Dfmtp:, a=3Dptime, = etc. > > > > In draft-ietf-mmusic-sdp-capability-negotiation-01 the new=20 > SDP attribute a=3Dcapar: is going to be defined. > > It is basically a container that can carry everything that=20 > is specified as an SDP attribute. > > Hence it could carry e.g. a=3Drtpmap as well, which will=20 > introduce some ambiguity and unclear semantics in combination=20 > with media capability negotiation. > > =20 > Why is that ? It's just one of several building blocks that=20 > can be used=20 > to piece together a potential configuration - it really=20 > doesn't matter=20 > whether it's done with one or the other. I think it does matter.=20 In my view, the scope of draft-ietf-mmusic-sdp-capability-negotiation-01 = is the basic=20 framework and negotiation of transport protocols.=20 Dependend on the transport protocol various transport-specific = attributes must be negotiated.=20 This is done using the "a=3Dcapar:" attribute. I think the the corresponding semantics for attribute received in an = "a=3Dcapar:" line must be defined as well.=20 Currently "a=3Dcapar:" allows for transport of attributes that are not = needed to fulfill the task above. However, we cannot spell out the semantics for each attribute that can = potentially be found in the "a=3Dcapar:" line. Therefore I'd like to restrict the number of attributes that can be = included after "a=3Dcapar:". Another concern that I have is that already the base spec could be used = for a poor man's media capability negotiation. For the sake of discussion, I could build the following offer. v=3D0 o=3D- 25678 753849 IN IP4 128.96.41.1 s=3D c=3DIN IP4 128.96.41.1 t=3D0 0 m=3Daudio 3456 RTP/AVP 96 a=3Drtpmap:96 iLBC/8000 a=3Dcreq: v0 a=3Dctrpr:1 RTP/SAVP a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 = inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=3Dcapar:2 a=3Drtpmap:96 pcmu a=3Dcapar:3 a=3Dptime:20 a=3Dcapar:4 a=3Drtpmap:96 g729 a=3Dpcfg: t=3D1 a=3D1,2,3 a=3Dpcfg: t=3D1 a=3D1,4 Currently draft 01 of the base spec does not define the semantics for = such an offer.=20 This gives way for different interpretations. My interpretation would be that in this example payload type 96 has = different meaning whether the media stream is encrypted or not = (encrypted G711 with 20ms packets or encrypted G.729 vs. unencrypted = ILBC). =20 Such an interpretation could be expressed using the media capability = negotiation extension as follows: v=3D0 o=3D- 25678 753849 IN IP4 192.0.2.1/24 s=3D c=3DIN IP4 192.0.2.1/24 t=3D0 0 a=3Dcreq:v1 a=3Dcmed:1 audio pcmu g729=20 a=3Dctrpr:1 RTP/SAVP m=3Daudio 3456 RTP/AVP 96 a=3Drtpmap:96 iLBC/8000 a=3Dmcap:3 a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 = inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=3Dcapar:2 a=3Dptime:20 a=3Dpcfg:1 m=3D1 t=3D1 a=3D2=20 a=3Dpcfg:2 m=3D2 t=3D1=20 We would have two different ways to express the same information (modulo = different interpretations of the first offer).=20 This introduces more complexity for the parser at the receiving side.=20 I think that should be avoided. Additionally, I'd like to avoid that an = implementation of the base spec has to be prepared for something like = the first offer.=20 > > > > As the main driver for this initiative is best-effort SRTP=20 > and as we already received complaints about complexity, > > I wonder if we should not lay the hurdle for implementation=20 > even lower by defining 4 clearly separate modules for basic > > SDP capability negotiation, namely "best-effort srtp",=20 > "comedia", "bfcp" and "flute".=20 > > Support for each could be indicated using 4 option tags for=20 > a=3Dcsup/creq:.=20 > > Replacing the a=3Dcapar by 4 specifc attributes would also be=20 > something to consider in this context. > > > > The modules could be separately implemented as needed for=20 > the specific application of the capabilitiy negotiation framework. > > > > Comments? > > =20 > It looks like the SDP equivalent of coming up with specific feature=20 > definition and identification in SIP as opposed to producing=20 > and using a=20 > general framework. We received AD guidance to come up with a general=20 > framework that could be used for things beyond best-effort SRTP and=20 > althought you could argue that your proposal still allows for=20 > that, it=20 > doesn't encourage any kind of generality in an actual=20 > implementation and=20 > we might as well define point solutions for each of these instead. >=20 > You can register me as opposed. >=20 > -- Flemming Fleming, I agree. I think I overshot here, but still I'd like to see a restriction on the = number of=20 attributes that have to be dealt with when only the base spec is = implemented. >=20 > > mit freundlichen Gr=FC=DFen/Kind Regards > > > > Dr.-Ing. Thomas Stach=20 > > PSE KB B1=20 > > Siemens Austria AG=20 > > Gudrunstr. 11 Tel: +43-51707-47364=20 > > A-1100 Vienna Fax: +43-51707-56992=20 > > mailto:thomas.stach@siemens.com =20 > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > =20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic effort SRTP=20 > and as we already received complaints about complexity, > > I wonder if we should not lay the hurdle for implementation=20 > even lower by defining 4 clearly separate modules for basic > > SDP capability negotiation, namely "best-effort srtp",=20 > "comedia", "bfcp" and "flute".=20 > > Support for each could be indicated using 4 option tags for=20 > a=3Dcsup/creq:.=20 > > Replacing the a=3Dcapar by 4 specifc attributes would also be=20 > something to consider in this context. > > > > The modules could be separately implemented as needed for=20 > the specific application of the capabilitiy negotiation framework. > > > > Comments? > > =20 > It looks like the SDP equivalent of coming up with specific feature=20 > definition and identification in SIP as opposed to producing=20 > and using a=20 > general framework. We received AD guidance to come up with a general=20 > framework that could be used for things beyond best-effort SRTP and=20 > althought you could argue that your proposal still allows for=20 > that, it=20 > doesn't encourage any kind of generality in an actual=20 > implementation and=20 > we might as well define point solutions for each of these instead. >=20 > You can register me as opposed. >=20 > -- Flemming Fleming, I agree. I think I overshot here, but still I'd like to see a restriction on the = number of=20 attributes that have to be dealt with when only the base spec is = implemented. >=20 > > mit freundlichen Gr=FC=DFen/Kind Regards > > > > Dr.-Ing. Thomas Stach=20 > > PSE KB B1=20 > > Siemens Austria AG=20 > > Gudrunstr. 11 Tel: +43-51707-47364=20 > > A-1100 Vienna Fax: +43-51707-56992=20 > > mailto:thomas.stach@siemens.com =20 > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > =20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 13 09:46:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyvH-0007Fr-Ti; Tue, 13 Feb 2007 09:46:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyvF-0007EG-QN for mmusic@ietf.org; Tue, 13 Feb 2007 09:46:22 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGysd-0000jX-RZ for mmusic@ietf.org; Tue, 13 Feb 2007 09:43:41 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Feb 2007 06:43:39 -0800 X-IronPort-AV: i="4.14,163,1170662400"; d="scan'208,217"; a="112128238:sNHT84008295" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1DEhdbv000617 for ; Tue, 13 Feb 2007 06:43:39 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1DEhdDk024431 for ; Tue, 13 Feb 2007 06:43:39 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 06:43:39 -0800 Received: from [10.21.99.79] ([10.21.99.79]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 06:43:38 -0800 Message-ID: <45D1CE99.8000103@cisco.com> Date: Tue, 13 Feb 2007 09:43:37 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 13 Feb 2007 14:43:38.0721 (UTC) FILETIME=[59120D10:01C74F7D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7985; t=1171377819; x=1172241819; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotation=3A=20Minutes=20of=202/6/07=20de sign=20team=20conference=0A=20call |Sender:=20; bh=QUtiJhsogANBLqpWQEZDHkZAP3z2fn800v+0LQfbL6s=; b=tbh7jFjcUZIWgjUFwvFJ/DHMXyjfBhkvCvX+qRCo9ZaGUqfVuYd/J2F8akl0KVJE/dyNJRjF 7tFnC3VGrj6T5Ofwk2gV/FyNzcQgXdLLGIJ4OxgXYlXOwV1Bm6KIxZmU; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Subject: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design team conference call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1465273926==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1465273926== Content-Type: multipart/alternative; boundary="------------000103000908000305040908" This is a multi-part message in MIME format. --------------000103000908000305040908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings The SDP Capability Negotiation Design team had a conference call on 2/6/07. The attendees were: Bob Gilman Matt Lepinski Roni Even Flemming Andreasen Thomas Stach Colin Perkins Joerg Ott The call centered on the new media capabilities document, which Roni and Bob have been working on. The issues discussed were: 1) Relationship to RFC 3407 The core capability negotiation document and the media capabilities document provide everything that RFC 3407 does (and then some). In lieu of this, the team discussed whether these two documents should obsolete RFC 3407 or not. The intent is for this work to replace RFC 3407 going forward, however it is possible that interworking with RFC 3407 may still be required. 2) Numbering of media capabilites (codecs) Discussion around whether we need to explicitly definie media types in the "m=" line. This is similar to the discussion we had around transport capabilities and the conclusion is the same: we will require them to be specified explicitly, even though they are already part of the "m=" line. 3) Discussion around how we specify the same codecs with different parameters Currently will have multiple instances in cmed line. Alternatives include: - Changing pcfg attribute to specify potential configurations differently. - Another level of indirection in the cmed line allowing for composite capabilities to be built (and referenced in the pcfg attribute). . The authors will look further into this. 4) Discussion around what goes in answers. The m= line in the answer needs to be in accordance with the accepted configuration (the way it's done currently). The "acfg" attribute in the core should be changed to just reference the pcfg attribute from the offer (as opposed to spell it out). 5) Latent configuration attribute Further work is needed on this - the authors are currently debating format and contents. It was suggested that the lcfg: attribute need not include all the attributes of a typical pcfg: line; it might be enough to announce the capability to do video, for example, without specifying all the details. The details would, of course, be carried in the subsequent offer, if any. This would avoid complicating and expanding the initial offer - after all, the latent configuration might never be used. The tradeoff, of course, is that it might turn out that the two parties cannot support a compatible set of attributes. It was decided to examine both options and make a decision after that. The latent configuration may require the transport parameter(s). One question (which arose before): if we do include attributes within the lcfg: attribute, one of those is quite likely to be a crypto: attribute, so what do we do with the key material? 6) Attributes in "capar" The team discussed Thomas Stach's email with respect to attributes permitted (or forbidden) within capar: attribute lines. Thomas agreed to investigate further to help us understand the uses of the attributes he identified. He noted that some may be obsolete; he will try to look at the most useful first. The meeting concluded with Bob and Roni promising to continue work on the version 2 document in order to send it to the list before the next meeting. Thanks (and thanks to Bob for help with taking notes) -- Flemming --------------000103000908000305040908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

The SDP Capability Negotiation Design team had a conference call on 2/6/07. The attendees were:

    Bob Gilman
    Matt Lepinski
    Roni Even
    Flemming Andreasen
    Thomas Stach
    Colin Perkins
    Joerg Ott

The call centered on the new media capabilities document, which Roni and Bob have been working on. The issues discussed were:

1) Relationship to RFC 3407
The core capability negotiation document and the media capabilities document provide everything that RFC 3407 does (and then some). In lieu of this, the team discussed whether these two documents should obsolete RFC 3407 or not. The intent is for this work to replace RFC 3407 going forward, however it is possible that interworking with RFC 3407 may still be required.

2) Numbering of media capabilites (codecs)
Discussion around whether we need to explicitly definie media types in the "m=" line. This is similar to the discussion we had around transport capabilities and the conclusion is the same: we will require them to be specified explicitly, even though they are already part of the "m=" line.

3) Discussion around how we specify the same codecs with different parameters
Currently will have multiple instances in cmed line. Alternatives include:
- Changing pcfg attribute to specify potential configurations differently.
- Another level of indirection in the cmed line allowing for composite capabilities to be built (and referenced in the pcfg attribute). .

The authors will look further into this.

 
4) Discussion around what goes in answers.

The m= line in the answer needs to be in accordance with the accepted configuration (the way it's done currently). The "acfg" attribute in the core should be changed to just reference the pcfg attribute from the offer (as opposed to spell it out).

5) Latent configuration attribute
Further work is needed on this - the authors are currently debating format and contents.
It was suggested that the lcfg: attribute need not include all the attributes of a typical pcfg: line; it might be enough to announce the capability to do video, for example, without specifying all the details. The details would, of course, be carried in the subsequent offer, if any. This would avoid complicating and expanding the initial offer - after all, the latent configuration might never be used. The tradeoff, of course, is that it might turn out that the two parties cannot support a compatible set of attributes. It was decided to examine both options and make a decision after that. The latent configuration may require the transport parameter(s). One question (which arose before): if we do include attributes within the lcfg: attribute, one of those is quite likely to be a crypto: attribute, so what do we do with the key material?

6) Attributes in "capar"
The team discussed Thomas Stach's email with respect to attributes permitted (or forbidden) within capar: attribute lines. Thomas agreed to investigate further to help us understand the uses of the attributes he identified. He noted that some may be obsolete; he will try to look at the most useful first.


The meeting concluded with Bob and Roni promising to continue work on the version 2 document in order to send it to the list before the next meeting.

Thanks (and thanks to Bob for help with taking notes)

-- Flemming






--------------000103000908000305040908-- --===============1465273926== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1465273926==-- From mmusic-bounces@ietf.org Wed Feb 14 15:51:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5R-0006SZ-Vc; Wed, 14 Feb 2007 15:50:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5F-0006Pn-OV; Wed, 14 Feb 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHR5F-0008NW-Ax; Wed, 14 Feb 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BFC231760E; Wed, 14 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HHR4j-0004JX-UP; Wed, 14 Feb 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Feb 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart 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 : SDP media capabilities Negotiation Author(s) : F. Andreasen, et al. Filename : draft-ietf-mmusic-sdp-media-capabilities-00.txt Pages : 22 Date : 2007-2-14 Session Description Protocol (SDP) capability negotiation provides a general framework for negotiation capabilities in SDP. The base framework defines only capabilities for negotiation transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-media-capabilities-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-14123026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-media-capabilities-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-14123026.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Wed Feb 14 15:51:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5O-0006Rk-7C; Wed, 14 Feb 2007 15:50:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5F-0006PQ-Iw; Wed, 14 Feb 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHR5E-0008NN-5t; Wed, 14 Feb 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1BDA52AD72; Wed, 14 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HHR4j-0004JF-Qv; Wed, 14 Feb 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Feb 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart 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 : SDP Capability Negotiation Author(s) : F. Andreasen Filename : draft-ietf-mmusic-sdp-capability-negotiation-02.txt Pages : 29 Date : 2007-2-14 The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback. The purpose of this document is to address that and other real-life limitations by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The solution provided in this document provides a general SDP capability negotiation framework. It also defines specifically how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g. media types and formats) may be provided in other documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-capability-negotiation-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-14121809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-capability-negotiation-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-14121809.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Fri Feb 16 02:42:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxiv-00077E-UO; Fri, 16 Feb 2007 02:41:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxit-00074r-Ug; Fri, 16 Feb 2007 02:41:39 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHxis-0003OI-Fo; Fri, 16 Feb 2007 02:41:39 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1G7faF2007255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2007 23:41:37 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1G7faIw028741; Thu, 15 Feb 2007 23:41:36 -0800 Received: from NAEX01.qualcomm.com ([129.46.51.60]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 23:41:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Feb 2007 23:41:36 -0800 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B028B0ACC@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on SDP BW attribute for media bitrate in 'send' direction ( draft-hdesinen-mmusic-oa-send-bw-attr-00.txt ) Thread-Index: AcdRneNSWBGfPE2eQB2K8M4MrfgUlw== From: "Desineni, Harikishan" To: , X-OriginalArrivalTime: 16 Feb 2007 07:41:36.0100 (UTC) FILETIME=[E2D9FA40:01C7519D] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [MMUSIC] Draft on SDP BW attribute for media bitrate in 'send' direction ( draft-hdesinen-mmusic-oa-send-bw-attr-00.txt ) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org AVT & MMUSIC, Here is a draft which defines a new bandwidth attribute for SDP Offer/Answer model. =3D=3D=3D=3D=3D=3D=3D Abstract: "This document defines a new SDP bandwidth attribute that can be used to signal the maximum media bitrate in 'send' direction of a stream in SDP offer/answer model." =3D=3D=3D=3D=3D=3D=3D=3D=3D -01 version of the draft is not yet available on IETF server. Until then it can be viewed at http://people.qualcomm.com/hdesinen/draft-hdesinen-mmusic-oa-send-bw-att r-01.txt -00 is available on IETF server at http://www.ietf.org/internet-drafts/draft-hdesinen-mmusic-oa-send-bw-att r-00.txt Please review the latest version (-01) of the draft and post your comments. Thanks, Hari _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Feb 18 10:42:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIoBF-0000z0-9f; Sun, 18 Feb 2007 10:42:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIoBD-0000yM-KE for mmusic@ietf.org; Sun, 18 Feb 2007 10:42:23 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIoBB-0000vD-Tu for mmusic@ietf.org; Sun, 18 Feb 2007 10:42:23 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2007 07:42:21 -0800 X-IronPort-AV: i="4.14,187,1170662400"; d="scan'208,217"; a="361503292:sNHT87149692" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1IFgLjc020837 for ; Sun, 18 Feb 2007 07:42:21 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1IFgLUw001476 for ; Sun, 18 Feb 2007 07:42:21 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Feb 2007 07:42:21 -0800 Received: from [10.21.154.28] ([10.21.154.28]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Feb 2007 07:42:20 -0800 Message-ID: <45D873D8.9060406@cisco.com> Date: Sun, 18 Feb 2007 10:42:16 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 18 Feb 2007 15:42:20.0889 (UTC) FILETIME=[6082FC90:01C75373] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8454; t=1171813341; x=1172677341; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotation=3A=20Minutes=20of=202/13/07=20d esign=20team=20conference=0A=20call |Sender:=20; bh=xQCBhFuIbV3zM+Ki8ajFYxlly7OizsiMbKFgLik4mNM=; b=pHT6PBEq87Xjf3PPNMdh8X5k5P9ILk8hAUJzKQfb4bd4Bq5m1CbKjdaUNvcTLSe0Z9usFlto svNbKmf4NTjE2fPBHD8/91SRqcEaYDWLq9th945Vph+sVnvdgTQAgP8I; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Subject: [MMUSIC] SDP Capability Negotation: Minutes of 2/13/07 design team conference call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0707908416==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0707908416== Content-Type: multipart/alternative; boundary="------------030005070606090502020800" This is a multi-part message in MIME format. --------------030005070606090502020800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings The SDP Capability Negotiation Design team had a conference call on 2/13/07. The attendees were: Bob Gilman Thomas Stach Flemming Andreasen Roni Even Colin Perkins Matt Lepinski Joerg Ott 1) The team first discussed the new version of the core SDP capability negotiation document (draft-ietf-mmusic-sdp-capability-negotiation-02.txt) 1a) Contrary to what was discussed last week, the actual configuration attribute still includes the parameters from the potential configuration attribute that were selected from the offer. The reason for this is that a single potential configuration attribute can include alternatives, and the offerer may need to know which alternative was chosen (e.g. RTP or SRTP) without having to try and infer that somehow. 1b) Discussion around limiting attributes to use with the attribute capabilities ("a=acap") Thomas had proposed specifying explicitly allowed attributes only, however Flemming had some concerns with that. After additional discussion, the team had consensus to specify which well-known attributes SHOULD NOT be used with it. More text is needed on this (e.g. rtpmap and fmtp, although rtpmap is up for discussion with respect to media before answer). 1c) Are capabilities additive or do they completely replace the actual configuration ? Currently, the document does not specify it one way or the other. It was noted at as an issue that needs further consideration and clear specification in the document - currently, it's not clear what the right answer is. 1d) "v0" option tag During discussion of the media capabilities, it was decided that we should have a more descriptive option tag name for the base protocol (e.g. "cap_v0"). 2) The team then discussed the media capabilities document (draft-ietf-mmusic-sdp-media-capabilities-00.txt) 2a) Structure of media capabilities It is not clear that the current structure around media capabilities is the right one. We need to look further into non-RTP based transports as well as more complicated capabilities to verify. SDPng found that supporting things like - Forward Error Correction - Redundancy encoding - Layered Codecs was non-trivial and requried quite a bit of work to encompass. We need to look further into this. 2b) The "a=cmed" attribute The "cmed" uses implicit references to media capabilities. There is a concern with middle-boxes enforcing policies and potentially reordering media formats. Consensus to have explicit capabilities for all media capabilities instead. 2c) Option tags The base protocol defines the option tag "v0", and the media capabilities document defines the option tag "v1", however the media capabilities document should not be seen as a replacement/update to the base protocol, but rather just an extension. A different (and more descriptive option tag) should therefore be used for the media capabilities (same goes for the base protocol). 2d) Latent Configurations Discussion around whether attributes should be allowed. Consensus that they should. "crypto" attribute is an example of an attribute that is not particulary well-suited as a latent configuration capabily since it includes keying material. Still, it can be provided. If a more suitable format is desired for latent configurations, then new attributes can be defined, however we should not modify existing attributes. Thanks -- Flemming --------------030005070606090502020800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

The SDP Capability Negotiation Design team had a conference call on 2/13/07. The attendees were:

    Bob Gilman
    Thomas Stach
    Flemming Andreasen
    Roni Even
    Colin Perkins
    Matt Lepinski
    Joerg Ott

1) The team first discussed the new version of the core SDP capability negotiation document (draft-ietf-mmusic-sdp-capability-negotiation-02.txt)
1a) Contrary to what was discussed last week, the actual configuration attribute still includes the parameters from the potential configuration attribute that were selected from the offer. The reason for this is that a single potential configuration attribute can include alternatives, and the offerer may need to know which alternative was chosen (e.g. RTP or SRTP) without having to try and infer that somehow.

1b) Discussion around limiting attributes to use with the attribute capabilities ("a=acap")
Thomas had proposed specifying explicitly allowed attributes only, however Flemming had some concerns with that. After additional discussion, the team had consensus to specify which well-known attributes SHOULD NOT be used with it. More text is needed on this (e.g. rtpmap and fmtp, although rtpmap is up for discussion with respect to media before answer).

1c) Are capabilities additive or do they completely replace the actual configuration ?
Currently, the document does not specify it one way or the other. It was noted at as an issue that needs further consideration and clear specification in the document - currently, it's not clear what the right answer is.

1d) "v0" option tag
During discussion of the media capabilities, it was decided that we should have a more descriptive option tag name for the base protocol (e.g. "cap_v0").

2) The team then discussed the media capabilities document (draft-ietf-mmusic-sdp-media-capabilities-00.txt)
2a) Structure of media capabilities
It is not clear that the current structure around media capabilities is the right one. We need to look further into non-RTP based transports as well as more complicated capabilities to verify. SDPng found that supporting things like
- Forward Error Correction
- Redundancy encoding
- Layered Codecs
was non-trivial and requried quite a bit of work to encompass. We need to look further into this.

2b) The "a=cmed" attribute
The "cmed" uses implicit references to media capabilities. There is a concern with middle-boxes enforcing policies and potentially reordering media formats. Consensus to have explicit capabilities for all media capabilities instead.

2c) Option tags
The base protocol defines the option tag "v0", and the media capabilities document defines the option tag "v1", however the media capabilities document should not be seen as a replacement/update to the base protocol, but rather just an extension. A different (and more descriptive option tag) should therefore be used for the media capabilities (same goes for the base protocol).

2d) Latent Configurations
Discussion around whether attributes should be allowed. Consensus that they should. "crypto" attribute is an example of an attribute that is not particulary well-suited as a latent configuration capabily since it includes keying material. Still, it can be provided. If a more suitable format is desired for latent configurations, then new attributes can be defined, however we should not modify existing attributes.


Thanks

-- Flemming

--------------030005070606090502020800-- --===============0707908416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0707908416==-- From mmusic-bounces@ietf.org Mon Feb 19 22:01:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLEf-0007ya-TX; Mon, 19 Feb 2007 22:00:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLEe-0007wO-PM for mmusic@ietf.org; Mon, 19 Feb 2007 22:00:08 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJLEd-0003Yh-G7 for mmusic@ietf.org; Mon, 19 Feb 2007 22:00:08 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2007 19:00:07 -0800 X-IronPort-AV: i="4.14,193,1170662400"; d="scan'208"; a="390945998:sNHT74574140" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1K306vA008426 for ; Mon, 19 Feb 2007 19:00:06 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1K306ho025082 for ; Mon, 19 Feb 2007 19:00:06 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 19:00:06 -0800 Received: from [10.21.154.28] ([10.21.154.28]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 19:00:05 -0800 Message-ID: <45DA6434.2060708@cisco.com> Date: Mon, 19 Feb 2007 22:00:04 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2007 03:00:05.0856 (UTC) FILETIME=[39224600:01C7549B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=560; t=1171940406; x=1172804406; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotiation=3A=20Updated=20solution=20docu ment=20(-03) |Sender:=20; bh=YHOrtDwo7DKSF9CZgRhQmX/6U7Gx2bsCjoT0yz87nq0=; b=jf1SmKqfM8lmpPchthD4Z3XK8LOsPqbIaAxfb3TIuzDqxEmLbK/70cfmgpuAsnckAuFeSRFj BMgjiI4tyXM88g7sME2j2i8EuyF9nY3vG7dhRbH5ZS6kBQqGUpMhMNeQ; Authentication-Results: sj-dkim-6; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Greetings I have just submitted an updated solution document as draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which you can retrieve from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-03.txt until it appears in the archives. The list of changes (from Section 9.1): o Base option tag name changed from "v0" to "cap-v0". o Added new section on extension capability attributes o Firmed up offer/answer procedures. o Added security considerations o Added IANA considerations Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 20 03:29:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQMx-0002X6-FU; Tue, 20 Feb 2007 03:29:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQMw-0002X0-Nk for mmusic@ietf.org; Tue, 20 Feb 2007 03:29:02 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJQMv-0007iJ-Dd for mmusic@ietf.org; Tue, 20 Feb 2007 03:29:02 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60475 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HJQMu-0005Dc-NW; Tue, 20 Feb 2007 08:29:00 +0000 In-Reply-To: <45DA6434.2060708@cisco.com> References: <45DA6434.2060708@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <680E6487-7D2A-4E50-98D9-33DA960EE51D@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) Date: Tue, 20 Feb 2007 08:28:58 +0000 To: Flemming Andreasen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Flemming, On 20 Feb 2007, at 03:00, Flemming Andreasen wrote: > I have just submitted an updated solution document as draft-ietf- > mmusic-sdp-capability-negotiation-03.txt, which you can retrieve > from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp- > capability-negotiation-03.txt until it appears in the archives. > > The list of changes (from Section 9.1): > o Base option tag name changed from "v0" to "cap-v0". > o Added new section on extension capability attributes > o Firmed up offer/answer procedures. > o Added security considerations > o Added IANA considerations This is looking good, especially with the clarifications to the offer/ answer procedures. I would like to highlight one design choice on the list: when attributes are included in "a=acap:" lines of a potential configuration, those attributes are added to the set in the actual configuration during the offer/answer exchange. This may sometimes result in meaningless attributes, as is noted in Section 3.5.2 (half way down page 25). An alternative is for the attributes in the "a=acap:" lines of a potential configuration to replace those in the actual configuration if that potential configuration is accepted. This removes the potential for meaningless attributes, and makes negotiation simpler, at the cost of needing to duplicate attributes that are common to the actual and potential configurations. I'd like to hear opinions on this choice. I have a slight preference for changing the draft so attributes in potential configurations replace those in the actual during the negotiation phase, since that seems conceptually simpler. I'm curious whether people believe it would introduce too much overhead though. Comments? -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 20 04:00:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQrT-00009Q-8L; Tue, 20 Feb 2007 04:00:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQrR-00009K-Lh for mmusic@ietf.org; Tue, 20 Feb 2007 04:00:33 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJQrQ-0008Bj-Oo for mmusic@ietf.org; Tue, 20 Feb 2007 04:00:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design team conference call Date: Tue, 20 Feb 2007 11:00:05 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C0457B986@IsrExch01.israel.polycom.com> In-Reply-To: <45D1CE99.8000103@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design team conference call Thread-Index: AcdPfiIPCcFB+u7tQEOA7Rxf0XvjPAFTuFsA From: "Even, Roni" To: "Flemming Andreasen" , "mmusic" X-Spam-Score: 0.1 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0198937097==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0198937097== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C754CD.8F431C51" This is a multi-part message in MIME format. ------_=_NextPart_001_01C754CD.8F431C51 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Item number 2 about explicitly numbering of media capabilities. There are two ways to do it. The first it to specify the subtypes in the = cmed line. The second is to use a media level mcap attribute that will = assign a number to the subtypes in the m line. The current version use = the second option. =20 Roni=20 =20 ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: Tuesday, February 13, 2007 4:44 PM To: mmusic Subject: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design = team conference call =20 Greetings=20 The SDP Capability Negotiation Design team had a conference call on = 2/6/07. The attendees were: Bob Gilman Matt Lepinski Roni Even Flemming Andreasen Thomas Stach Colin Perkins Joerg Ott The call centered on the new media capabilities document, which Roni and = Bob have been working on. The issues discussed were: 1) Relationship to RFC 3407 The core capability negotiation document and the media capabilities = document provide everything that RFC 3407 does (and then some). In lieu = of this, the team discussed whether these two documents should obsolete = RFC 3407 or not. The intent is for this work to replace RFC 3407 going = forward, however it is possible that interworking with RFC 3407 may = still be required.=20 2) Numbering of media capabilites (codecs) Discussion around whether we need to explicitly definie media types in = the "m=3D" line. This is similar to the discussion we had around = transport capabilities and the conclusion is the same: we will require = them to be specified explicitly, even though they are already part of = the "m=3D" line.=20 3) Discussion around how we specify the same codecs with different = parameters Currently will have multiple instances in cmed line. Alternatives = include: - Changing pcfg attribute to specify potential configurations = differently. - Another level of indirection in the cmed line allowing for composite = capabilities to be built (and referenced in the pcfg attribute). .=20 The authors will look further into this.=20 =20 4) Discussion around what goes in answers. The m=3D line in the answer needs to be in accordance with the accepted = configuration (the way it's done currently). The "acfg" attribute in the = core should be changed to just reference the pcfg attribute from the = offer (as opposed to spell it out).=20 5) Latent configuration attribute Further work is needed on this - the authors are currently debating = format and contents. It was suggested that the lcfg: attribute need not include all the = attributes of a typical pcfg: line; it might be enough to announce the = capability to do video, for example, without specifying all the details. = The details would, of course, be carried in the subsequent offer, if = any. This would avoid complicating and expanding the initial offer - = after all, the latent configuration might never be used. The tradeoff, = of course, is that it might turn out that the two parties cannot support = a compatible set of attributes. It was decided to examine both options = and make a decision after that. The latent configuration may require the = transport parameter(s). One question (which arose before): if we do = include attributes within the lcfg: attribute, one of those is quite = likely to be a crypto: attribute, so what do we do with the key = material? 6) Attributes in "capar" The team discussed Thomas Stach's email with respect to attributes = permitted (or forbidden) within capar: attribute lines. Thomas agreed to = investigate further to help us understand the uses of the attributes he = identified. He noted that some may be obsolete; he will try to look at = the most useful first. The meeting concluded with Bob and Roni promising to continue work on = the version 2 document in order to send it to the list before the next = meeting. Thanks (and thanks to Bob for help with taking notes) -- Flemming=20 ------_=_NextPart_001_01C754CD.8F431C51 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

=A0Item number 2 about explicitly = numbering of media capabilities.

There are two ways to do it. The = first it to specify the subtypes in the cmed line. The second is to use a media = level mcap attribute that will assign a number to the subtypes in the m line. The = current version use the second option.

 

Roni

 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Tuesday, February = 13, 2007 4:44 PM
To: mmusic
Subject: [MMUSIC] SDP = Capability Negotation: Minutes of 2/6/07 design team conference = call

 

Greetings

The SDP Capability Negotiation Design team had a conference call on = 2/6/07. The attendees were:

    Bob Gilman
    Matt Lepinski
    Roni Even
    Flemming Andreasen
    Thomas Stach
    Colin Perkins
    Joerg Ott

The call centered on the new media capabilities document, which Roni and = Bob have been working on. The issues discussed were:

1) Relationship to RFC 3407
The core capability negotiation document and the media capabilities = document provide everything that RFC 3407 does (and then some). In lieu of this, = the team discussed whether these two documents should obsolete RFC 3407 or = not. The intent is for this work to replace RFC 3407 going forward, however it is possible that interworking with RFC 3407 may still be required.

2) Numbering of media capabilites (codecs)
Discussion around whether we need to explicitly definie media types in = the "m=3D" line. This is similar to the discussion we had around = transport capabilities and the conclusion is the same: we will require them to be specified explicitly, even though they are already part of the = "m=3D" line.

3) Discussion around how we specify the same codecs with different = parameters
Currently will have multiple instances in cmed line. Alternatives = include:
- Changing pcfg attribute to specify potential configurations = differently.
- Another level of indirection in the cmed line allowing for composite capabilities to be built (and referenced in the pcfg attribute). . =

The authors will look further into this.

 
4) Discussion around what goes in answers.

The m=3D line = in the answer needs to be in accordance with the accepted configuration (the way it's = done currently). The "acfg" attribute in the core should be changed = to just reference the pcfg attribute from the offer (as opposed to spell it = out).

5) Latent configuration attribute
Further work is needed on this - the authors are currently debating = format and contents.
It was suggested that the lcfg: attribute need not include all the = attributes of a typical pcfg: line; it might be enough to announce the capability = to do video, for example, without specifying all the details. The details = would, of course, be carried in the subsequent offer, if any. This would avoid complicating and expanding the initial offer - after all, the latent configuration might never be used. The tradeoff, of course, is that it = might turn out that the two parties cannot support a compatible set of = attributes. It was decided to examine both options and make a decision after that. The = latent configuration may require the transport parameter(s). One question = (which arose before): if we do include attributes within the lcfg: attribute, one of = those is quite likely to be a crypto: attribute, so what do we do with the key material?

6) Attributes in "capar"
The team discussed Thomas Stach's email with respect to attributes = permitted (or forbidden) within capar: attribute lines. Thomas agreed to = investigate further to help us understand the uses of the attributes he identified. = He noted that some may be obsolete; he will try to look at the most useful = first.


The meeting concluded with Bob and Roni promising to continue work on = the version 2 document in order to send it to the list before the next = meeting.

Thanks (and thanks to Bob for help with taking notes)

-- Flemming





------_=_NextPart_001_01C754CD.8F431C51-- --===============0198937097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0198937097==-- From mmusic-bounces@ietf.org Tue Feb 20 06:55:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTaA-0007Se-JL; Tue, 20 Feb 2007 06:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTa8-0007Ja-W9 for mmusic@ietf.org; Tue, 20 Feb 2007 06:54:53 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJTa7-0004O9-OP for mmusic@ietf.org; Tue, 20 Feb 2007 06:54:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design teamconference call Date: Tue, 20 Feb 2007 13:54:54 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C0457B9F2@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C0457B986@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design teamconference call Thread-Index: AcdPfiIPCcFB+u7tQEOA7Rxf0XvjPAFTuFsAAAYtCwA= From: "Even, Roni" To: "Even, Roni" , "Flemming Andreasen" , "mmusic" X-Spam-Score: 0.1 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1062222651==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1062222651== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C754E5.EBFFB5C7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C754E5.EBFFB5C7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am answering myself. The reason for specifying in cmed line is because = the order of codecs in the m-line may change by an intermediary that = does not support the capability negotiation. Roni =20 ________________________________ From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Tuesday, February 20, 2007 11:00 AM To: Flemming Andreasen; mmusic Subject: RE: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 = design teamconference call =20 Hi, Item number 2 about explicitly numbering of media capabilities. There are two ways to do it. The first it to specify the subtypes in the = cmed line. The second is to use a media level mcap attribute that will = assign a number to the subtypes in the m line. The current version use = the second option. =20 Roni=20 =20 ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: Tuesday, February 13, 2007 4:44 PM To: mmusic Subject: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design = team conference call =20 Greetings=20 The SDP Capability Negotiation Design team had a conference call on = 2/6/07. The attendees were: Bob Gilman Matt Lepinski Roni Even Flemming Andreasen Thomas Stach Colin Perkins Joerg Ott The call centered on the new media capabilities document, which Roni and = Bob have been working on. The issues discussed were: 1) Relationship to RFC 3407 The core capability negotiation document and the media capabilities = document provide everything that RFC 3407 does (and then some). In lieu = of this, the team discussed whether these two documents should obsolete = RFC 3407 or not. The intent is for this work to replace RFC 3407 going = forward, however it is possible that interworking with RFC 3407 may = still be required.=20 2) Numbering of media capabilites (codecs) Discussion around whether we need to explicitly definie media types in = the "m=3D" line. This is similar to the discussion we had around = transport capabilities and the conclusion is the same: we will require = them to be specified explicitly, even though they are already part of = the "m=3D" line.=20 3) Discussion around how we specify the same codecs with different = parameters Currently will have multiple instances in cmed line. Alternatives = include: - Changing pcfg attribute to specify potential configurations = differently. - Another level of indirection in the cmed line allowing for composite = capabilities to be built (and referenced in the pcfg attribute). .=20 The authors will look further into this.=20 =20 4) Discussion around what goes in answers. The m=3D line in the answer needs to be in accordance with the accepted = configuration (the way it's done currently). The "acfg" attribute in the = core should be changed to just reference the pcfg attribute from the = offer (as opposed to spell it out).=20 5) Latent configuration attribute Further work is needed on this - the authors are currently debating = format and contents. It was suggested that the lcfg: attribute need not include all the = attributes of a typical pcfg: line; it might be enough to announce the = capability to do video, for example, without specifying all the details. = The details would, of course, be carried in the subsequent offer, if = any. This would avoid complicating and expanding the initial offer - = after all, the latent configuration might never be used. The tradeoff, = of course, is that it might turn out that the two parties cannot support = a compatible set of attributes. It was decided to examine both options = and make a decision after that. The latent configuration may require the = transport parameter(s). One question (which arose before): if we do = include attributes within the lcfg: attribute, one of those is quite = likely to be a crypto: attribute, so what do we do with the key = material? 6) Attributes in "capar" The team discussed Thomas Stach's email with respect to attributes = permitted (or forbidden) within capar: attribute lines. Thomas agreed to = investigate further to help us understand the uses of the attributes he = identified. He noted that some may be obsolete; he will try to look at = the most useful first. The meeting concluded with Bob and Roni promising to continue work on = the version 2 document in order to send it to the list before the next = meeting. Thanks (and thanks to Bob for help with taking notes) -- Flemming=20 ------_=_NextPart_001_01C754E5.EBFFB5C7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I am answering myself. The reason = for specifying in cmed line is because the order of codecs in the m-line may = change by an intermediary that does not support the capability = negotiation.

Roni

 

From: Even, Roni [mailto:roni.even@polycom.co.il]
Sent: Tuesday, February = 20, 2007 11:00 AM
To: Flemming Andreasen; = mmusic
Subject: RE: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design teamconference = call

 

Hi,

 Item number 2 about = explicitly numbering of media capabilities.

There are two ways to do it. The = first it to specify the subtypes in the cmed line. The second is to use a media = level mcap attribute that will assign a number to the subtypes in the m line. = The current version use the second option.

 

Roni

 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Tuesday, February = 13, 2007 4:44 PM
To: mmusic
Subject: [MMUSIC] SDP = Capability Negotation: Minutes of 2/6/07 design team conference = call

 

Greetings

The SDP Capability Negotiation Design team had a conference call on = 2/6/07. The attendees were:

    Bob Gilman
    Matt Lepinski
    Roni Even
    Flemming Andreasen
    Thomas Stach
    Colin Perkins
    Joerg Ott

The call centered on the new media capabilities document, which Roni and = Bob have been working on. The issues discussed were:

1) Relationship to RFC 3407
The core capability negotiation document and the media capabilities = document provide everything that RFC 3407 does (and then some). In lieu of this, = the team discussed whether these two documents should obsolete RFC 3407 or = not. The intent is for this work to replace RFC 3407 going forward, however it is possible that interworking with RFC 3407 may still be required.

2) Numbering of media capabilites (codecs)
Discussion around whether we need to explicitly definie media types in = the "m=3D" line. This is similar to the discussion we had around = transport capabilities and the conclusion is the same: we will require them to be specified explicitly, even though they are already part of the = "m=3D" line.

3) Discussion around how we specify the same codecs with different = parameters
Currently will have multiple instances in cmed line. Alternatives = include:
- Changing pcfg attribute to specify potential configurations = differently.
- Another level of indirection in the cmed line allowing for composite capabilities to be built (and referenced in the pcfg attribute). . =

The authors will look further into this.

 
4) Discussion around what goes in answers.

The m=3D line = in the answer needs to be in accordance with the accepted configuration (the way it's = done currently). The "acfg" attribute in the core should be changed = to just reference the pcfg attribute from the offer (as opposed to spell it = out).

5) Latent configuration attribute
Further work is needed on this - the authors are currently debating = format and contents.
It was suggested that the lcfg: attribute need not include all the = attributes of a typical pcfg: line; it might be enough to announce the capability = to do video, for example, without specifying all the details. The details = would, of course, be carried in the subsequent offer, if any. This would avoid complicating and expanding the initial offer - after all, the latent configuration might never be used. The tradeoff, of course, is that it = might turn out that the two parties cannot support a compatible set of = attributes. It was decided to examine both options and make a decision after that. The = latent configuration may require the transport parameter(s). One question = (which arose before): if we do include attributes within the lcfg: attribute, one of = those is quite likely to be a crypto: attribute, so what do we do with the key material?

6) Attributes in "capar"
The team discussed Thomas Stach's email with respect to attributes = permitted (or forbidden) within capar: attribute lines. Thomas agreed to = investigate further to help us understand the uses of the attributes he identified. = He noted that some may be obsolete; he will try to look at the most useful = first.


The meeting concluded with Bob and Roni promising to continue work on = the version 2 document in order to send it to the list before the next = meeting.

Thanks (and thanks to Bob for help with taking notes)

-- Flemming




------_=_NextPart_001_01C754E5.EBFFB5C7-- --===============1062222651== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1062222651==-- From mmusic-bounces@ietf.org Tue Feb 20 15:51:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbxW-0007O9-D5; Tue, 20 Feb 2007 15:51:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbx1-0006F0-Tl; Tue, 20 Feb 2007 15:51:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJbx1-00037A-I9; Tue, 20 Feb 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 868012ACA6; Tue, 20 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJbw3-0007QX-8B; Tue, 20 Feb 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Feb 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart 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 : SDP Capability Negotiation Author(s) : F. Andreasen Filename : draft-ietf-mmusic-sdp-capability-negotiation-03.txt Pages : 48 Date : 2007-2-20 The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback. The purpose of this document is to address that and other real-life limitations by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The solution provided in this document provides a general SDP capability negotiation framework. It also defines specifically how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g. media types and formats) may be provided in other documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-capability-negotiation-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-20133951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-capability-negotiation-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-20133951.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Wed Feb 21 08:12:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJrG0-0003yQ-C6; Wed, 21 Feb 2007 08:11:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJrFy-0003ss-W4 for mmusic@ietf.org; Wed, 21 Feb 2007 08:11:39 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJrFv-0004FR-PA for mmusic@ietf.org; Wed, 21 Feb 2007 08:11:38 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JDT00K39DYWZ6@siemenscomms.co.uk> for mmusic@ietf.org; Wed, 21 Feb 2007 13:11:20 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Feb 2007 13:11:20 +0000 Content-return: allowed Date: Wed, 21 Feb 2007 13:11:20 +0000 From: "Elwell, John" To: Flemming Andreasen , mmusic@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B1A27CF@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e831a3b581a967a651997b2cbc2bae7 Cc: Francois Audet Subject: [MMUSIC] RE: SDP Capability Negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1487115288==" Errors-To: mmusic-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1487115288== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_e/IZZ8BoTFwZ3iZwtTD2RQ)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_e/IZZ8BoTFwZ3iZwtTD2RQ) Content-type: text/plain Content-transfer-encoding: 7BIT Flemming, Given the requirement for a general purpose capability negotiation framework, then this seems a reasonable solution. I still maintain it is overkill for best effort SRTP negotiation, but I am prepared to support it if we can get it moving forward very quickly. If we can't achieve consensus at the Prague meeting that it is ready for WGLC, I would wish to reconsider Hadriel's alternative. Some comments on 03: 1. Section 1, 2nd bullet "A set of potential configurations indicating which of those capabilities can be used for the session" - Can we include the word "combination", e.g. "A set of potential configurations indicating which combinations of those capabilities can be used for the session" 2. Section 1, 3rd bullet. Does it really provide "A set of actual configurations"? I thought it just provided a single actual configuration, selected from the set of potential configurations. 3. Section 3.1 "Two new attributes to support versioning and extensions ..." Now that the version attribute has gone, should we remove "versioning"? 4. Section 3.1 - there is no point in listing the supported or required base - this can be implied simply by the presence of a=csup / a=creq. 5. Section 3.1, "A new attribute ("a=acap") that defines how to list attribute parameter values.." In fact it contains complete attributes or attribute values, not attribute parameter values. 6. Section 3.1 "A new attribute ("a=acfg") to be used in an answer SDP. The attribute identifies which of the potential configurations from an offer were used as actual configurations..." Should it be "was used as the actual configuration"? Surely you can select only one. 7. Section 3.1 "Potential configurations are always preferred over actual configurations..." I find this confusing, because the example offer to which it refers does not have an a=acfg attribute. We should use a different term to express what is indicated by the "regular" transport and attributes. In fact in lots of places in the document I think the term "actual configuration" is used with different meanings. 8. Section 3.2.1. I don't see the need for the cap-v0 option tag - isn't it implied by the presence of a=csup/creq? What is the meaning of receiving a=csup/creq without the cap-v0 option tag? 9. Section 3.2.2 - the first paragraph could be replaced by a reference to 3.2.1 for the meaning of option tags. 10. Section 3.4.2 states "The actual configuration attribute identifies which of the potential configurations from an offer SDP were used as actual configurations..." Again this seems to suggest multiple actual configurations, but the meaning of this is not given. As I understand it, there are multiple capabilities in an actual configuration, but only one actual configuration. 11. Section 3.5.2 says that attributes from a potential configuration are added to the regular attributes. This could result in two attributes of the same type, e.g., two a=crypto lines. What happens in this case? 12. Section 3.5.2, last paragraph. Again I have trouble with the term actual configuration. It is not clear whether this refers to the regular configuration in the offer or in the answer (the latter corresponding to the actual configuration indicated by the a=acfg line). 13. In the same paragraph there seems to be a contradiction. The MUST NOT sentence seems to be contradicted by the subsequent MAY sentence. Again I think this is because of ambiguity in the term "actual configuration". I think what it is trying to say is that you MUST NOT send media in accordance with the m-line in the offer if you have selected a potential configuration, but instead you MAY send media in accordance with the a=acfg line in the answer. 14. Do we need to make any statements about asymmetrical (direction-sensitive) attributes? I am thinking here of things like a=sendonly and a=rcvonly. If you have an a=acap:1 a=sendonly line, and this is used by a potential configuration that gets selected as the actual configuration by the answerer, then if the answerer promotes the sendonly attribute to a regular a=sendonly line in the answer, then this is clearly wrong (but a=rcvonly would be correct). I don't have any practical use cases for using this, so perhaps we just need to exclude this type of attribute from use in a=acap lines. 15. There are some very long sections in the draft. Is it not possible to break some of them up into sub-sections so that specific aspects can be referenced more easily? John _____ From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: 20 February 2007 20:59 To: Elwell, John Cc: Francois Audet; Hadriel Kaplan; Flemming Andreasen Subject: SDP Capability Negotiation [Was Re: test (Nortel filter problem)] Elwell, John wrote: Yes, I share Francois' concerns. I appreciate the efforts the design team has put in over the last few weeks to simplify the solution compared with the earlier proposal. If we had nothing at all, I guess the current proposal would be reasonable. But given the variety of existing implementations of best effort SRTP, it is hard to see how quickly the MMUSIC solution will gain traction in the market. That's fine - there's nothing the IETF can do about that. What I'm looking for at this stage is feedback of the form "yes, this looks like a decent solution, and legacy pre-standard deployment issues aside, this is the path we should try and head down", or "no, this is terrible, there is no way in h... I'm ever going to look at this useless piece of s... again". More constructive comments somewhere in between those two will of course be welcome as well :-). Basically, the goal here is to get as close as possible to WG consensus before Prague, and since you are all significant stakeholders, I'm looking for any feedback you may have at this point that will bring us closer to that goal. -- Flemming John _____ From: Francois Audet [mailto:audet@nortel.com ] Sent: 20 February 2007 18:06 To: Flemming Andreasen Cc: Hadriel Kaplan; Elwell, John Subject: RE: test (Nortel filter problem) Our spam filter is completely useless. It filters more good emails than bad ones. Can you send the email that keeps getting bounced to filtops@nortel.com ? Along with a description of the problem, i.e., that you need to send it to me and that it keeps getting bounced? I'll take a look at the two documents again. Here is my main question: * What timing do we expect for publication as an RFC? I'm ok with the content, I guess, although I'm a bit worried about complexity. I am also very worried about how to handle the plethora of "pre-standard" implemenatations of best-effort security out there. And since the timing for the "standard" solution is very bad, it will get worst. I do not think that we can hide our heads in the sand. I believe the following mechnanisms are out there and have to be reckoned with: * Multiple c lines, one with AVP the other with SAVP * with port overloading * without port overloading * Use of crypto/kmgmt without SAVP profile * return of crypto/kmgmt in Answer means SRTP * Sometimes based on a=encryption:optional tag _____ From: Flemming Andreasen [mailto:fandreas@cisco.com ] Sent: Tuesday, February 20, 2007 09:14 To: Audet, Francois (SC100:3055) Subject: Re: test (Nortel filter problem) well that surely is weird - I'm trying to send you another e-mail which the Nortel mail filters keep bouncing. Let me try and cut and paste here without including any URLs: Hi Francois and Hadriel We've been doing a bunch of work on the SDP Capability Negotiation stuff since the last IETF, and I believe we are at a point where the core document is fairly solid (still need to add a few more examples). The goal is to try and get consensus around the document in Prague and then move to WGLC after that. To facitilitate that, it would be very helpful if both of you can review the current document (preferably before Sunday 2/25/07) and let us know if you have any major (or minor) issues with it. Please send any comments you may have to the MMUSIC list. Thanks. -- Flemming PS: Latest document can be obtained from Francois Audet wrote: Yep. -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com ] Sent: Tuesday, February 20, 2007 08:00 To: Audet, Francois (SC100:3055) Subject: test (Nortel filter problem) let me know if you got this -- Flemming --Boundary_(ID_e/IZZ8BoTFwZ3iZwtTD2RQ) Content-type: text/html Content-transfer-encoding: 7BIT
Flemming,
 
Given the requirement for a general purpose capability negotiation framework, then this seems a reasonable solution. I still maintain it is overkill for best effort SRTP negotiation, but I am prepared to support it if we can get it moving forward very quickly. If we can't achieve consensus at the Prague meeting that it is ready for WGLC, I would wish to reconsider Hadriel's alternative.
 
Some comments on 03:
 
1. Section 1, 2nd bullet "A set of potential configurations indicating which of those capabilities can be used for the session" - Can we include the word "combination", e.g. "A set of potential configurations indicating which combinations of those capabilities can be used for the session"
 
2. Section 1, 3rd bullet. Does it really provide "A set of actual configurations"? I thought it just provided a single actual configuration, selected from the set of potential configurations.
 
3. Section 3.1 "Two new attributes to support versioning and extensions ..." Now that the version attribute has gone, should we remove "versioning"?
 
4. Section 3.1 - there is no point in listing the supported or required base - this can be implied simply by the presence of a=csup / a=creq.
 
5. Section 3.1, "A new attribute ("a=acap") that defines how to list attribute parameter values.." In fact it contains complete attributes or attribute values, not attribute parameter values.
 
6. Section 3.1 "A new attribute ("a=acfg") to be used in an answer SDP. The attribute identifies which of the potential configurations from an offer were used as actual configurations..." Should it be "was used as the actual configuration"? Surely you can select only one.
 
7. Section 3.1 "Potential configurations are always preferred over actual configurations..." I find this confusing, because the example offer to which it refers does not have an a=acfg attribute. We should use a different term to express what is indicated by the "regular" transport and attributes. In fact in lots of places in the document I think the term "actual configuration" is used with different meanings.
 
8. Section 3.2.1. I don't see the need for the cap-v0 option tag - isn't it implied by the presence of a=csup/creq? What is the meaning of receiving a=csup/creq without the cap-v0 option tag?
 
9. Section 3.2.2 - the first paragraph could be replaced by a reference to 3.2.1 for the meaning of option tags.
 
10. Section 3.4.2 states "The actual configuration attribute identifies which of the potential  configurations from an offer SDP were used as actual configurations..." Again this seems to suggest multiple actual configurations, but the meaning of this is not given. As I understand it, there are multiple capabilities in an actual configuration, but only one actual configuration.
 
11. Section 3.5.2 says that attributes from a potential configuration are added to the regular attributes. This could result in two attributes of the same type, e.g., two a=crypto lines. What happens in this case?
 
12. Section 3.5.2, last paragraph. Again I have trouble with the term actual configuration. It is not clear whether this refers to the regular configuration in the offer or in the answer (the latter corresponding to the actual configuration indicated by the a=acfg line).
 
13. In the same paragraph there seems to be a contradiction. The MUST NOT sentence seems to be contradicted by the subsequent MAY sentence. Again I think this is because of ambiguity in the term "actual configuration". I think what it is trying to say is that you MUST NOT send media in accordance with the m-line in the offer if you have selected a potential configuration, but instead you MAY send media in accordance with the a=acfg line in the answer.
 
14. Do we need to make any statements about asymmetrical (direction-sensitive) attributes? I am thinking here of things like a=sendonly and a=rcvonly. If you have an a=acap:1 a=sendonly line, and this is used by a potential configuration that gets selected as the actual configuration by the answerer, then if the answerer promotes the sendonly attribute to a regular a=sendonly line in the answer, then this is clearly wrong (but a=rcvonly would be correct). I don't have any practical use cases for using this, so perhaps we just need to exclude this type of attribute from use in a=acap lines.
 
15. There are some very long sections in the draft. Is it not possible to break some of them up into sub-sections so that specific aspects can be referenced more easily?
 
John
 
 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: 20 February 2007 20:59
To: Elwell, John 
Cc: Francois Audet; Hadriel Kaplan; Flemming Andreasen
Subject: SDP Capability Negotiation [Was Re: test (Nortel filter problem)]



Elwell, John wrote:
Yes, I share Francois' concerns. I appreciate the efforts the design team has put in over the last few weeks to simplify the solution compared with the earlier proposal. If we had nothing at all, I guess the current proposal would be reasonable. But given the variety of existing implementations of best effort SRTP, it is hard to see how quickly the MMUSIC solution will gain traction in the market.
That's fine - there's nothing the IETF can do about that. What I'm looking for at this stage is feedback of the form "yes, this looks like a decent solution, and legacy pre-standard deployment issues aside, this is the path we should try and head down", or "no, this is terrible, there is no way in h... I'm ever going to look at this useless piece of s... again". More constructive comments somewhere in between those two will of course be welcome as well :-). Basically, the goal here is to get as close as possible to WG consensus before Prague, and since you are all significant stakeholders, I'm looking for any feedback you may have at this point that will bring us closer to that goal.

-- Flemming

 
John

From: Francois Audet [mailto:audet@nortel.com]
Sent: 20 February 2007 18:06
To: Flemming Andreasen
Cc: Hadriel Kaplan; Elwell, John
Subject: RE: test (Nortel filter problem)

Our spam filter is completely useless. It filters more good emails than bad ones.
 
Can you send the email that keeps getting bounced to filtops@nortel.com?
Along with a description of the problem, i.e., that you need to send it to me and that it keeps getting bounced?
 
I'll take a look at the two documents again.
 
Here is my main question:
  • What timing do we expect for publication as an RFC?
I'm ok with the content, I guess, although I'm a bit worried about complexity.
 
I am also very worried about how to handle the plethora of "pre-standard" implemenatations of best-effort security out there. And since the timing for the "standard" solution is very bad, it will get worst. I do not think that we can hide our heads in the sand. I believe the following mechnanisms are out there and have to be reckoned with:
  • Multiple c lines, one with AVP the other with SAVP
    • with port overloading
    • without port overloading
  • Use of crypto/kmgmt without SAVP profile
    • return of crypto/kmgmt in Answer means SRTP
    • Sometimes based on a=encryption:optional tag
 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Tuesday, February 20, 2007 09:14
To: Audet, Francois (SC100:3055)
Subject: Re: test (Nortel filter problem)

well that surely is weird - I'm trying to send you another e-mail which the Nortel mail filters keep bouncing. Let me try and cut and paste here without including any URLs:

Hi Francois and Hadriel

We've been doing a bunch of work on the SDP Capability Negotiation stuff since the last IETF, and I believe we are at a point where the core document is fairly solid (still need to add a few more examples). The goal is to try and get consensus around the document in Prague and then move to WGLC after that. To facitilitate that, it would be very helpful if both of you can review the current document (preferably before Sunday 2/25/07) and let us know if you have any major (or minor) issues with it. Please send any comments you may have to the MMUSIC list.

Thanks.

-- Flemming

PS: Latest document can be obtained from <see e-mail on MMUSIC list>


Francois Audet wrote: 
Yep. 

  
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: Tuesday, February 20, 2007 08:00
To: Audet, Francois (SC100:3055)
Subject: test (Nortel filter problem)

let me know if you got this

-- Flemming
--Boundary_(ID_e/IZZ8BoTFwZ3iZwtTD2RQ)-- --===============1487115288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1487115288==-- From mmusic-bounces@ietf.org Wed Feb 21 09:04:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJs55-000799-32; Wed, 21 Feb 2007 09:04:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJs53-000794-KV for mmusic@ietf.org; Wed, 21 Feb 2007 09:04:25 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJs52-0008Du-9Q for mmusic@ietf.org; Wed, 21 Feb 2007 09:04:25 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:55204) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HJs51-0004Jm-Te for mmusic@ietf.org; Wed, 21 Feb 2007 14:04:23 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Wed, 21 Feb 2007 14:04:22 +0000 To: mmusic WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [MMUSIC] Fwd: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org A reminder that the internet-draft submission deadlines for the Prague IETF meeting are rapidly approaching. Colin Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: 16 February 2007 05:00:01 GMT > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF > Meeting in Prague, Czech Republic > > > There are two (2) Internet-Draft cutoff dates for the 68th > IETF Meeting in Prague, Czech Republic: > > February 26th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > February 26th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > February 19th at 9:00 AM ET. > > March 5th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, March 5th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, March 19th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 68th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_68.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 21 10:51:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtjw-0007Ue-NQ; Wed, 21 Feb 2007 10:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtjL-0006HN-Go; Wed, 21 Feb 2007 10:50:07 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtjG-0004fy-Sv; Wed, 21 Feb 2007 10:50:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9A4B426EDE; Wed, 21 Feb 2007 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJtjG-0008Sy-4p; Wed, 21 Feb 2007 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Feb 2007 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart 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 : SDP media capabilities Negotiation Author(s) : F. Andreasen, et al. Filename : draft-ietf-mmusic-sdp-media-capabilities-01.txt Pages : 22 Date : 2007-2-21 Session Description Protocol (SDP) capability negotiation provides a general framework for negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-media-capabilities-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-21084738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-media-capabilities-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-21084738.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Wed Feb 21 11:15:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJu7Y-0004Um-Ki; Wed, 21 Feb 2007 11:15:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJu7X-0004Ud-IP for mmusic@ietf.org; Wed, 21 Feb 2007 11:15:07 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJu7I-0003hA-1k for mmusic@ietf.org; Wed, 21 Feb 2007 11:15:07 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1LGEnJs004842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Feb 2007 08:14:49 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1LGEmgc014688; Wed, 21 Feb 2007 08:14:48 -0800 Received: from NAEX01.qualcomm.com ([129.46.51.61]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 08:14:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Draft on SDP BW attribute for media bitrate in 'send' direction ( draft-hdesinen-mmusic-oa-send-bw-attr-00.txt ) Date: Wed, 21 Feb 2007 08:14:46 -0800 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B0297C7DE@NAEX01.na.qualcomm.com> In-Reply-To: <6345BEB5-1C1D-4B99-9662-8E75C3CA87EC@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Draft on SDP BW attribute for media bitrate in 'send' direction ( draft-hdesinen-mmusic-oa-send-bw-attr-00.txt ) Thread-Index: AcdV0agnPDYT93F4QcWvIsYKeg/4CQAAWouA References: <2CA3E1B6CEC064449CAA7D0FAB46079B028B0ACC@NAEX01.na.qualcomm.com> <6345BEB5-1C1D-4B99-9662-8E75C3CA87EC@csperkins.org> From: "Desineni, Harikishan" To: "Colin Perkins" X-OriginalArrivalTime: 21 Feb 2007 16:14:48.0547 (UTC) FILETIME=[68A54330:01C755D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Colin, Thanks for the review. I agree with your comments. I'll make the suggested changes in the next version of the draft. Thanks, Hari > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Wednesday, February 21, 2007 8:02 AM > To: Desineni, Harikishan > Cc: mmusic WG > Subject: Re: [MMUSIC] Draft on SDP BW attribute for media bitrate in > 'send' direction ( draft-hdesinen-mmusic-oa-send-bw-attr-00.txt ) >=20 > > Please review the latest version (-01) of the draft and post your > > comments. >=20 > The terminology in Section 5 is misleading and incorrect, and should > be changed. This is not an SDP attribute ("a=3D" line), but rather a > Bandwidth Specifier (for the "b=3D" line). Please update the draft to > use the correct terminology. >=20 > Also, RFC 4566, notes that "although no length limit is given, it is > recommended that they be short" when discussing bandwidth specifier > names. Following this, and existing practice, it might be better to > name this "MSR" rather than "maxsendrate"? >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 21 11:16:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJu8Z-0004lj-DA; Wed, 21 Feb 2007 11:16:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJu8Y-0004lc-Ka for mmusic@ietf.org; Wed, 21 Feb 2007 11:16:10 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJu8S-00044Y-BP for mmusic@ietf.org; Wed, 21 Feb 2007 11:16:10 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HJu8P-0001QV-4L; Wed, 21 Feb 2007 11:16:01 -0500 Message-ID: <45DC7040.2050907@bbn.com> Date: Wed, 21 Feb 2007 11:16:00 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) References: <45DA6434.2060708@cisco.com> <680E6487-7D2A-4E50-98D9-33DA960EE51D@csperkins.org> In-Reply-To: <680E6487-7D2A-4E50-98D9-33DA960EE51D@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Flemming Andreasen , mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I appreciate Colin's desire for conceptual simplicity, and as long as we're only talking about media-level attributes, I agree with Colin's proposed change. However, I don't see a good way to integrate Colin's change with the semantics of session-level attributes. Perhaps someone can propose a good way for "attribute replacement" to work at the session level? However, in the absence of such a proposal, my preference is for keeping the document as it is. To help clarify the point in question, let me provide a couple of examples to clarify the point in question. (I'm the kind of person who has trouble thinking clearly without examples). Here is an offer for "Best-Effort SRTP" as the document is currently written: v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 1 a=creq: cap_v0 m=audio 3456 RTP/AVP 18 a=fmt:18 annexb:no a=tcap:1 RTP/SAVP RTP/AVP a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:AAA... a=pcfg:1 t=1 a=1 Notice that if the potential configuration (using SAVP) is chosen then the crypto attribute is "added" to the set of media stream attributes. (That is, the a=fmt attribute remains regardless of which configuration is chosen). Colin has proposed that attributes in potential configurations "replace" the existing media stream attributes. Therefore, one would re-write the above example as follows: v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 2 a=creq: cap_v0 m=audio 3456 RTP/AVP 18 a=fmt:18 annexb:no a=tcap:1 RTP/SAVP RTP/AVP a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:AAA... a=acap:2 a=fmt:18 annexb:no a=pcfg:1 t=1 a=1,2 In this particular case, the first SDP offer is perhaps a bit simpler than the second SDP offer. However, I would agree with Colin that in cases repeating session-level attributes adds only a small amount of overhead. Now consider an example where the offerer perfers unencrypted media, but is willing to encrypt if the answerer requires media privacy. v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 3 a=creq: cap_v0 m=audio 3456 RTP/SAVP 18 a=fmt:18 annexb:no a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:AAA... a=tcap:1 RTP/AVP RTP/SAVP a=pcfg:1 t=1 In this case, if the answerer accepts the potential configuration, the answerer must deal with the fact that there is a "meaningless" a=crypto attribute being offered for an AVP media stream. Certainly, this is something that implementations can deal with, but I agree with Colin that the following offer is more clear: v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 4 a=creq: cap_v0 m=audio 3456 RTP/SAVP 18 a=fmt:18 annexb:no a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:AAA... a=tcap:1 RTP/AVP RTP/SAVP a=acap:1 a=fmt:18 annexb:no a=pcfg:1 t=1, a=1 This brings us to session attributes. Following the "additive" paradaigm, each media-level potential configuration is able to "add" potential attributes at the session-level as well as the media level. That is, in the following example: v=0 o=jdoe 12345 67890 IN IP4 10.0.0.1 c=IN IP4 10.0.0.2 t=0 0 s=Example 5 a=creq: cap_v0 a=recvonly a=acap:1 a=key-mgmt:mikey ABAC... m=audio 3456 RTP/AVP 18 a=tcap:1 RTP/SAVP RTP/AVP a=pcfg:1 t=1, a=1 The a=recvonly attribute is always active and the a=key-mgmt attribute only if the potential configuration is selected. First, I find it unappealing to have potential configurations "add" attributes at the session level and "replace" attributes at the media-level. (I think this loses any conceptual simplicity that would be gained by "replacement" at the media-level.). Second, I'm not sure how define a clear semantics for "replacement" at the session-level. That is, let's say I select a potential configuration for media stream #1, and the "standard" configuration for media stream #2. Does selecting a potential configuration for media stream 1 replace (eliminate) the existing session level attributes? If so, are there cases where this would have bad interactions with media stream #2, whose "standard" configuration may be expecting the presence of certain session-level attributes? Just my two cents, - Matt Lepinski :-> Colin Perkins wrote: > Flemming, > > On 20 Feb 2007, at 03:00, Flemming Andreasen wrote: > >> I have just submitted an updated solution document as draft-ietf- >> mmusic-sdp-capability-negotiation-03.txt, which you can retrieve >> from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp- >> capability-negotiation-03.txt until it appears in the archives. >> >> The list of changes (from Section 9.1): >> o Base option tag name changed from "v0" to "cap-v0". >> o Added new section on extension capability attributes >> o Firmed up offer/answer procedures. >> o Added security considerations >> o Added IANA considerations > > > This is looking good, especially with the clarifications to the offer/ > answer procedures. > > I would like to highlight one design choice on the list: when > attributes are included in "a=acap:" lines of a potential > configuration, those attributes are added to the set in the actual > configuration during the offer/answer exchange. This may sometimes > result in meaningless attributes, as is noted in Section 3.5.2 (half > way down page 25). An alternative is for the attributes in the > "a=acap:" lines of a potential configuration to replace those in the > actual configuration if that potential configuration is accepted. > This removes the potential for meaningless attributes, and makes > negotiation simpler, at the cost of needing to duplicate attributes > that are common to the actual and potential configurations. > > I'd like to hear opinions on this choice. I have a slight preference > for changing the draft so attributes in potential configurations > replace those in the actual during the negotiation phase, since that > seems conceptually simpler. I'm curious whether people believe it > would introduce too much overhead though. Comments? > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 21 12:47:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvYZ-0004GV-Hv; Wed, 21 Feb 2007 12:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtuw-0004xZ-E9; Wed, 21 Feb 2007 11:02:07 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtus-0008LZ-JB; Wed, 21 Feb 2007 11:02:06 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:55362) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HJtur-0005Wd-1s; Wed, 21 Feb 2007 16:02:01 +0000 In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B028B0ACC@NAEX01.na.qualcomm.com> References: <2CA3E1B6CEC064449CAA7D0FAB46079B028B0ACC@NAEX01.na.qualcomm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6345BEB5-1C1D-4B99-9662-8E75C3CA87EC@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Draft on SDP BW attribute for media bitrate in 'send' direction ( draft-hdesinen-mmusic-oa-send-bw-attr-00.txt ) Date: Wed, 21 Feb 2007 16:01:59 +0000 To: "Desineni, Harikishan" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 16 Feb 2007, at 07:41, Desineni, Harikishan wrote: > AVT & MMUSIC, I've bcc'd the AVT list on this message. Future discussion on the MMUSIC list, please. > Here is a draft which defines a new bandwidth attribute for SDP > Offer/Answer model. > > ======= > Abstract: > "This document defines a new SDP bandwidth attribute that can be > used to > signal the maximum media bitrate in 'send' direction of a stream in > SDP > offer/answer model." > ========= > > -01 version of the draft is not yet available on IETF server. Until > then > it can be viewed at > http://people.qualcomm.com/hdesinen/draft-hdesinen-mmusic-oa-send- > bw-att > r-01.txt > > -00 is available on IETF server at > http://www.ietf.org/internet-drafts/draft-hdesinen-mmusic-oa-send- > bw-att > r-00.txt > > Please review the latest version (-01) of the draft and post your > comments. The terminology in Section 5 is misleading and incorrect, and should be changed. This is not an SDP attribute ("a=" line), but rather a Bandwidth Specifier (for the "b=" line). Please update the draft to use the correct terminology. Also, RFC 4566, notes that "although no length limit is given, it is recommended that they be short" when discussing bandwidth specifier names. Following this, and existing practice, it might be better to name this "MSR" rather than "maxsendrate"? -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Feb 22 02:46:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK8dy-0003RM-6Z; Thu, 22 Feb 2007 02:45:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK8dx-0003QH-35 for mmusic@ietf.org; Thu, 22 Feb 2007 02:45:33 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK8dq-0000Zu-F7 for mmusic@ietf.org; Thu, 22 Feb 2007 02:45:33 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1B5B200DB; Thu, 22 Feb 2007 08:45:15 +0100 (CET) X-AuditID: c1b4fb3e-b06d4bb0000007e1-57-45dd4a0bd1a4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9AE962005D; Thu, 22 Feb 2007 08:45:15 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 08:45:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) Date: Thu, 22 Feb 2007 08:45:14 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05047883DC@esealmw109.eemea.ericsson.se> In-Reply-To: <45DA6434.2060708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) Thread-Index: AcdUm9b9MhA30pJCSZGgHUJ5pbwXiABtjVIg From: "Ingemar Johansson S \(LU/EAB\)" To: "Flemming Andreasen" , "mmusic" X-OriginalArrivalTime: 22 Feb 2007 07:45:15.0532 (UTC) FILETIME=[641F24C0:01C75655] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi If I understand things correctly (snippet below from section 3.5.3), there will be two offer/answers during call setup. The second offer/answer in order to ensure that "intermediaries" understand. This might have some issues regarding call setup times e.g in wireless access where service radio bearers might have a limited bitrate, currently I cannot tell much this might mean in extra call setup time. One possible solution is that it may be possible that the call could be setup already after the first offer/answer ?, this probably assumes that possible radio resource management understands the first offer/answer. Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20 If the offer/answer exchange was succesful, and if the answerer=20 selected one of the potential configurations from the offer as the=20 actual configuration, then the offerer SHOULD perform another=20 offer/answer exchange: The new offer should contain the selected=20 potential configuration as the actual configuration, i.e. with the=20 actual configuration used in the "m=3D" line and any other relevant=20 attributes. This second offer/answer exchange will not modify the=20 session in any way, however it will help intermediaries that look at=20 the SDP, but do not understand or support the capability negotiation=20 extensions, to understand the details of the media stream(s) that=20 were actually negotiated. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20 > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 > Sent: den 20 februari 2007 04:00 > To: mmusic > Subject: [MMUSIC] SDP Capability Negotiation: Updated=20 > solution document (-03) >=20 > Greetings >=20 > I have just submitted an updated solution document as=20 > draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which=20 > you can retrieve from=20 > http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa > bility-negotiation-03.txt > until it appears in the archives. >=20 > The list of changes (from Section 9.1): > o Base option tag name changed from "v0" to "cap-v0". > o Added new section on extension capability attributes o=20 > Firmed up offer/answer procedures. > o Added security considerations > o Added IANA considerations >=20 >=20 > Thanks >=20 > -- Flemming >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Feb 22 07:10:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKClL-00037P-Sn; Thu, 22 Feb 2007 07:09:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKClJ-000362-Q2 for mmusic@ietf.org; Thu, 22 Feb 2007 07:09:25 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKClI-0001ff-37 for mmusic@ietf.org; Thu, 22 Feb 2007 07:09:25 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 22 Feb 2007 04:09:24 -0800 X-IronPort-AV: i="4.14,205,1170662400"; d="scan'208,217"; a="392095481:sNHT90729756" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1MC9N4S031705; Thu, 22 Feb 2007 04:09:23 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1MC9Nho009789; Thu, 22 Feb 2007 04:09:23 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 04:09:23 -0800 Received: from [10.21.154.28] ([10.21.154.28]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 04:09:20 -0800 Message-ID: <45DD87EB.1000605@cisco.com> Date: Thu, 22 Feb 2007 07:09:15 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Ingemar Johansson S (LU/EAB)" Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) References: <026F8EEDAD2C4342A993203088C1FC05047883DC@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05047883DC@esealmw109.eemea.ericsson.se> X-OriginalArrivalTime: 22 Feb 2007 12:09:22.0553 (UTC) FILETIME=[49AEA690:01C7567A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7325; t=1172146163; x=1173010163; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Update d=20solution=20document=0A=20(-03) |Sender:=20; bh=QbbLnQP4OxgD4tsEGePt/fPArvni0YtP+dD3jvlNdYk=; b=zDX+QWkWxgpVLZsc3KXIjCIOsHU3o2mHoP5VhhNAjL31rNqjTzO6eHeqFVaE+yQkjMWeR3Hj 3uLl30jLVLgtKn+XpmWnZSbqeRMXyOxC6HXhb+EaGKO/XwzEC/XZf5yw; Authentication-Results: sj-dkim-5; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2076100170==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============2076100170== Content-Type: multipart/alternative; boundary="------------070306070506040806090503" This is a multi-part message in MIME format. --------------070306070506040806090503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ingemar Johansson S (LU/EAB) wrote: > Hi > > If I understand things correctly (snippet below from section 3.5.3), > there will be two offer/answers during call setup. The second > offer/answer in order to ensure that "intermediaries" understand. This > might have some issues regarding call setup times e.g in wireless access > where service radio bearers might have a limited bitrate, currently I > cannot tell much this might mean in extra call setup time. > > One possible solution is that it may be possible that the call could be > setup already after the first offer/answer ?, this probably assumes that > possible radio resource management understands the first offer/answer. > That's correct. As far as the offerer and the answerer is concerned, all media stream negotiation is complete after the first exchange. The second exchange is merely done as a courtesy to any intermediaries that may not understand what was actually going on. If those intermediaries do understand it (and have a need to a know in the first place), then the second exchange is effectively a no-op for all parties. -- Flemming > Regards > Ingemar > > ============================== > If the offer/answer exchange was succesful, and if the answerer > selected one of the potential configurations from the offer as the > actual configuration, then the offerer SHOULD perform another > offer/answer exchange: The new offer should contain the selected > potential configuration as the actual configuration, i.e. with the > actual configuration used in the "m=" line and any other relevant > attributes. This second offer/answer exchange will not modify the > session in any way, however it will help intermediaries that look at > the SDP, but do not understand or support the capability negotiation > extensions, to understand the details of the media stream(s) that > were actually negotiated. > ============================== > > >> -----Original Message----- >> From: Flemming Andreasen [mailto:fandreas@cisco.com] >> Sent: den 20 februari 2007 04:00 >> To: mmusic >> Subject: [MMUSIC] SDP Capability Negotiation: Updated >> solution document (-03) >> >> Greetings >> >> I have just submitted an updated solution document as >> draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which >> you can retrieve from >> http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa >> bility-negotiation-03.txt >> until it appears in the archives. >> >> The list of changes (from Section 9.1): >> o Base option tag name changed from "v0" to "cap-v0". >> o Added new section on extension capability attributes o >> Firmed up offer/answer procedures. >> o Added security considerations >> o Added IANA considerations >> >> >> Thanks >> >> -- Flemming >> >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> >> > > --------------070306070506040806090503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Ingemar Johansson S (LU/EAB) wrote: 
Hi

If I understand things correctly (snippet below from section 3.5.3),
there will be two offer/answers during call setup. The second
offer/answer in order to ensure that "intermediaries" understand. This
might have some issues regarding call setup times e.g in wireless access
where service radio bearers might have a limited bitrate, currently I
cannot tell much this might mean in extra call setup time.

One possible solution is that it may be possible that the call could be
setup already after the first offer/answer ?, this probably assumes that
possible radio resource management understands the first offer/answer.
That's correct. As far as the offerer and the answerer is concerned, all media stream negotiation is complete after the first exchange. The second exchange is merely done as a courtesy to any intermediaries that may not understand what was actually going on. If those intermediaries do understand it (and have a need to a know in the first place), then the second exchange is effectively a no-op for all parties.

-- Flemming 

Regards
Ingemar

============================== 
   If the offer/answer exchange was succesful, and if the answerer 
   selected one of the potential configurations from the offer as the 
   actual configuration, then the offerer SHOULD perform another 
   offer/answer exchange: The new offer should contain the selected 
   potential configuration as the actual configuration, i.e. with the 
   actual configuration used in the "m=" line and any other relevant 
   attributes. This second offer/answer exchange will not modify the 
   session in any way, however it will help intermediaries that look at 
   the SDP, but do not understand or support the capability negotiation 
   extensions, to understand the details of the media stream(s) that 
   were actually negotiated.  
============================== 

  
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: den 20 februari 2007 04:00
To: mmusic
Subject: [MMUSIC] SDP Capability Negotiation: Updated 
solution document (-03)

Greetings

I have just submitted an updated solution document as 
draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which 
you can retrieve from 
http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa
bility-negotiation-03.txt
until it appears in the archives.

The list of changes (from Section 9.1):
o Base option tag name changed from "v0" to "cap-v0".
o Added new section on extension capability attributes o 
Firmed up offer/answer procedures.
o Added security considerations
o Added IANA considerations


Thanks

-- Flemming





_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
--------------070306070506040806090503-- --===============2076100170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============2076100170==-- From mmusic-bounces@ietf.org Fri Feb 23 09:03:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKb0u-0000h9-76; Fri, 23 Feb 2007 09:03:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKb0t-0000gy-6b for mmusic@ietf.org; Fri, 23 Feb 2007 09:03:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKb0l-0004aA-8g for mmusic@ietf.org; Fri, 23 Feb 2007 09:03:07 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C6EB42098F; Fri, 23 Feb 2007 15:02:37 +0100 (CET) X-AuditID: c1b4fb3c-b0fcabb0000007de-3d-45def3fde026 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A9BFD2098A; Fri, 23 Feb 2007 15:02:37 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 15:01:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) Date: Fri, 23 Feb 2007 15:01:27 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050478920E@esealmw109.eemea.ericsson.se> In-Reply-To: <45DD87EB.1000605@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) Thread-Index: AcdWek2g7VhaSezLQLe0lREFpGiX5gA14zWA From: "Ingemar Johansson S \(LU/EAB\)" To: "Flemming Andreasen" X-OriginalArrivalTime: 23 Feb 2007 14:01:28.0103 (UTC) FILETIME=[1CD5E370:01C75753] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0955277834==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0955277834== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75753.1C7A7342" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75753.1C7A7342 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I checked out a little and _very_ rougly speaking the call setup time will be increased by ~1.0 second due to the extra offer/answer, this of course depends heaviliy on the achievable compression ratio of SigComp and the bitrate of the signaling radio bearer, the figures assume HSPA access. =20 Ingemar =20 ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: den 22 februari 2007 13:09 To: Ingemar Johansson S (LU/EAB) Cc: mmusic Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) =09 =09 Ingemar Johansson S (LU/EAB) wrote:=20 Hi =09 If I understand things correctly (snippet below from section 3.5.3), there will be two offer/answers during call setup. The second offer/answer in order to ensure that "intermediaries" understand. This might have some issues regarding call setup times e.g in wireless access where service radio bearers might have a limited bitrate, currently I cannot tell much this might mean in extra call setup time. =09 One possible solution is that it may be possible that the call could be setup already after the first offer/answer ?, this probably assumes that possible radio resource management understands the first offer/answer. =20 That's correct. As far as the offerer and the answerer is concerned, all media stream negotiation is complete after the first exchange. The second exchange is merely done as a courtesy to any intermediaries that may not understand what was actually going on. If those intermediaries do understand it (and have a need to a know in the first place), then the second exchange is effectively a no-op for all parties. =09 -- Flemming=20 =09 =09 Regards Ingemar =09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20 If the offer/answer exchange was succesful, and if the answerer=20 selected one of the potential configurations from the offer as the=20 actual configuration, then the offerer SHOULD perform another=20 offer/answer exchange: The new offer should contain the selected=20 potential configuration as the actual configuration, i.e. with the=20 actual configuration used in the "m=3D" line and any other relevant=20 attributes. This second offer/answer exchange will not modify the=20 session in any way, however it will help intermediaries that look at=20 the SDP, but do not understand or support the capability negotiation=20 extensions, to understand the details of the media stream(s) that=20 were actually negotiated. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20 =09 =20 -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: den 20 februari 2007 04:00 To: mmusic Subject: [MMUSIC] SDP Capability Negotiation: Updated=20 solution document (-03) =09 Greetings =09 I have just submitted an updated solution document as=20 =09 draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which=20 you can retrieve from=20 =09 http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa bility-negotiation-03.txt until it appears in the archives. =09 The list of changes (from Section 9.1): o Base option tag name changed from "v0" to "cap-v0". o Added new section on extension capability attributes o=20 Firmed up offer/answer procedures. o Added security considerations o Added IANA considerations =09 =09 Thanks =09 -- Flemming =09 =09 =09 =09 =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic =09 =20 =09 =20 ------_=_NextPart_001_01C75753.1C7A7342 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
I=20 checked out a little and _very_ rougly speaking the call setup time will = be=20 increased by ~1.0 second due to the extra offer/answer, this of course = depends=20 heaviliy on the achievable compression ratio of SigComp and the bitrate = of the=20 signaling radio bearer, the figures assume HSPA=20 access.
 
Ingemar
 

From: Flemming Andreasen=20 [mailto:fandreas@cisco.com]
Sent: den 22 februari 2007=20 13:09
To: Ingemar Johansson S (LU/EAB)
Cc:=20 mmusic
Subject: Re: [MMUSIC] SDP Capability Negotiation: = Updated=20 solution document (-03)



Ingemar Johansson S (LU/EAB) wrote:=20 
Hi

If I understand things correctly (snippet below from section 3.5.3),
there will be two offer/answers during call setup. The second
offer/answer in order to ensure that "intermediaries" understand. This
might have some issues regarding call setup times e.g in wireless access
where service radio bearers might have a limited bitrate, currently I
cannot tell much this might mean in extra call setup time.

One possible solution is that it may be possible that the call could be
setup already after the first offer/answer ?, this probably assumes that
possible radio resource management understands the first offer/answer.
That's correct. As far as the offerer and the = answerer is=20 concerned, all media stream negotiation is complete after the first = exchange.=20 The second exchange is merely done as a courtesy to any intermediaries = that=20 may not understand what was actually going on. If those intermediaries = do=20 understand it (and have a need to a know in the first place), then the = second=20 exchange is effectively a no-op for all parties.

-- Flemming = 

Regards
Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=20
   If the offer/answer exchange was succesful, and if the answerer=20
   selected one of the potential configurations from the offer as the=20
   actual configuration, then the offerer SHOULD perform another=20
   offer/answer exchange: The new offer should contain the selected=20
   potential configuration as the actual configuration, i.e. with the=20
   actual configuration used in the "m=3D" line and any other relevant=20
   attributes. This second offer/answer exchange will not modify the=20
   session in any way, however it will help intermediaries that look at=20
   the SDP, but do not understand or support the capability negotiation=20
   extensions, to understand the details of the media stream(s) that=20
   were actually negotiated. =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=20

  
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]=20
Sent: den 20 februari 2007 04:00
To: mmusic
Subject: [MMUSIC] SDP Capability Negotiation: Updated=20
solution document (-03)

Greetings

I have just submitted an updated solution document as=20
draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which=20
you can retrieve from=20
h=
ttp://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa
bility-negotiation-03.txt
until it appears in the archives.

The list of changes (from Section 9.1):
o Base option tag name changed from "v0" to "cap-v0".
o Added new section on extension capability attributes o=20
Firmed up offer/answer procedures.
o Added security considerations
o Added IANA considerations


Thanks

-- Flemming





_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.=
org/mailman/listinfo/mmusic
------_=_NextPart_001_01C75753.1C7A7342-- --===============0955277834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0955277834==-- From mmusic-bounces@ietf.org Fri Feb 23 09:19:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbFm-0001uL-Uo; Fri, 23 Feb 2007 09:18:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbFl-0001ty-Hm; Fri, 23 Feb 2007 09:18:29 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKbFU-0007Ji-4P; Fri, 23 Feb 2007 09:18:29 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DE6382097E; Fri, 23 Feb 2007 15:17:15 +0100 (CET) X-AuditID: c1b4fb3c-affc8bb0000007de-59-45def76b0739 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C16A820540; Fri, 23 Feb 2007 15:17:15 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 15:17:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt Date: Fri, 23 Feb 2007 15:17:14 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC0504789240@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt Thread-Index: AcdV0F2FpSdgzLaGQqG3bebdlHxt6gBg97dw From: "Ingemar Johansson S \(LU/EAB\)" To: , X-OriginalArrivalTime: 23 Feb 2007 14:17:15.0190 (UTC) FILETIME=[5157E560:01C75755] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Reading the draft I have the following simple question=20 Would it be possible, based on all the possible attributes given in=20 http://tools.ietf.org/id/draft-ietf-avt-rtp-amr-bis-06.txt to formulate an SDP offer like the one below.=20 I am not sure that it is possible to combine several cmft's in the pcfg in the f=3Dx,y,z.. way that I written below, it is possible that it is sematically incorrect, anyway comments welcome. Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = a=3Dcreq:v1 a=3Dcmed:1 AMR a=3Dcfmt:1 mode-change-capability=3D1; a=3Dcfmt:2 mode-change-capability=3D2; a=3Dcfmt:3 max-red=3D220; a=3Dcfmt:4 octet-align=3D1; a=3Dcfmt:5 mode-change-neighbor=3D1;=20 a=3Dcfmt:6 mode-change-period=3D2; a=3Dcfmt:7 mode-set=3D0,2,4,7; a=3Dcfmt:8 mode-set=3D0,3,5,6; a=3Dcenc:1 16000/1 a=3Dcenc:2 8000/1 m=3Daudio 49152 RTP/AVP 97 a=3Drtpmap:97 AMR/16000/1 a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 pcfg:1 m=3D(1 f=3D1,3,7 e=3D1 pt=3D98)|(1 f=3D1,3,8 e=3D2 pt=3D99) pcfg:2 m=3D(1 f=3D1,3,4,7 e=3D1 pt=3D98)|(1 f=3D1,3,4,8 e=3D2 pt=3D99) pcfg:3 m=3D(1 f=3D2,4,7 e=3D1 pt=3D98)|(1 f=3D2,4,8 e=3D2 pt=3D99) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: den 21 februari 2007 16:50 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D=20 > ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia=20 > Session Control Working Group of the IETF. >=20 > Title : SDP media capabilities Negotiation > Author(s) : F. Andreasen, et al. > Filename :=20 > draft-ietf-mmusic-sdp-media-capabilities-01.txt > Pages : 22 > Date : 2007-2-21 > =09 > Session Description Protocol (SDP) capability negotiation provides a > general framework for negotiating capabilities in SDP. The base > framework defines only capabilities for negotiating transport > protocols and attributes. In this document, we extend the=20 > framework > by defining media capabilities that can be used to negotiate media > types and their associated parameters. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-medi > a-capabilities-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-mmusic-sdp-media-capabilities-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Feb 23 09:31:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbS3-0006Im-8e; Fri, 23 Feb 2007 09:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbS1-00069Z-IX for mmusic@ietf.org; Fri, 23 Feb 2007 09:31:09 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKbRz-0001sh-0K for mmusic@ietf.org; Fri, 23 Feb 2007 09:31:09 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 23 Feb 2007 06:31:06 -0800 X-IronPort-AV: i="4.14,211,1170662400"; d="scan'208,217"; a="41923814:sNHT111120930" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1NEV630024775; Fri, 23 Feb 2007 06:31:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1NEV6Gk016043; Fri, 23 Feb 2007 06:31:06 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 06:31:06 -0800 Received: from [10.21.88.208] ([10.21.88.208]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 06:31:05 -0800 Message-ID: <45DEFAA7.6050604@cisco.com> Date: Fri, 23 Feb 2007 09:31:03 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Ingemar Johansson S (LU/EAB)" Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) References: <026F8EEDAD2C4342A993203088C1FC050478920E@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050478920E@esealmw109.eemea.ericsson.se> X-OriginalArrivalTime: 23 Feb 2007 14:31:05.0631 (UTC) FILETIME=[405322F0:01C75757] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10774; t=1172241066; x=1173105066; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Update d=20solution=20document=0A=20(-03) |Sender:=20; bh=FxDRKq+yj9TDVpBxsOkzUOwiuy33NjeDjcrqn2TpZdA=; b=oV65MRai8ufAD3HkgN7vXJH/wa0HxU30MW7Wt+5sVkTGDl7lh4doMAsMvpWakKg8hRTHHjBW J4gNhNSgKLZweEK+CCsqEC1lMx1+8ldZcfMzg+CKQWPslKxUCBiqw/U2; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1823195279==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1823195279== Content-Type: multipart/alternative; boundary="------------020607070301020801020200" This is a multi-part message in MIME format. --------------020607070301020801020200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ingemar Johansson S (LU/EAB) wrote: > Hi > > I checked out a little and _very_ rougly speaking the call setup time > will be increased by ~1.0 second due to the extra offer/answer, this > of course depends heaviliy on the achievable compression ratio of > SigComp and the bitrate of the signaling radio bearer, the figures > assume HSPA access. Thanks. To put that in perspective, what is the approximate call setup time without the extra offer/answer (and does it use preconditions, resource reservation, etc.) ? -- Flemming > > Ingemar > > > ------------------------------------------------------------------------ > *From:* Flemming Andreasen [mailto:fandreas@cisco.com] > *Sent:* den 22 februari 2007 13:09 > *To:* Ingemar Johansson S (LU/EAB) > *Cc:* mmusic > *Subject:* Re: [MMUSIC] SDP Capability Negotiation: Updated > solution document (-03) > > > > Ingemar Johansson S (LU/EAB) wrote: >> Hi >> >> If I understand things correctly (snippet below from section 3.5.3), >> there will be two offer/answers during call setup. The second >> offer/answer in order to ensure that "intermediaries" understand. This >> might have some issues regarding call setup times e.g in wireless access >> where service radio bearers might have a limited bitrate, currently I >> cannot tell much this might mean in extra call setup time. >> >> One possible solution is that it may be possible that the call could be >> setup already after the first offer/answer ?, this probably assumes that >> possible radio resource management understands the first offer/answer. >> > That's correct. As far as the offerer and the answerer is > concerned, all media stream negotiation is complete after the > first exchange. The second exchange is merely done as a courtesy > to any intermediaries that may not understand what was actually > going on. If those intermediaries do understand it (and have a > need to a know in the first place), then the second exchange is > effectively a no-op for all parties. > > -- Flemming > >> Regards >> Ingemar >> >> ============================== >> If the offer/answer exchange was succesful, and if the answerer >> selected one of the potential configurations from the offer as the >> actual configuration, then the offerer SHOULD perform another >> offer/answer exchange: The new offer should contain the selected >> potential configuration as the actual configuration, i.e. with the >> actual configuration used in the "m=" line and any other relevant >> attributes. This second offer/answer exchange will not modify the >> session in any way, however it will help intermediaries that look at >> the SDP, but do not understand or support the capability negotiation >> extensions, to understand the details of the media stream(s) that >> were actually negotiated. >> ============================== >> >> >>> -----Original Message----- >>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>> Sent: den 20 februari 2007 04:00 >>> To: mmusic >>> Subject: [MMUSIC] SDP Capability Negotiation: Updated >>> solution document (-03) >>> >>> Greetings >>> >>> I have just submitted an updated solution document as >>> draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which >>> you can retrieve from >>> http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa >>> bility-negotiation-03.txt >>> until it appears in the archives. >>> >>> The list of changes (from Section 9.1): >>> o Base option tag name changed from "v0" to "cap-v0". >>> o Added new section on extension capability attributes o >>> Firmed up offer/answer procedures. >>> o Added security considerations >>> o Added IANA considerations >>> >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> >> >> > --------------020607070301020801020200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Ingemar Johansson S (LU/EAB) wrote:
Hi
 
I checked out a little and _very_ rougly speaking the call setup time will be increased by ~1.0 second due to the extra offer/answer, this of course depends heaviliy on the achievable compression ratio of SigComp and the bitrate of the signaling radio bearer, the figures assume HSPA access.
Thanks. To put that in perspective, what is the approximate call setup time without the extra offer/answer (and does it use preconditions, resource reservation, etc.) ?

-- Flemming
 
Ingemar
 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: den 22 februari 2007 13:09
To: Ingemar Johansson S (LU/EAB)
Cc: mmusic
Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03)



Ingemar Johansson S (LU/EAB) wrote: 
Hi

If I understand things correctly (snippet below from section 3.5.3),
there will be two offer/answers during call setup. The second
offer/answer in order to ensure that "intermediaries" understand. This
might have some issues regarding call setup times e.g in wireless access
where service radio bearers might have a limited bitrate, currently I
cannot tell much this might mean in extra call setup time.

One possible solution is that it may be possible that the call could be
setup already after the first offer/answer ?, this probably assumes that
possible radio resource management understands the first offer/answer.
That's correct. As far as the offerer and the answerer is concerned, all media stream negotiation is complete after the first exchange. The second exchange is merely done as a courtesy to any intermediaries that may not understand what was actually going on. If those intermediaries do understand it (and have a need to a know in the first place), then the second exchange is effectively a no-op for all parties.

-- Flemming 

Regards
Ingemar

============================== 
   If the offer/answer exchange was succesful, and if the answerer 
   selected one of the potential configurations from the offer as the 
   actual configuration, then the offerer SHOULD perform another 
   offer/answer exchange: The new offer should contain the selected 
   potential configuration as the actual configuration, i.e. with the 
   actual configuration used in the "m=" line and any other relevant 
   attributes. This second offer/answer exchange will not modify the 
   session in any way, however it will help intermediaries that look at 
   the SDP, but do not understand or support the capability negotiation 
   extensions, to understand the details of the media stream(s) that 
   were actually negotiated.  
============================== 

  
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: den 20 februari 2007 04:00
To: mmusic
Subject: [MMUSIC] SDP Capability Negotiation: Updated 
solution document (-03)

Greetings

I have just submitted an updated solution document as 
draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which 
you can retrieve from 
http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa
bility-negotiation-03.txt
until it appears in the archives.

The list of changes (from Section 9.1):
o Base option tag name changed from "v0" to "cap-v0".
o Added new section on extension capability attributes o 
Firmed up offer/answer procedures.
o Added security considerations
o Added IANA considerations


Thanks

-- Flemming





_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
--------------020607070301020801020200-- --===============1823195279== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1823195279==-- From mmusic-bounces@ietf.org Fri Feb 23 14:54:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKgU3-00026c-52; Fri, 23 Feb 2007 14:53:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKgU1-00026Q-98 for mmusic@ietf.org; Fri, 23 Feb 2007 14:53:33 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKgTz-0005Ea-Qy for mmusic@ietf.org; Fri, 23 Feb 2007 14:53:33 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 23 Feb 2007 11:53:32 -0800 X-IronPort-AV: i="4.14,212,1170662400"; d="scan'208"; a="466725832:sNHT113521858" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1NJrSNJ024478; Fri, 23 Feb 2007 11:53:28 -0800 Received: from dwingwxp (sjc-vpn6-746.cisco.com [10.21.122.234]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1NJrOho002316; Fri, 23 Feb 2007 11:53:24 -0800 (PST) From: "Dan Wing" To: "'Ingemar Johansson S \(LU/EAB\)'" , "'Flemming Andreasen'" Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated solution document(-03) Date: Fri, 23 Feb 2007 11:53:19 -0800 Message-ID: <022001c75784$478d9870$ea7a150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050478920E@esealmw109.eemea.ericsson.se> Thread-Index: AcdWek2g7VhaSezLQLe0lREFpGiX5gA14zWAAAyJX6A= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4699; t=1172260408; x=1173124408; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Update d=20solution=20document(-03) |Sender:=20; bh=IZHS3WzQkdT/QzKISn4bl7KScqP8tyZIYdTovPrIMro=; b=D2h2Vh5xqOg9GoNtsHCpTduH9PTieG4MQkkj0aXfqxx+nMNzcrFtVSedX526SQyiNNElL0ag FjANn1P3uqfDD7Ec5thJ1ZmKKKzPTi3B0fUfKU1S7HT/3Oa7kjPPKG7O; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: 'mmusic' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org But there is only this additional delay if the middleboxes don't understand the first offer/answer, exchange, right? The solution seems to be upgrade the software in them so they understand the new SDP Capability Negotiation in the first exchange. The extra o/a is just to provide some accommodation during the transition to everything understanding SDP Cap. Neg. -d > -----Original Message----- > From: Ingemar Johansson S (LU/EAB) > [mailto:ingemar.s.johansson@ericsson.com] > Sent: Friday, February 23, 2007 6:01 AM > To: Flemming Andreasen > Cc: mmusic > Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated > solution document(-03) > > Hi > > I checked out a little and _very_ rougly speaking the call > setup time will be increased by ~1.0 second due to the extra > offer/answer, this of course depends heaviliy on the > achievable compression ratio of SigComp and the bitrate of > the signaling radio bearer, the figures assume HSPA access. > > Ingemar > > > > ________________________________ > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: den 22 februari 2007 13:09 > To: Ingemar Johansson S (LU/EAB) > Cc: mmusic > Subject: Re: [MMUSIC] SDP Capability Negotiation: > Updated solution document (-03) > > > > > Ingemar Johansson S (LU/EAB) wrote: > > Hi > > If I understand things correctly (snippet below > from section 3.5.3), > there will be two offer/answers during call > setup. The second > offer/answer in order to ensure that > "intermediaries" understand. This > might have some issues regarding call setup > times e.g in wireless access > where service radio bearers might have a > limited bitrate, currently I > cannot tell much this might mean in extra call > setup time. > > One possible solution is that it may be > possible that the call could be > setup already after the first offer/answer ?, > this probably assumes that > possible radio resource management understands > the first offer/answer. > > > That's correct. As far as the offerer and the answerer > is concerned, all media stream negotiation is complete after > the first exchange. The second exchange is merely done as a > courtesy to any intermediaries that may not understand what > was actually going on. If those intermediaries do understand > it (and have a need to a know in the first place), then the > second exchange is effectively a no-op for all parties. > > -- Flemming > > > > Regards > Ingemar > > ============================== > If the offer/answer exchange was succesful, > and if the answerer > selected one of the potential configurations > from the offer as the > actual configuration, then the offerer > SHOULD perform another > offer/answer exchange: The new offer should > contain the selected > potential configuration as the actual > configuration, i.e. with the > actual configuration used in the "m=" line > and any other relevant > attributes. This second offer/answer > exchange will not modify the > session in any way, however it will help > intermediaries that look at > the SDP, but do not understand or support > the capability negotiation > extensions, to understand the details of the > media stream(s) that > were actually negotiated. > ============================== > > > > -----Original Message----- > From: Flemming Andreasen > [mailto:fandreas@cisco.com] > Sent: den 20 februari 2007 04:00 > To: mmusic > Subject: [MMUSIC] SDP Capability > Negotiation: Updated > solution document (-03) > > Greetings > > I have just submitted an updated > solution document as > > draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which > you can retrieve from > > http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa > bility-negotiation-03.txt > until it appears in the archives. > > The list of changes (from Section 9.1): > o Base option tag name changed from > "v0" to "cap-v0". > o Added new section on extension > capability attributes o > Firmed up offer/answer procedures. > o Added security considerations > o Added IANA considerations > > > Thanks > > -- Flemming > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Feb 23 18:22:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKjit-0000pJ-85; Fri, 23 Feb 2007 18:21:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKjir-0000pB-UM for mmusic@ietf.org; Fri, 23 Feb 2007 18:21:05 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKjio-0000R3-Cu for mmusic@ietf.org; Fri, 23 Feb 2007 18:21:05 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1NNL1ki011591 for ; Fri, 23 Feb 2007 18:21:01 -0500 Received: from [135.9.42.38] ([135.9.42.38]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Feb 2007 16:21:01 -0700 Message-ID: <45DF76DA.8030700@avaya.com> Date: Fri, 23 Feb 2007 16:20:58 -0700 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ingemar Johansson S (LU/EAB)" Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt References: <026F8EEDAD2C4342A993203088C1FC0504789240@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0504789240@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2007 23:21:01.0109 (UTC) FILETIME=[47E80E50:01C757A1] X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Ingemar- Thanks for your comments. Let me try to explain the approach we took. Our intent was to associate each cfmt attribute with a codec in a cmed attribute, in just the same way that the fmtp attribute is associated with a codec (via payload type) in the media line. We didn't consider a mix-and-match at the codec level within the pcfg attribute. I'll most likely mess this up, but I believe the following is equivalent to your SDP (you didn't seem to use the cmft:5 and cfmt:6 lines in your description; doing so would cause the following example to perhaps be even larger): a=creq:1 a=cmed:1 AMR AMR AMR AMR AMR AMR a=cmft:1 mode-change-capability=1; max-red-220; mode-set=0,2,4,7 a=cfmt:2 mode-change-capability=1; max-red=220; mode-set=0,3,5,6 a=cfmt:3 mode-change-capability=1; max-red-220; octet-align=1; mode-set=0,2,4,7 a=cfmt:4 mode-change-capability=1; max-red=220; octet-align=1; mode-set=0,3,5,6 a=cfmt:5 mode-change-capability=2; octet-align=1; mode-set=0,2,4,7 a=cfmt:6 mode-change-capability=2; octet-align=1; mode-set=0,3,5,6 a=cenc:1 16000/1 a=cenc:2 8000/1 a=cenc:3 16000/1 a=cenc:4 8000/1 a=cenc:5 16000/1 a=cenc:6 8000/1 m=audio 49152 RTP/AVP 97 a=rtpmap:97 AMR/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220 pcfg:1 m=1|2 pt=1:98,2:99 pcfg:2 m=3|4 pt=3:98,4:99 pcfg:3 m=5|6 pt=5:98,5:99 My version takes about half again as many characters as yours. There might be a third way to do this as well - suppose the cfmt and cenc attributes were applicable to multiple codecs, and multiple lines were applicable to one codec (equivalent to your assumption). Then we might say something like: a=creq:1 a=cmed:1 AMR AMR AMR AMR AMR AMR a=cenc:1,3,5 16000/1 a=cenc:2,4,6 8000/1 a=cfmt:1,2,3,4 mode-change-capability=1 a=cfmt:5,6 mode-change-capability=2 a=cfmt:1,2,3,5 max-red=220 a=cfmt:3,4,5,6 octet-align=1 a=cfmt:???? mode-change-neighbor=1 a=cfmt:???? mode-change-period=2 a=cfmt:1,3,5 mode-set=0,2,4,7 a=cfmt:2,4,6 mode-set=0,3,5,6 m=audio 49152 RTP/AVP 97 a=rtpmap:97 AMR/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220 pcfg:1 m=1|2 pt=1:98,2:99 pcfg:2 m=3|4 pt=3:98,4:99 pcfg:3 m=5|6 pt=5:98,5:99 This form takes slightly fewer characters than yours (I left in the two format parameters you didn't seem to use), but I'm not sure which one is more useful or readable. Both permit the SDP generator to code format parameters on multiple lines, rather than force one long line, but still permit it if desired. Codecs with lots of formatting parameters and options are always problematic in capability announcements - unless you can declare lot of "don't-care" values or use popular defaults. It seems almost any method will do if there is little reuse of parameters. What do you think? -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Ingemar Johansson S (LU/EAB) wrote: > Hi > > Reading the draft I have the following simple question > Would it be possible, based on all the possible attributes given in > http://tools.ietf.org/id/draft-ietf-avt-rtp-amr-bis-06.txt > to formulate an SDP offer like the one below. > I am not sure that it is possible to combine several cmft's in the pcfg > in the f=x,y,z.. way that I written below, it is possible that it is > sematically incorrect, anyway comments welcome. > Regards > Ingemar > ======================== > a=creq:v1 > a=cmed:1 AMR > a=cfmt:1 mode-change-capability=1; > a=cfmt:2 mode-change-capability=2; > a=cfmt:3 max-red=220; > a=cfmt:4 octet-align=1; > a=cfmt:5 mode-change-neighbor=1; > a=cfmt:6 mode-change-period=2; > a=cfmt:7 mode-set=0,2,4,7; > a=cfmt:8 mode-set=0,3,5,6; > a=cenc:1 16000/1 > a=cenc:2 8000/1 > m=audio 49152 RTP/AVP 97 > a=rtpmap:97 AMR/16000/1 > a=fmtp:97 mode-change-capability=2; max-red=220 > pcfg:1 m=(1 f=1,3,7 e=1 pt=98)|(1 f=1,3,8 e=2 pt=99) > pcfg:2 m=(1 f=1,3,4,7 e=1 pt=98)|(1 f=1,3,4,8 e=2 pt=99) > pcfg:3 m=(1 f=2,4,7 e=1 pt=98)|(1 f=2,4,8 e=2 pt=99) > ======================== > > >>-----Original Message----- >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Sent: den 21 februari 2007 16:50 >>To: i-d-announce@ietf.org >>Cc: mmusic@ietf.org >>Subject: [MMUSIC] I-D >>ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.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 : SDP media capabilities Negotiation >> Author(s) : F. Andreasen, et al. >> Filename : >>draft-ietf-mmusic-sdp-media-capabilities-01.txt >> Pages : 22 >> Date : 2007-2-21 >> >>Session Description Protocol (SDP) capability negotiation provides a >> general framework for negotiating capabilities in SDP. The base >> framework defines only capabilities for negotiating transport >> protocols and attributes. In this document, we extend the >>framework >> by defining media capabilities that can be used to negotiate media >> types and their associated parameters. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-medi >>a-capabilities-01.txt >> >>To remove yourself from the I-D Announcement list, send a >>message to i-d-announce-request@ietf.org with the word >>unsubscribe in the body of the message. >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >>Internet-Drafts are also available by anonymous FTP. Login >>with the username "anonymous" and a password of your e-mail >>address. After logging in, type "cd internet-drafts" and then >>"get draft-ietf-mmusic-sdp-media-capabilities-01.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html or >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE >>/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-01.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >>mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >>Below is the data which will enable a MIME compliant mail >>reader implementation to automatically retrieve the ASCII >>version of the Internet-Draft. >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Feb 23 18:50:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkBN-0005HI-Us; Fri, 23 Feb 2007 18:50:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkBL-00055n-NJ for mmusic@ietf.org; Fri, 23 Feb 2007 18:50:31 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKkBJ-0005SP-0H for mmusic@ietf.org; Fri, 23 Feb 2007 18:50:31 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1NNoPs25668; Fri, 23 Feb 2007 18:50:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Feb 2007 17:50:09 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F522982@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0F52297F@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDP Capability Negotiation Thread-Index: AcdVuc04Tg5tD+SJS+SsfSygYFLF0QB6zIDgAAAHWKA= From: "Francois Audet" To: "Flemming Andreasen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Subject: [MMUSIC] RE: SDP Capability Negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > > Given the requirement for a general purpose capability=20 > negotiation framework, then this seems a reasonable solution.=20 > I still maintain it is overkill for best effort SRTP=20 > negotiation, but I am prepared to support it if we can get it=20 > moving forward very quickly. If we can't achieve consensus at=20 > the Prague meeting that it is ready for WGLC, I would wish to=20 > reconsider Hadriel's alternative. Same here. I agree 100% with John. Here are my comments: - What do we do with RFC 3407 and RFC 3388? Are we deprecating them?=20 If not, what are the interactions of this draft with them? I think this=20 needs to be covered. (Maybe it's as simple as saying MUST not be used=20 together: I don't know). - Woulnd't the a=3Dcsup: cap-v0 be functionaly identical to a:creq: cap-v0???=20 I think they would. If that's the case, I'd like clarification of if=20 a=3Dcsup: cap-v0 is legal or or not to include (I'd say no). The fact that=20 a-csup: cap-v0 is specifically spelled out in examples on page 10 is=20 very confusing because I can't figure out a use case. If John's point=20 about the whole cap-v0 being redundant and therefore should be removed,=20 then it would solve the problem.=20 - Generally speaking, there are quite a few cases in the spec where=20 you "could include a parameter, or not". This generally leads to=20 interop problems unless the spec is absolutely clear on if it is=20 mandatory or not. - Similartly, there are cases where different format for the same=20 things can be used, also leading to uncessary complexity and potential=20 interop problems. For example, a single line saying "a=3Dcreq: cap-v0, foo"=20 or two lines "a=3Dcreq: capv0" and "a=3Dcreq: foo". I know we have precedents for this, but it seems gratuitous parsing complexity. - Section 3.5.2.1. Why is that example there? Shouldn't it be moved into 4.2=20 (replacing the current example)?=20 - Section 3.5.2.1: I see that we can have an a=3Dpcfg line per m line. That is=20 a bit confusing to me. Does it semantic vary depending on if it is one per=20 m-line or one for an a-line. How would we incate the following 2 subcases:=20 - Session level MIKEY (both audio and video) OR SDES for audio and for Video, vs=20 - Session level MIKEY (both audio and video) OR SDES for audio or for=20 Video, but not both=20 - Section 4.1:=20 - I find the second Offer/Answer in the diagram to be distracting.=20 I'd rather it would be omitted, and the text on page 33 describing the=20 possibility of having a second offer/answer to "lock down" the exchange=20 to describe it more as an optional procedure. I.e., it should be more=20 clear that this is really just OPTIONAL (in fact, I think this whole=20 second offer/answer thing should be in a 4.1.1 subsection, clearly=20 labelled as an optional enhancement).=20 - Section 4.2:=20 - I really don't understand what is the difference between 4.2 and 4.1.=20 They seem identical, except that 4.2 adds an explicit "a=3Dpcfg: 10 t=3D2" line. If I understand the procedure correctly, this line does absolutely=20 nothing as it is implied from the m line anyways.=20 - I don't like this idea of having two ways to say the same thing.=20 I'd rather we either always explicitely list all the t lines, or=20 we always assume that the m line is the implicit missing one=20 =20 - Here is another idea. Could we redefine cap-v0 to be "best-effort transport=20 negotiation"? All the examples in this document are related to that (which=20 I'm okay with). I'm a bit worried that the scope of cap-v0 is wider than that=20 and since it is pretty vague what it would be used for, it would be an undue=20 requirement for people who need to support the only concrete usecase we have=20 today (i.e., best-effort SRTP/RTP?). Kind of a blank check. We could defer to=20 cap-v1 for other applications.=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Feb 24 10:22:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKyic-0003iw-66; Sat, 24 Feb 2007 10:21:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKyia-0003il-TM for mmusic@ietf.org; Sat, 24 Feb 2007 10:21:48 -0500 Received: from neptune.azu.com ([67.15.54.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKyiT-0003K6-5F for mmusic@ietf.org; Sat, 24 Feb 2007 10:21:48 -0500 Received: (qmail 25207 invoked by uid 89); 25 Feb 2007 00:21:20 +0900 Received: from unknown (HELO notebook) (202.219.189.108) by 0 with SMTP; 25 Feb 2007 00:21:20 +0900 Date: Sun, 25 Feb 2007 00:21:33 +0900 From: "Jia Hu" To: "mmusic" Organization: WICI X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Subject: [MMUSIC] CFP: IEEE/WIC/ACM Web Intelligence 2007 (Silicon Valley, USA) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wiiat@kis-lab.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Message-Id: [Apologies if you receive this more than once] ##################################################################### IEEE/WIC/ACM WEB INTELLIGENCE 2007 CALL FOR PAPERS ##################################################################### 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07) Silicon Valley, USA, November 2-5, 2007 http://www.cs.sjsu.edu/wi07/wi/ Sponsored By IEEE Computer Society Web Intelligence Consortium (WIC) Association for Computing Machinery (ACM) ###################################################################### # Conference Chair # Andrei Broder, VP, Yahoo Fellow, Yahoo! Research # # Program Chair and Co-Chairs # T.Y. Lin, Professor, SJSU, BISC Fellow, UC-Berkeley # Laura Haas, Director, IBM Almaden Research Center # Janusz Kacprzyk, Professor, Polish Academy of Science # Rajeev Motwani, Professor, Stanford University # # Organizing Chair # Howard Ho, Manager, IBM Almaden Research Center # # WI-IAT Joint Keynote Speakers (Tentative) # # Vinton G. Cerf, Turing Award Winner, # VP and Chief Internet Evangelist, Google # Anant Jhingran, VP and CTO, IBM Silicon Valley Laboratory # # (More WI Invited Speakers will be announced) # # (Papers Due: ** June 1 **, 2007) # Accepted papers will be published in the conference proceedings # by the IEEE Computer Society Press, which are indexed by EI. ###################################################################### Web Intelligence (WI) has been recognized as a new direction for scientific research and development to explore the fundamental roles as well as practical impacts of Artificial Intelligence (AI) (e.g., knowledge representation, planning, knowledge discovery and data mining, intelligent agents, and social network intelligence) and advanced Information Technology (IT) (e.g., wireless networks, ubiquitous devices, social networks, and data/knowledge grids) on the next generation of Web-empowered products, systems, services, and activities. It is one of the most important as well as promising IT research fields in the era of Web and agent intelligence. The 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07) will be jointly held with the 2007 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT'07), the 2007 IEEE International Conference on BioInformation and BioMedicine (BIBM'07), and the 2007 IEEE International Conference on Granular Computing (GrC'07) for providing synergism among the four research areas. It will provide opportunities for technical collaboration beyond that of previous conferences. The four conferences will have a joint opening, keynote, reception, and banquet. Attendees only need to register for one conference and can attend workshops, sessions and tutorials across the four conferences. We are also planning a joint panel and joint paper sessions that discuss common problems in the four areas. +++++++++++ Highlights +++++++++++ The conference will be held in Silicon Valley, California. Many high-tech companies and three distinguished universities (Stanford, UC Berkely and UCSC) are just around the corner. The highlight of the conference is that a unique forum consisting of a half-day industry/ demo track and free discussion will be organized to link industries and academics. Leading IT companies like IBM, Google, and Yahoo etc will present at the conference. The area now known as Silicon Valley has been a center of technological development since the 1950's. The name Silicon Valley stems from the early 1970's, when the area had become the center for many semiconductor companies. While still hosting semiconductor and microprocessor companies, the region now hosts the headquarters of high tech companies of every kind, including many of the best known and most prestigious names in personal computers, Web search, Internet auctions, networking, storage, databases, etc. +++++++++++++++++++ Topics of Interest +++++++++++++++++++ The topics and areas include, but not limited to: * WI Foundations - Brain Informatics for WI - Human level WI - New cognitive models and computational models for WI - Granular Computing (GrC) for WI - Autonomy-Oriented Computing (AOC) for WI * World Wide Wisdom Web (W4) - Meta-Knowledge Discovery and Representation - Problem Solver Markup Language (PSML) - Search of Best Means and Ends - Goal-Directed Services Support - Distributed Resources Optimization - Service Self-Aggregation - Web Inference Engine - Information and Knowledge Markets - New Social Interaction Paradigms - Social and Psychological Contexts - Regularities and Laws of W4 * Social Networks and Social Intelligence - Social Network Mining - Web Site Clustering - Link Topology and Site Hierarchy - Theories of Small-World Web - Virtual and Web Communities - Web-Based Cooperative Work - Knowledge Community Formation and Support - Ubiquitous Computing - Intelligent Wireless Web - Ubiquitous Learning Systems - Entertainment * Knowledge Grids and Grid Intelligence - Semantic Grids - Knowledge Resources and Services Discovery - On-Demand Planning and Routing - Brokering and Scheduling - Middleware Architectures and Tools * Web Mining and Farming - Text Mining - Data Stream Mining - Multimedia Data Mining - Web Content Mining - Web Log and Usage Mining - Learning User Profiles - Context Sensitive Web Mining - Web Information Clustering - Web Page Clustering and Mining - E-Mail Classification - Web Site Classification - Web Information Indexing - Data Warehousing - Web Farming and Warehousing * Semantics and Ontology Engineering - Ontology-Based Information Extraction and Retrieval - Ontology-Based Web Mining - Web-Based Ontology Learning - Semantic Web * Web Agents - Global Information Foraging - Distributed Problem Solving - Coordination - Resource Intermediary and Coordination Mechanisms - Self-Organization and Reproduction - Agent Networks and Topologies - Mobile Agents - Macroscopic Behavior Modeling - Trust Models for Web Agents * Web Services - Service-Oriented Computing - Matchmaking - Web Service Reconfiguration - Web Service Workflow Composition - Middleware-Based Ubiquitous Services - Grid Services * Web Information Filtering and Retrieval - Automatic Cataloging and Indexing - Clustering-Based Recommender Systems - Collaborative Filtering and Recommendation - Hybrid Recommendation - Information Retrieval Criteria and Evaluations - Web Information Categorization and Ranking - Proxy and Cache Techniques - Web Prediction and Prefetching - Distributed Web Search - Specifications for Web Information Extraction Process - Web Crawling Systems - Search Engines and Meta-search Engines * Intelligent Human-Web Interaction - Adaptive Web Interfaces - Context-Aware Computing - Learning User Profiles - Personalized Interfaces - Personalized Web Sites - Remembrance Agents - Multimedia Representation - Visualization of Information and Knowledge - Social and Psychological Issues * Web Support Systems - Information Retrieval Support Systems - Web Site Navigation Support Systems - Recommender Support Systems - Web-Based Decision Support Systems - Soft Computing (including neural networks, fuzzy logic, evolutionary computation, rough sets, and granular computing) and Uncertainty Management for WI * Intelligent e-Technology - Business Intelligence - Digital Library - Decentralized Community Communication Techniques - e-Community - e-Business and e-Commerce - e-Finance - e-Government - e-Learning - e-Publishing - e-Science - Intelligent Enterprise Portals - Web-Based Direct Marketing and CRM - Web-Based EDI - Web Security, Integrity, Privacy and Trust ++++++++++++++++++++++++++++++++++++ On-Line Submissions and Publication ++++++++++++++++++++++++++++++++++++ High-quality papers in all WI related areas are solicited. Paper submissions should be limited to a maximum of 7 pages in the IEEE 2-column format, the same as the camera-ready format (see the Author Guidelines of last year at http://www.computer.org/portal/pages/cscps/cps/final/wi06.xml). All submitted papers will be reviewed by the Program Committee on the basis of technical quality, relevance, significance, and clarity. Note that WI'07 will accept ONLY on-line submissions, containing PDF versions. Please use the Submission Form on the WI'07 website to submit your paper. Accepted papers will be published in the conference proceedings by the IEEE Computer Society Press that are indexed by EI. Submissions accepted as regular papers will be allocated 7 pages in the proceedings and accorded oral presentation times in the main conference. Submissions accepted as short papers will be allocated 4 pages in the proceedings and will have a shorter presentation time at the conference than regular papers. All co-authors will be notified at all time, for the submission, notification, and confirmation on the attendance. Submitting a paper to the conference and workshops means that, if the paper is accepted, at least one author should attend the conference to present the paper. The acceptance list and no-show list will be openly published on-line. For no-show authors, their affiliations will receive a notification. A selected number of WI'07 accepted papers will be expanded and revised for inclusion in Web Intelligence and Agent Systems: An International Journal (http://wi-consortium.org/journal.html) and in Annual Review of Intelligent Informatics (http://www.wi-consortium.org/annual.html). More detailed instructions and the On-Line Submission Form can be found from the WI'07 homepage: http://www.cs.sjsu.edu/wi07/wi/. ++++++++++++++++++++++++ WI'07 Best Paper Awards ++++++++++++++++++++++++ The best paper awards will be conferred at the conference on the authors of (1) the best research paper and (2) the best application paper. Application-oriented submissions will be considered for the best application paper award. The full author list and paper title will be announced on the Web Intelligence Consortium homepage: http://wi-consortium.org/html/wicawards.html ++++++++++++++++++++ Industry/Demo-Track ++++++++++++++++++++ We solicit Industry/Demo-Track papers by the following methods. (1) Industry papers of 4 pages can be submitted on the same schedule as the research track. (2) Separate 2 page demo proposals can submitted at a later schedule. (3) Full regular paper submissions can include a demo option. That is, a full paper submissions will be asked to specify if they would like to give a demonstration; choice of demonstrations (while utilizing information from the regular reviewing process) will be selected based on value as a demonstration. For options (1) and (2), please find more detailed instructions at the homepage: http://www.cs.sjsu.edu/wi07/wi/ We are planning to arrange the Industry/Demo track in the afternoon of November 3 (before and during the conference reception), jointly with the IAT'07 Demo sessions. Leading IT companies in Silicon Valley will be invited to attend this track. ++++++++++ Workshops ++++++++++ As an important part of the conference, the workshop program will focus on new research challenges and initiatives. All papers accepted for workshops will be included in the Workshop Proceedings published by the IEEE Computer Society Press that are indexed by EI, and will be available at the workshops. Detailed information is available at the conference homepage. Note: we will not have a separate workshop registration fee (i.e., conference registration covers everything). For more information, please visit the conference website at http://www.cs.sjsu.edu/wi07/wi/. ++++++++++ Tutorials ++++++++++ WI'07 also welcomes Tutorial proposals. WI'07 will include tutorials providing in-depth background on subjects that are of broad interest to the Web intelligence community. Both short (2 hours) and long (half day) tutorials will be considered. The tutorials will be part of the main conference technical program. Detailed information is available at the conference homepage. Note: we will not have a separate tutorials registration fee (i.e., only one conference registration covers everything). ++++++++++++++++ Important Dates ++++++++++++++++ Workshop proposal submission: March 20, 2007 Electronic submission of full papers: ** June 1, 2007 ** Tutorial proposal submission: June 15, 2007 Notification of paper acceptance: August 3, 2007 Camera-ready copies of accepted papers: August 17, 2007 Conference: November 2-5, 2007 ++++++++++++++++++++++++ Conference Organization ++++++++++++++++++++++++ Conference Chair: * Andrei Broder, Yahoo! Research, USA Program Chair: * Tsau Young (T.Y.) Lin, San Jose State University/UC Berkeley, USA WI Program Co-Chairs: * Laura Haas, IBM Almaden Research Center, USA * Janusz Kacprzyk, Polish Academy of Science, Poland * Rajeev Motwani, Stanford University, USA IAT Program Co-Chairs: * Jeffrey M. Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Matthias Klusch, German Research Center for AI, Germany * Chengqi Zhang, University of Technology, Sydney, Australia Organizing Chair: * Howard Ho, IBM Almaden Research Center, USA Workshop Co-Chairs: * Vijay Raghavan, University of Louisiana, USA * Yuefeng Li, Queensland University of Technology, Australia Tutorial Chair: * Pawan Lingras, Saint Mary's University, Canada Industry/Demo-Track Chair: * Jianchang Mao, Yahoo! Inc., USA Local Accommodations Co-Chairs: * David Scot Taylor, San Jose State University, USA * Tom Qi Zhang, Google, USA Publicity Chair: * James Wang, Clemson University, USA (chair) Publicity Co-Chairs: * Martine De Cock, Ghent University, Belgium * Jia Hu, International WIC Institute, China * Debajyoti Mukhopadhyay, West Bengal University of Technology, India IEEE-CS-TCII Chair: * Ning Zhong, Maebashi Institute of Technology, Japan ACM-SIGART Chair * Maria Gini, University of Minnesota, USA WIC Co-Chairs/Directors: * Ning Zhong, Maebashi Institute of Technology, Japan * Jiming Liu, University of Windsor, Canada WIC Advisory Board: * Edward A. Feigenbaum, Stanford University, USA * Setsuo Ohsuga, Waseda University, Japan * Benjamin Wah, University of Illinois, Urbana-Champaign, USA * Philip Yu, IBM Thomas J. Watson Research Center, USA * L.A. Zadeh, University of California Berkeley, USA WIC Tech. Committee & WI/IAT Steering Committee: * Jeffrey Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Nick Cercone, Dalhousie University, Canada * Dieter Fensel, National University of Ireland, Ireland * Georg Gottlob, Oxford University, UK * Lakhmi Jain, University of South Australia, Australia * Jianchang Mao, Yahoo! Inc., USA * Pierre Morizet-Mahoudeaux, Compiegne University of Technology, France * Hiroshi Motoda, Osaka University, Japan * Toyoaki Nishida, Kyoto University, Japan * Andrzej Skowron, Warsaw University, Poland * Jinglong Wu, Kagawa University, Japan * Xindong Wu, University of Vermont, USA * Yiyu Yao, University of Regina, Canada Webmaster: * Albert Sutojo, San Jose State University, USA *** Contact Information *** Jia Hu International WIC Institute, China E-mail: hujia@kis-lab.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Feb 25 12:29:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLNAi-0006hh-FS; Sun, 25 Feb 2007 12:28:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLNAh-0006ZO-7D for mmusic@ietf.org; Sun, 25 Feb 2007 12:28:27 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLNAd-0006H1-11 for mmusic@ietf.org; Sun, 25 Feb 2007 12:28:27 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 25 Feb 2007 09:28:22 -0800 X-IronPort-AV: i="4.14,216,1170662400"; d="scan'208"; a="42353001:sNHT61795854" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1PHSMMp008343; Sun, 25 Feb 2007 09:28:22 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1PHSLho010035; Sun, 25 Feb 2007 09:28:22 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 09:28:21 -0800 Received: from [10.21.88.208] ([10.21.88.208]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 09:28:21 -0800 Message-ID: <45E1C733.2000109@cisco.com> Date: Sun, 25 Feb 2007 12:28:19 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) References: <45DA6434.2060708@cisco.com> <680E6487-7D2A-4E50-98D9-33DA960EE51D@csperkins.org> In-Reply-To: <680E6487-7D2A-4E50-98D9-33DA960EE51D@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2007 17:28:21.0286 (UTC) FILETIME=[587ECC60:01C75902] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2574; t=1172424502; x=1173288502; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Update d=20solution=20document=0A=20(-03) |Sender:=20; bh=4Ch7kw554DVQzYR3f7zDdxJVnlMvUk7MK3NIWTWucys=; b=AB0Qv9XjZlp/r+7hOONVei1yVmikhpXYy9aYxZJQxWkWEDYwsqpr5xP7HBvispxa7HHUD8IN O46a1v7bgG+Q7u3HH4j0h6Xlfe9YLVCGJcwOUMkAbhmL2SHQx3SEXS0a; Authentication-Results: sj-dkim-8; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Colin Perkins wrote: > Flemming, > > On 20 Feb 2007, at 03:00, Flemming Andreasen wrote: >> I have just submitted an updated solution document as >> draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which you can >> retrieve from >> http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-03.txt >> until it appears in the archives. >> >> The list of changes (from Section 9.1): >> o Base option tag name changed from "v0" to "cap-v0". >> o Added new section on extension capability attributes >> o Firmed up offer/answer procedures. >> o Added security considerations >> o Added IANA considerations > > This is looking good, especially with the clarifications to the > offer/answer procedures. > > I would like to highlight one design choice on the list: when > attributes are included in "a=acap:" lines of a potential > configuration, those attributes are added to the set in the actual > configuration during the offer/answer exchange. This may sometimes > result in meaningless attributes, as is noted in Section 3.5.2 (half > way down page 25). An alternative is for the attributes in the > "a=acap:" lines of a potential configuration to replace those in the > actual configuration if that potential configuration is accepted. This > removes the potential for meaningless attributes, and makes > negotiation simpler, at the cost of needing to duplicate attributes > that are common to the actual and potential configurations. > > I'd like to hear opinions on this choice. I have a slight preference > for changing the draft so attributes in potential configurations > replace those in the actual during the negotiation phase, since that > seems conceptually simpler. I'm curious whether people believe it > would introduce too much overhead though. Comments? We had a brief thread titled "How big can SDP get" in the May-June 2006 timeframe. Magnus constructed a 10k SDP by using a large number of attribute lines. While the purpose of that example was to purposely generate a large SDP, it nevertheless illustrated that these SDPs can get quite large in practice, and if SDP capability negotiation automatically requires them to be 50-100% larger, then we're headed for trouble. I have a desire to maintain clear semantics as well, however I think the price can quickly become too high here (just think ICE and crypto attribute duplication), and hence I vote for keeping the structure as-is. -- Flemming > > --Colin Perkins > http://csperkins.org/ > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Feb 25 12:33:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLNFU-0002V7-TS; Sun, 25 Feb 2007 12:33:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLNFT-0002V2-S7 for mmusic@ietf.org; Sun, 25 Feb 2007 12:33:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLNFP-0007KH-1k for mmusic@ietf.org; Sun, 25 Feb 2007 12:33:23 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 25 Feb 2007 09:33:18 -0800 X-IronPort-AV: i="4.14,216,1170662400"; d="scan'208,217"; a="42353619:sNHT103639266" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1PHXGIf028263; Sun, 25 Feb 2007 09:33:16 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1PHXAho010875; Sun, 25 Feb 2007 09:33:10 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 09:33:10 -0800 Received: from [10.21.88.208] ([10.21.88.208]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 09:33:09 -0800 Message-ID: <45E1C854.1010005@cisco.com> Date: Sun, 25 Feb 2007 12:33:08 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document(-03) References: <022001c75784$478d9870$ea7a150a@amer.cisco.com> In-Reply-To: <022001c75784$478d9870$ea7a150a@amer.cisco.com> X-OriginalArrivalTime: 25 Feb 2007 17:33:09.0555 (UTC) FILETIME=[04512830:01C75903] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11363; t=1172424796; x=1173288796; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Update d=20solution=20document(-03) |Sender:=20; bh=d0uDjjZ12tpYS4OYqsi/z++dYnKviq+vJdZYMtqmmo8=; b=jMMMiZmOmRhjX2zKBgrV+G4QIJVKT/2Tnff/qJEHt0gspaP4mDeiI0Hohnj/AF7CH+Ox82zy SN41iVlIMN0KsrlaCuwZ44FJM67A6RZe9ZmjZDQFJ6FGYuN9wg8V4fGE; Authentication-Results: sj-dkim-7; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Cc: 'mmusic' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0088504956==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0088504956== Content-Type: multipart/alternative; boundary="------------090804020605030605050106" This is a multi-part message in MIME format. --------------090804020605030605050106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan Wing wrote: > But there is only this additional delay if the middleboxes don't > understand the first offer/answer, exchange, right? Right - and to be clear, it does not add to actual call setup delay. If the second o/a exchange can not be performed until receipt of the 200 Ok (read: no PRACK or preconditions), then there could be a clipping issue. As you note below, the solution to this problem is to upgrade the middle-boxes. -- Flemming > The solution > seems to be upgrade the software in them so they understand the > new SDP Capability Negotiation in the first exchange. > > The extra o/a is just to provide some accommodation during the > transition to everything understanding SDP Cap. Neg. > > -d > > > >> -----Original Message----- >> From: Ingemar Johansson S (LU/EAB) >> [mailto:ingemar.s.johansson@ericsson.com] >> Sent: Friday, February 23, 2007 6:01 AM >> To: Flemming Andreasen >> Cc: mmusic >> Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated >> solution document(-03) >> >> Hi >> >> I checked out a little and _very_ rougly speaking the call >> setup time will be increased by ~1.0 second due to the extra >> offer/answer, this of course depends heaviliy on the >> achievable compression ratio of SigComp and the bitrate of >> the signaling radio bearer, the figures assume HSPA access. >> >> Ingemar >> >> >> >> ________________________________ >> >> From: Flemming Andreasen [mailto:fandreas@cisco.com] >> Sent: den 22 februari 2007 13:09 >> To: Ingemar Johansson S (LU/EAB) >> Cc: mmusic >> Subject: Re: [MMUSIC] SDP Capability Negotiation: >> Updated solution document (-03) >> >> >> >> >> Ingemar Johansson S (LU/EAB) wrote: >> >> Hi >> >> If I understand things correctly (snippet below >> from section 3.5.3), >> there will be two offer/answers during call >> setup. The second >> offer/answer in order to ensure that >> "intermediaries" understand. This >> might have some issues regarding call setup >> times e.g in wireless access >> where service radio bearers might have a >> limited bitrate, currently I >> cannot tell much this might mean in extra call >> setup time. >> >> One possible solution is that it may be >> possible that the call could be >> setup already after the first offer/answer ?, >> this probably assumes that >> possible radio resource management understands >> the first offer/answer. >> >> >> That's correct. As far as the offerer and the answerer >> is concerned, all media stream negotiation is complete after >> the first exchange. The second exchange is merely done as a >> courtesy to any intermediaries that may not understand what >> was actually going on. If those intermediaries do understand >> it (and have a need to a know in the first place), then the >> second exchange is effectively a no-op for all parties. >> >> -- Flemming >> >> >> >> Regards >> Ingemar >> >> ============================== >> If the offer/answer exchange was succesful, >> and if the answerer >> selected one of the potential configurations >> from the offer as the >> actual configuration, then the offerer >> SHOULD perform another >> offer/answer exchange: The new offer should >> contain the selected >> potential configuration as the actual >> configuration, i.e. with the >> actual configuration used in the "m=" line >> and any other relevant >> attributes. This second offer/answer >> exchange will not modify the >> session in any way, however it will help >> intermediaries that look at >> the SDP, but do not understand or support >> the capability negotiation >> extensions, to understand the details of the >> media stream(s) that >> were actually negotiated. >> ============================== >> >> >> >> -----Original Message----- >> From: Flemming Andreasen >> [mailto:fandreas@cisco.com] >> Sent: den 20 februari 2007 04:00 >> To: mmusic >> Subject: [MMUSIC] SDP Capability >> Negotiation: Updated >> solution document (-03) >> >> Greetings >> >> I have just submitted an updated >> solution document as >> >> draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which >> you can retrieve from >> >> http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa >> bility-negotiation-03.txt >> until it appears in the archives. >> >> The list of changes (from Section 9.1): >> o Base option tag name changed from >> "v0" to "cap-v0". >> o Added new section on extension >> capability attributes o >> Firmed up offer/answer procedures. >> o Added security considerations >> o Added IANA considerations >> >> >> Thanks >> >> -- Flemming >> >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> >> >> >> >> >> > > --------------090804020605030605050106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Dan Wing wrote: 
But there is only this additional delay if the middleboxes don't
understand the first offer/answer, exchange, right?
Right  - and to be clear, it does not add to actual call setup delay.  If the second o/a exchange can not be performed until receipt of the 200 Ok (read: no PRACK or preconditions), then there could be a clipping issue. As you note below, the solution to this problem is to upgrade the middle-boxes.

-- Flemming 

 The solution
seems to be upgrade the software in them so they understand the
new SDP Capability Negotiation in the first exchange.  

The extra o/a is just to provide some accommodation during the
transition to everything understanding SDP Cap. Neg.  

-d


  
-----Original Message-----
From: Ingemar Johansson S (LU/EAB) 
[mailto:ingemar.s.johansson@ericsson.com] 
Sent: Friday, February 23, 2007 6:01 AM
To: Flemming Andreasen
Cc: mmusic
Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated 
solution document(-03)

Hi
 
I checked out a little and _very_ rougly speaking the call 
setup time will be increased by ~1.0 second due to the extra 
offer/answer, this of course depends heaviliy on the 
achievable compression ratio of SigComp and the bitrate of 
the signaling radio bearer, the figures assume HSPA access.
 
Ingemar
 


________________________________

	From: Flemming Andreasen [mailto:fandreas@cisco.com] 
	Sent: den 22 februari 2007 13:09
	To: Ingemar Johansson S (LU/EAB)
	Cc: mmusic
	Subject: Re: [MMUSIC] SDP Capability Negotiation: 
Updated solution document (-03)
	
	


	Ingemar Johansson S (LU/EAB) wrote: 

		Hi
		
		If I understand things correctly (snippet below 
from section 3.5.3),
		there will be two offer/answers during call 
setup. The second
		offer/answer in order to ensure that 
"intermediaries" understand. This
		might have some issues regarding call setup 
times e.g in wireless access
		where service radio bearers might have a 
limited bitrate, currently I
		cannot tell much this might mean in extra call 
setup time.
		
		One possible solution is that it may be 
possible that the call could be
		setup already after the first offer/answer ?, 
this probably assumes that
		possible radio resource management understands 
the first offer/answer.
		  

	That's correct. As far as the offerer and the answerer 
is concerned, all media stream negotiation is complete after 
the first exchange. The second exchange is merely done as a 
courtesy to any intermediaries that may not understand what 
was actually going on. If those intermediaries do understand 
it (and have a need to a know in the first place), then the 
second exchange is effectively a no-op for all parties.
	
	-- Flemming 
	
	

		Regards
		Ingemar
		
		============================== 
		   If the offer/answer exchange was succesful, 
and if the answerer 
		   selected one of the potential configurations 
from the offer as the 
		   actual configuration, then the offerer 
SHOULD perform another 
		   offer/answer exchange: The new offer should 
contain the selected 
		   potential configuration as the actual 
configuration, i.e. with the 
		   actual configuration used in the "m=" line 
and any other relevant 
		   attributes. This second offer/answer 
exchange will not modify the 
		   session in any way, however it will help 
intermediaries that look at 
		   the SDP, but do not understand or support 
the capability negotiation 
		   extensions, to understand the details of the 
media stream(s) that 
		   were actually negotiated.  
		============================== 
		
		  

			-----Original Message-----
			From: Flemming Andreasen 
[mailto:fandreas@cisco.com] 
			Sent: den 20 februari 2007 04:00
			To: mmusic
			Subject: [MMUSIC] SDP Capability 
Negotiation: Updated 
			solution document (-03)
			
			Greetings
			
			I have just submitted an updated 
solution document as 
			
draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which 
			you can retrieve from 
			
http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa
			bility-negotiation-03.txt
			until it appears in the archives.
			
			The list of changes (from Section 9.1):
			o Base option tag name changed from 
"v0" to "cap-v0".
			o Added new section on extension 
capability attributes o 
			Firmed up offer/answer procedures.
			o Added security considerations
			o Added IANA considerations
			
			
			Thanks
			
			-- Flemming
			
			
			
			
			
			_______________________________________________
			mmusic mailing list
			mmusic@ietf.org
			https://www1.ietf.org/mailman/listinfo/mmusic
--------------090804020605030605050106-- --===============0088504956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0088504956==-- From mmusic-bounces@ietf.org Sun Feb 25 15:01:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLPY4-0004fM-GU; Sun, 25 Feb 2007 15:00:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLPY3-0004fF-IA for mmusic@ietf.org; Sun, 25 Feb 2007 15:00:43 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLPY1-0005LU-Ae for mmusic@ietf.org; Sun, 25 Feb 2007 15:00:43 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2007 12:00:40 -0800 X-IronPort-AV: i="4.14,216,1170662400"; d="scan'208,217"; a="466970300:sNHT125240122" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1PK0eJd001845; Sun, 25 Feb 2007 12:00:40 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1PK0XnF020196; Sun, 25 Feb 2007 12:00:33 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 12:00:33 -0800 Received: from [10.21.88.208] ([10.21.88.208]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 12:00:32 -0800 Message-ID: <45E1EADF.1040408@cisco.com> Date: Sun, 25 Feb 2007 15:00:31 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [MMUSIC] RE: SDP Capability Negotiation References: <50B1CBA96870A34799A506B2313F26670B1A27CF@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B1A27CF@ntht201e.siemenscomms.co.uk> X-OriginalArrivalTime: 25 Feb 2007 20:00:33.0080 (UTC) FILETIME=[9B77FB80:01C75917] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=24594; t=1172433640; x=1173297640; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20RE=3A=20SDP=20Capability=20Negotiation |Sender:=20; bh=22r4BS6WAL9MnfWlHRtf0O8D2m6DOyau+m9wQIG+1Hs=; b=V6CZ+tIJZrB2G6gVCyfVL1PG6BjxArOB0ILOUyKVD9Uv8WZ0h9kTUt22AnYsrJDVh3oLE4AM mcArJtBGssqw3dDv8VqrVMY3mOWbOs83V1xcKIQ+4QyIUdOSX6YOm6mo; Authentication-Results: sj-dkim-8; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 439b8e44c906b144bce6744ebb966e60 Cc: Francois Audet , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1293388877==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1293388877== Content-Type: multipart/alternative; boundary="------------080108050905020306080602" This is a multi-part message in MIME format. --------------080108050905020306080602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the review and comments John Responses below..... Elwell, John wrote: > Flemming, > > Given the requirement for a general purpose capability negotiation > framework, then this seems a reasonable solution. I still maintain it > is overkill for best effort SRTP negotiation, but I am prepared to > support it if we can get it moving forward very quickly. If we can't > achieve consensus at the Prague meeting that it is ready for WGLC, I > would wish to reconsider Hadriel's alternative. > > Some comments on 03: > > 1. Section 1, 2nd bullet "A set of potential configurations indicating > which of those capabilities can be used for the session" - Can we > include the word "combination", e.g. "A set of potential > configurations indicating which combinations of those capabilities can > be used for the session" fixed > > 2. Section 1, 3rd bullet. Does it really provide "A set of actual > configurations"? I thought it just provided a single actual > configuration, selected from the set of potential configurations. changed accordingly > > 3. Section 3.1 "Two new attributes to support versioning and > extensions ..." Now that the version attribute has gone, should we > remove "versioning"? > removed > 4. Section 3.1 - there is no point in listing the supported or > required base - this can be implied simply by the presence of a=csup / > a=creq. > You could have a rule like that, but what does it then mean when say "cap-v1" is included in a "a=csup" ? Would "cap-v0" be supported as well ? I suppose that would be up to the definition of "cap-v1", but let's say "cap-v1" is not 100% backwards compatible, how would the offerer then indicate that it supports both "cap-v0" and "cap-v1" operation ? With the current definitions, we could have a "creq" attribute listing "cap-v0", and then a "csup" attribute listing "cap-v1" - the rules for "v1" could then say that you can "upgrade" to using "v1" operation. A "v1" compliant endpoint could do that, whereas a "v0" compliant endpoint would just continue with the "v0" operation. If we infer "v0" support by presence of certain attributes instead (I'd prefer the "pcfg" attribute since that would then allow for omitting the "csup" and "creq" attributes in the best-effort SRTP case today), then we can easily do something similar, however what about the case where the offerer supports only "v1" operation ? We would now need to include a "creq=cap-v1" attribute, but I suppose that's fine: We don't have to pay the price until (if) v1 actually comes along. I'll wait for others to chime in here, since the current solution was agreed to by the design team, but it seems ok to me (we still need the option tag but don't have to require its use in an offer that supports "v0" or other independent extensions only). > 5. Section 3.1, "A new attribute ("a=acap") that defines how to list > attribute parameter values.." In fact it contains complete attributes > or attribute values, not attribute parameter values. > reworded > 6. Section 3.1 "A new attribute ("a=acfg") to be used in an answer > SDP. The attribute identifies which of the potential configurations > from an offer were used as actual configurations..." Should it be "was > used as the actual configuration"? Surely you can select only one. > reworded - there can be multiple of these attributes in an answer SDP, but only one at the session level and one per media description. > 7. Section 3.1 "Potential configurations are always preferred over > actual configurations..." I find this confusing, because the example > offer to which it refers does not have an a=acfg attribute. We should > use a different term to express what is indicated by the "regular" > transport and attributes. In fact in lots of places in the document I > think the term "actual configuration" is used with different meanings. > I don't believe so - can you provides some examples of where you see such inconsistencies ? The use of the term "actual configuration" to reference what is in the offerered "m=" line, etc. is both deliberate and in line with the overall use of this term (AFAIK), so I would prefer not to have two different terms here. The reason for having the "actual configuration" attribute ("acfg") is because the answerer may use a different configuration from the offer than what was actually included as the actual configuration in the offer, and the offerer needs to know about that in order to process both the answer and incoming media correctly. Thus, the "selected configuration" from the offer is now what the offerer needs to use as the actual configuration (combined with the answer). In any case, I've rephrased the above referenced sentence slightly to try and make it clearer. > 8. Section 3.2.1. I don't see the need for the cap-v0 option tag - > isn't it implied by the presence of a=csup/creq? What is the meaning > of receiving a=csup/creq without the cap-v0 option tag? See answer to 4) above. > 9. Section 3.2.2 - the first paragraph could be replaced by a > reference to 3.2.1 for the meaning of option tags. > ok > 10. Section 3.4.2 states "The actual configuration attribute > identifies which of the potential configurations from an offer SDP > were used as actual configurations..." Again this seems to suggest > multiple actual configurations, but the meaning of this is not given. > As I understand it, there are multiple capabilities in an actual > configuration, but only one actual configuration. reworded. > > 11. Section 3.5.2 says that attributes from a potential configuration > are added to the regular attributes. This could result in two > attributes of the same type, e.g., two a=crypto lines. What happens in > this case? sdescriptions (RFC 4568) has rules for dealing with this; you simply pick one (based on the order in the resulting SDP). It brings up a good point though, namely how the answerer conceptually constructs the "viewed" offer SDP; I've added some additional rules saying potential configuration attributes are to be added before the originally provided attributes, and in the order specified by the potential configuration. > > 12. Section 3.5.2, last paragraph. Again I have trouble with the term > actual configuration. It is not clear whether this refers to the > regular configuration in the offer or in the answer (the latter > corresponding to the actual configuration indicated by the a=acfg line). I've tried rephrasing slightly to hopefully make it clearer. > > 13. In the same paragraph there seems to be a contradiction. The MUST > NOT sentence seems to be contradicted by the subsequent MAY sentence. > Again I think this is because of ambiguity in the term "actual > configuration". I think what it is trying to say is that you MUST NOT > send media in accordance with the m-line in the offer if you have > selected a potential configuration, but instead you MAY send media in > accordance with the a=acfg line in the answer. I don't see a contradiction in that paragraph, however I've tried to rephrase slightly to make it clearer. > > 14. Do we need to make any statements about asymmetrical > (direction-sensitive) attributes? I am thinking here of things like > a=sendonly and a=rcvonly. If you have an a=acap:1 a=sendonly line, and > this is used by a potential configuration that gets selected as the > actual configuration by the answerer, then if the answerer promotes > the sendonly attribute to a regular a=sendonly line in the answer, > then this is clearly wrong (but a=rcvonly would be correct). Agreed. > I don't have any practical use cases for using this, so perhaps we > just need to exclude this type of attribute from use in a=acap lines. I'm not following this part - why can direction attributes not be provided in acap lines ? Conversely, it sounds to me like you want us to outlaw something that is already forbidden by the existing o/a procedures (as supplemented by the procedures here) ? > > 15. There are some very long sections in the draft. Is it not possible > to break some of them up into sub-sections so that specific aspects > can be referenced more easily? > Please let me know of any specific suggestions here (the current section splits seem natural to me, and, examples aside, most sections are 2 pages or less, and only two sections are close to 4 pages long) Thanks -- Flemming --------------080108050905020306080602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks for the review and comments John

Responses below.....


Elwell, John wrote:
Flemming,
 
Given the requirement for a general purpose capability negotiation framework, then this seems a reasonable solution. I still maintain it is overkill for best effort SRTP negotiation, but I am prepared to support it if we can get it moving forward very quickly. If we can't achieve consensus at the Prague meeting that it is ready for WGLC, I would wish to reconsider Hadriel's alternative.
 
Some comments on 03:
 
1. Section 1, 2nd bullet "A set of potential configurations indicating which of those capabilities can be used for the session" - Can we include the word "combination", e.g. "A set of potential configurations indicating which combinations of those capabilities can be used for the session"
fixed
 
2. Section 1, 3rd bullet. Does it really provide "A set of actual configurations"? I thought it just provided a single actual configuration, selected from the set of potential configurations.
changed accordingly

 
3. Section 3.1 "Two new attributes to support versioning and extensions ..." Now that the version attribute has gone, should we remove "versioning"?

removed
4. Section 3.1 - there is no point in listing the supported or required base - this can be implied simply by the presence of a=csup / a=creq.

You could have a rule like that, but what does it then mean when say "cap-v1" is included in a "a=csup" ? Would "cap-v0" be supported as well ? I suppose that would be up to the definition of "cap-v1", but let's say "cap-v1" is not 100% backwards compatible, how would the offerer then indicate that it supports both "cap-v0" and "cap-v1" operation ? With the current definitions, we could have a "creq" attribute listing "cap-v0", and then a "csup" attribute listing "cap-v1" - the rules for "v1" could then say that you can "upgrade" to using "v1" operation. A "v1" compliant endpoint could do that, whereas a "v0" compliant endpoint would just continue with the "v0" operation.

If we infer "v0" support by presence of certain attributes instead (I'd prefer the "pcfg" attribute since that would then allow for omitting the "csup" and "creq" attributes in the best-effort SRTP case today), then we can easily do something similar, however what about the case where the offerer supports only "v1" operation ? We would now need to include a "creq=cap-v1" attribute, but I suppose that's fine: We don't have to pay the price until (if) v1 actually comes along.

I'll wait for others to chime in here, since the current solution was agreed to by the design team, but it seems ok to me (we still need the option tag but don't have to require its use in an offer that supports "v0" or other independent extensions only).

5. Section 3.1, "A new attribute ("a=acap") that defines how to list attribute parameter values.." In fact it contains complete attributes or attribute values, not attribute parameter values.

reworded

6. Section 3.1 "A new attribute ("a=acfg") to be used in an answer SDP. The attribute identifies which of the potential configurations from an offer were used as actual configurations..." Should it be "was used as the actual configuration"? Surely you can select only one.

reworded - there can be multiple of these attributes in an answer SDP, but only one at the session level and one per media description.


7. Section 3.1 "Potential configurations are always preferred over actual configurations..." I find this confusing, because the example offer to which it refers does not have an a=acfg attribute. We should use a different term to express what is indicated by the "regular" transport and attributes. In fact in lots of places in the document I think the term "actual configuration" is used with different meanings.

I don't believe so - can you provides some examples of where you see such inconsistencies ?  The use of the term "actual configuration" to reference what is in the offerered "m=" line, etc. is both deliberate and in line with the overall use of this term (AFAIK), so I would prefer not to have two different terms here.

The reason for having the "actual configuration" attribute ("acfg") is because the answerer may use a different configuration from the offer than what was actually included as the actual configuration in the offer, and the offerer needs to know about that in order to process both the answer and incoming media correctly. Thus, the "selected configuration" from the offer is now what the offerer needs to use as the actual configuration (combined with the answer).

In any case, I've rephrased the above referenced sentence slightly to try and make it clearer.

8. Section 3.2.1. I don't see the need for the cap-v0 option tag - isn't it implied by the presence of a=csup/creq? What is the meaning of receiving a=csup/creq without the cap-v0 option tag?
See answer to 4) above.

9. Section 3.2.2 - the first paragraph could be replaced by a reference to 3.2.1 for the meaning of option tags.

ok

10. Section 3.4.2 states "The actual configuration attribute identifies which of the potential  configurations from an offer SDP were used as actual configurations..." Again this seems to suggest multiple actual configurations, but the meaning of this is not given. As I understand it, there are multiple capabilities in an actual configuration, but only one actual configuration.
reworded.

 
11. Section 3.5.2 says that attributes from a potential configuration are added to the regular attributes. This could result in two attributes of the same type, e.g., two a=crypto lines. What happens in this case?
sdescriptions (RFC 4568) has rules for dealing with this; you simply pick one (based on the order in the resulting SDP). It brings up a good point though, namely how the answerer conceptually constructs the "viewed" offer SDP; I've added some additional rules saying potential configuration attributes are to be added before the originally provided attributes, and in the order specified by the potential configuration.
 
12. Section 3.5.2, last paragraph. Again I have trouble with the term actual configuration. It is not clear whether this refers to the regular configuration in the offer or in the answer (the latter corresponding to the actual configuration indicated by the a=acfg line).
I've tried rephrasing slightly to hopefully make it clearer.

 
13. In the same paragraph there seems to be a contradiction. The MUST NOT sentence seems to be contradicted by the subsequent MAY sentence. Again I think this is because of ambiguity in the term "actual configuration". I think what it is trying to say is that you MUST NOT send media in accordance with the m-line in the offer if you have selected a potential configuration, but instead you MAY send media in accordance with the a=acfg line in the answer.
I don't see a contradiction in that paragraph, however I've tried to rephrase slightly to make it clearer.

 
14. Do we need to make any statements about asymmetrical (direction-sensitive) attributes? I am thinking here of things like a=sendonly and a=rcvonly. If you have an a=acap:1 a=sendonly line, and this is used by a potential configuration that gets selected as the actual configuration by the answerer, then if the answerer promotes the sendonly attribute to a regular a=sendonly line in the answer, then this is clearly wrong (but a=rcvonly would be correct).
Agreed.

I don't have any practical use cases for using this, so perhaps we just need to exclude this type of attribute from use in a=acap lines.
I'm not following this part - why can direction attributes not be provided in acap lines ? Conversely, it sounds to me like you want us to outlaw something that is already forbidden by the existing o/a procedures (as supplemented by the procedures here) ?

 
15. There are some very long sections in the draft. Is it not possible to break some of them up into sub-sections so that specific aspects can be referenced more easily?

Please let me know of any specific suggestions here (the current section splits seem natural to me, and, examples aside, most sections are 2 pages or less, and only two sections are close to 4 pages long)


Thanks

-- Flemming

--------------080108050905020306080602-- --===============1293388877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1293388877==-- From mmusic-bounces@ietf.org Sun Feb 25 16:05:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLQXe-0000Os-1Q; Sun, 25 Feb 2007 16:04:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLQXd-0000Od-1d for mmusic@ietf.org; Sun, 25 Feb 2007 16:04:21 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLQXb-0004Bo-RG for mmusic@ietf.org; Sun, 25 Feb 2007 16:04:21 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2007 13:04:20 -0800 X-IronPort-AV: i="4.14,216,1170662400"; d="scan'208,217"; a="393290349:sNHT118077684" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1PL4Jpb004822; Sun, 25 Feb 2007 13:04:19 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1PL4DDk012301; Sun, 25 Feb 2007 13:04:19 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 13:04:13 -0800 Received: from [10.21.88.208] ([10.21.88.208]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 13:04:13 -0800 Message-ID: <45E1F9CB.7010408@cisco.com> Date: Sun, 25 Feb 2007 16:04:11 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF0F522982@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0F522982@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 25 Feb 2007 21:04:13.0277 (UTC) FILETIME=[807BC8D0:01C75920] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23745; t=1172437459; x=1173301459; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20SDP=20Capability=20Negotiation |Sender:=20; bh=WlrYGUZ+/JR5wQp0ssidS7DpMeo+Jr8bnh1g2R6/LNA=; b=nhNn05Uuhutsdvh0jdx2UonFhno1sMJCQ2qf9ne//nab+Gr5VGI557V7a10V9ir5gDDRUkEA Q8H97nCM2cQLPBAwS0oAdKzv1L7WWW5IZaZ83IMeWlCQJ73IIXQ/Xjsd; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: SDP Capability Negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0147419841==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0147419841== Content-Type: multipart/alternative; boundary="------------070406080703050507080103" This is a multi-part message in MIME format. --------------070406080703050507080103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Francois Thanks for the review and comments. Please see below for responses..... Francois Audet wrote: >> From: Elwell, John [mailto:john.elwell@siemens.com] >> >> Given the requirement for a general purpose capability >> negotiation framework, then this seems a reasonable solution. >> I still maintain it is overkill for best effort SRTP >> negotiation, but I am prepared to support it if we can get it >> moving forward very quickly. If we can't achieve consensus at >> the Prague meeting that it is ready for WGLC, I would wish to >> reconsider Hadriel's alternative. >> > > Same here. I agree 100% with John. > > Here are my comments: > > - What do we do with RFC 3407 and RFC 3388? Are we deprecating them? > If not, what are the interactions of this draft with them? I think > this > needs to be covered. (Maybe it's as simple as saying MUST not be used > together: I don't know). > 3407 (simcap) provides both more and less than the core SDP capability negotiation framework. More in terms of covering things like codecs, and min/max values. Less in terms of only providing capabilities; there is nothing related to potential configurations and their associated negotiation. Once you add the media capabilities extensions to the mix, it's a different story though. Consequenlty, the media capabilities draft says something about 3407, whereas this one does not (there are no interactions between "pure" core SDP cap neg and 3407, just a bit of overlap). Let me know if you think that needs to be called out (and/or something differently should be said). With respect to 3388 (grouping), I don't see any overlap or interactions either (at least not with the core), however you can clearly define grouping semantics and/or SDP Capability Negotiation extensions that does lead to overlap. I'm not sure what to say about that in the core document (or that we even should be saying anything about it). Instead, we should be aware of this potential overlap and interactions when (if) defining new extensions for either, and may need to deal with them on a case-by-case basis. I'm pretty sure there is both a need and use for both though (albeit, if we were to do it all over, maybe not with all the currently defined grouping semantics). > - Woulnd't the a=csup: cap-v0 be functionaly identical to a:creq: > cap-v0??? > I think they would. If that's the case, I'd like clarification of if > a=csup: cap-v0 is legal or or not to include (I'd say no). The fact > that > a-csup: cap-v0 is specifically spelled out in examples on page 10 is > very confusing because I can't figure out a use case. If John's point > about the whole cap-v0 being redundant and therefore should be > removed, > then it would solve the problem. > Note that the example on page 10 is merely an isolated parameter encoding example. Having said that, you could envision a "cap-v1" extension at some point, and you may have a need to indicate that you also support "cap-v1". Another (more immediate) example is an offer requiring support an extensions the answerer does not have; the answer will then not perform sdp capability negotiation, however the answer will include the "csup" attribute with a list of supporting extensions - "cap-v0" would be in that list. > - Generally speaking, there are quite a few cases in the spec > where > you "could include a parameter, or not". This generally leads > to > interop problems unless the spec is absolutely clear on if it > is > mandatory or not. > Can you provide some specific pointers (and ideally highlight your concern in each case) ? > - Similartly, there are cases where different format for the > same > things can be used, also leading to uncessary complexity and > potential > interop problems. For example, a single line saying "a=creq: > cap-v0, foo" > or two lines "a=creq: capv0" and "a=creq: foo". I know we have > precedents > for this, but it seems gratuitous parsing complexity. > I'm open to having a single "csup" and "creq" line at the session-level as well as at most one per media description of you want. Are there other specific cases you can point to ? > - Section 3.5.2.1. Why is that example there? Shouldn't it be moved into > 4.2 > (replacing the current example)? > > No - it is providing example text for a particular piece of answerer operation detailed in the section right before it. I thought that particular piece of text/logic could use some illustrative examples, however it seemed a bit much to include it right where the relevant answerer processing text was (not least considering John's concern about section length), so I put in a following sub-section for ease of reference. We can move it though if you prefer. > - Section 3.5.2.1: I see that we can have an a=pcfg line per m line. That is > a bit confusing to me. Does it semantic vary depending on if it is one > per > m-line or one for an a-line. You can have several "pcfg" lines per "m=" line and each includes references to capabilities, such as transport protocol and attribute capabilities. You don't have a "pcfg" line "per attribute" capability per se. > How would we incate the following 2 > subcases: > > - Session level MIKEY (both audio and video) OR SDES for audio > and for > Video, vs > > - Session level MIKEY (both audio and video) OR SDES for audio > or for > Video, but not both > > The core framework does not enable you to express any constraints on inter-media description configuration selection (too complicated). You can specify session-level MIKEY by use of a session-level key-mgmt attribute capability and media-level sdescriptions by use of a media-level crypto-attribute for both the audio and the video stream. You will then have a potential configuration attribute for each media description listing MIKEY and sdescriptions as alternatives. However, the solution does not have the expressive power to require selection of the same mechanism by both media descriptions, or alternative mechanisms. Do you have a use case in mind for this ? Is this something you see as important for the core negotiation framework ? > - Section 4.1: > > - I find the second Offer/Answer in the diagram to be > distracting. > I'd rather it would be omitted, and the text on page 33 > describing the > possibility of having a second offer/answer to "lock down" the > exchange > to describe it more as an optional procedure. I.e., it should > be more > clear that this is really just OPTIONAL (in fact, I think this > whole > second offer/answer thing should be in a 4.1.1 subsection, > clearly > labelled as an optional enhancement). > That probably requires further discussion. It is currently at RECOMMENDED/SHOULD strength (specified in Section 3.5.3), whereas ICE has similar functionality at MUST strength (ice-13, Section 8). Can you elaborate on why you want this to be at OPTIONAL/MAY strength ? > - Section 4.2: > > - I really don't understand what is the difference between 4.2 > and 4.1. > They seem identical, except that 4.2 adds an explicit "a=pcfg: > 10 t=2" > line. If I understand the procedure correctly, this line does > absolutely > nothing as it is implied from the m line anyways. > > Sorry - it's old text to be ignored (the very first line in the section says "[EDITOR'S NOTE: Example to be updated - old copy below]") > - I don't like this idea of having two ways to say the > same thing. > I'd rather we either always explicitely list all the t > lines, or > we always assume that the m line is the implicit missing > one > So, it's a bad example (hence to be updated), however there is another use case. Let's assume we had a third transport protocol supported, however it is even less preferred than the actual configuration in the offer. The only way we would be able to specifiy that is by explicitly listing it in a "pcfg" attribute; there would then be another (less preferred) "pcfg" attribute using the third alternative transport protocol. > - Here is another idea. Could we redefine cap-v0 to be "best-effort > transport > negotiation"? All the examples in this document are related to that > (which > I'm okay with). I'm not sure what that means or more importantly what the draft implications of doing that are. Can you elaborate ? > I'm a bit worried that the scope of cap-v0 is wider > than that > and since it is pretty vague what it would be used for, it would be an > undue > requirement for people who need to support the only concrete usecase > we have > today (i.e., best-effort SRTP/RTP?). Please see the media capabilities extensions for something else it will be used for. Use for other transport protocols (e.g. AVPF) is a use-case as well. > Kind of a blank check. We could > defer to > cap-v1 for other applications. > If I understand correctly, I think this would amount to essentially throwing all the generality we have built-in out, and focus on solving the best-effort SRTP use case (plus maybe other transport protocols) only. That's not the guidance we got from either the AD(s) or the WG chairs, and it's also not what the requirements and hence current scope (and solution) is. I hope you are not arguing against that direction at this (late) point. We've tried pretty hard to focus on the core part that is of importance to the best-effort SRTP (and transport protocol in general) folks, while at the same time making it somewhat general and extensible so that people with additional requirements can use it as well (by way of defining extensions). In the process of doing that, there is no doubt a bit more implementation work than a "best-effort SRTP" only solution would incur, however we normally try and come up with somewhat general and reusable specifications as opposed to point-specific solutions. Again, we've tried pretty hard to make this delta as small as possible (witness the exclusion of media capabilities for example) while still making it generally usable. If you have specific suggestions for how we can better do that (and preferably have them specified before and agreed to in Prague), then please let us know. Thanks -- Flemming --------------070406080703050507080103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Francois

Thanks for the review and comments.

Please see below for responses.....

Francois Audet wrote: 
	From: Elwell, John [mailto:john.elwell@siemens.com] 

Given the requirement for a general purpose capability 
negotiation framework, then this seems a reasonable solution. 
I still maintain it is overkill for best effort SRTP 
negotiation, but I am prepared to support it if we can get it 
moving forward very quickly. If we can't achieve consensus at 
the Prague meeting that it is ready for WGLC, I would wish to 
reconsider Hadriel's alternative.
    

Same here. I agree 100% with John.

Here are my comments:

- What do we do with RFC 3407 and RFC 3388? Are we deprecating them? 
  If not, what are the interactions of this draft with them? I think
this 
  needs to be covered. (Maybe it's as simple as saying MUST not be used 
  together: I don't know).
3407 (simcap) provides both more and less than the core SDP capability negotiation framework. More in terms of covering things like codecs, and min/max values. Less in terms of only providing capabilities; there is nothing related to potential configurations and their associated negotiation. Once you add the media capabilities extensions to the mix, it's a different story though. Consequenlty, the media capabilities draft says something about 3407, whereas this one does not (there are no interactions between "pure" core SDP cap neg and 3407, just a bit of overlap). Let me know if you think that needs to be called out (and/or something differently should be said).

With respect to 3388 (grouping), I don't see any overlap or interactions either (at least not with the core), however you can clearly define grouping semantics and/or SDP Capability Negotiation extensions that does lead to overlap. I'm not sure what to say about that in the core document (or that we even should be saying anything about it). Instead, we should be aware of this potential overlap and interactions when (if) defining new extensions for either, and may need to deal with them on a case-by-case basis. I'm pretty sure there is both a need and use for both though (albeit, if we were to do it all over, maybe not with all the currently defined grouping semantics). 

- Woulnd't the a=csup: cap-v0 be functionaly identical to a:creq:
cap-v0??? 
  I think they would. If that's the case, I'd like clarification of if 
  a=csup: cap-v0 is legal or or not to include (I'd say no). The fact
that 
  a-csup: cap-v0 is specifically spelled out in examples on page 10 is 
  very confusing because I can't figure out a use case. If John's point 
  about the whole cap-v0 being redundant and therefore should be
removed, 
  then it would solve the problem.
Note that the example on page 10 is merely an isolated parameter encoding example. Having said that, you could envision a "cap-v1" extension at some point, and you may have a need to indicate that you also support "cap-v1". Another (more immediate) example is an offer requiring support an extensions the answerer does not have; the answer will then not perform sdp capability negotiation, however the answer will include the "csup" attribute with a list of supporting extensions - "cap-v0" would be in that list. 


	- Generally speaking, there are quite a few cases in the spec
where 
	  you "could include a parameter, or not". This generally leads
to 
	  interop problems unless the spec is absolutely clear on if it
is 
	  mandatory or not.
Can you provide some specific pointers (and ideally highlight your concern in each case) ? 

	- Similartly, there are cases where different format for the
same 
	  things can be used, also leading to uncessary complexity and
potential 
	  interop problems. For example, a single line saying "a=creq:
cap-v0, foo" 
	  or two lines "a=creq: capv0" and "a=creq: foo". I know we have
precedents
	  for this, but it seems gratuitous parsing complexity.
I'm open to having a single "csup" and "creq" line at the session-level as well as at most one per media description of you want. Are there other specific cases you can point to ? 


- Section 3.5.2.1. Why is that example there? Shouldn't it be moved into
4.2 
  (replacing the current example)?
No - it is providing example text for a particular piece of answerer operation detailed in the section right before it. I thought that particular piece of text/logic could use some illustrative examples, however it seemed a bit much to include it right where the relevant answerer processing text was (not least considering John's concern about section length), so I put in a following sub-section for ease of reference. We can move it though if you prefer. 

- Section 3.5.2.1: I see that we can have an a=pcfg line per m line. That is 
  a bit confusing to me. Does it semantic vary depending on if it is one
per 
  m-line or one for an a-line.
You can have several "pcfg" lines per "m=" line and each includes references to capabilities, such as transport protocol and attribute capabilities. You don't have a "pcfg" line "per attribute" capability per se. 

How would we incate the following 2
subcases: 

	- Session level MIKEY (both audio and video) OR SDES for audio
and for
	  Video, vs 

	- Session level MIKEY (both audio and video) OR SDES for audio
or for 
	  Video, but not both
The core framework does not enable you to express any constraints on inter-media description configuration selection (too complicated). You can specify session-level MIKEY by use of a session-level key-mgmt attribute capability and media-level sdescriptions by use of a media-level crypto-attribute for both the audio and the video stream. You will then have a potential configuration attribute for each media description listing MIKEY and sdescriptions as alternatives. However, the solution does not have the expressive power to require selection of the same mechanism by both media descriptions, or alternative mechanisms. Do you have a use case in mind for this ? Is this something you see as important for the core negotiation framework ? 

- Section 4.1: 

	- I find the second Offer/Answer in the diagram to be
distracting. 
	  I'd rather it would be omitted, and the text on page 33
describing the 
	  possibility of having a second offer/answer to "lock down" the
exchange 
	  to describe it more as an optional procedure. I.e., it should
be more 
	  clear that this is really just OPTIONAL (in fact, I think this
whole 
	  second offer/answer thing should be in a 4.1.1 subsection,
clearly 
	  labelled as an optional enhancement).
That probably requires further discussion. It is currently at RECOMMENDED/SHOULD strength (specified in Section 3.5.3), whereas ICE has similar functionality at MUST strength (ice-13, Section 8). Can you elaborate on why you want this to be at OPTIONAL/MAY strength ? 


- Section 4.2: 

	- I really don't understand what is the difference between 4.2
and 4.1. 
	  They seem identical, except that 4.2 adds an explicit "a=pcfg:
10 t=2"
	  line. If I understand the procedure correctly, this line does
absolutely 
	  nothing as it is implied from the m line anyways.
Sorry - it's old text to be ignored (the very first line in the section says "[EDITOR'S NOTE: Example to be updated - old copy below]")

		- I don't like this idea of having two ways to say the
same thing. 
	        I'd rather we either always explicitely list all the t
lines, or 
	        we always assume that the m line is the implicit missing
one
So, it's a bad example (hence to be updated), however there is another use case. Let's assume we had a third transport protocol supported, however it is even less preferred than the actual configuration in the offer. The only way we would be able to specifiy that is by explicitly listing it in a "pcfg" attribute; there would then be another (less preferred) "pcfg" attribute using the third alternative transport protocol. 

- Here is another idea. Could we redefine cap-v0 to be "best-effort
transport 
  negotiation"? All the examples in this document are related to that
(which 
  I'm okay with).
I'm not sure what that means or more importantly what the draft implications of doing that are. Can you elaborate ? 

I'm a bit worried that the scope of cap-v0 is wider
than that 
  and since it is pretty vague what it would be used for, it would be an
undue 
  requirement for people who need to support the only concrete usecase
we have 
  today (i.e., best-effort SRTP/RTP?).
Please see the media capabilities extensions for something else it will be used for. Use for other transport protocols (e.g. AVPF) is a use-case as well. 
Kind of a blank check. We could
defer to 
  cap-v1 for other applications.
If I understand correctly, I think this would amount to essentially throwing all the generality we have built-in out, and focus on solving the best-effort SRTP use case (plus maybe other transport protocols) only. That's not the guidance we got from either the AD(s) or the WG chairs, and it's also not what the requirements and hence current scope (and solution) is. I hope you are not arguing against that direction at this (late) point. We've tried pretty hard to focus on the core part that is of importance to the best-effort SRTP (and transport protocol in general) folks, while at the same time making it somewhat general and extensible so that people with additional requirements can use it as well (by way of defining extensions). In the process of doing that, there is no doubt a bit more implementation work than a "best-effort SRTP" only solution would incur, however we normally try and come up with somewhat general and reusable specifications as opposed to point-specific solutions. Again, we've tried pretty hard to make this delta as small as possible (witness the exclusion of media capabilities for example) while still making it generally usable. If you have specific suggestions for how we can better do that (and preferably have them specified before and agreed to in Prague), then please let us know.

Thanks

-- Flemming















--------------070406080703050507080103-- --===============0147419841== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0147419841==-- From mmusic-bounces@ietf.org Sun Feb 25 21:49:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVub-0006Co-JC; Sun, 25 Feb 2007 21:48:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVuZ-0006A3-P5 for mmusic@ietf.org; Sun, 25 Feb 2007 21:48:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVuY-00083h-Cm for mmusic@ietf.org; Sun, 25 Feb 2007 21:48:23 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 25 Feb 2007 18:48:22 -0800 X-IronPort-AV: i="4.14,217,1170662400"; d="scan'208"; a="42408991:sNHT42225480" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1Q2mLmW001248 for ; Sun, 25 Feb 2007 18:48:21 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1Q2mLho019088 for ; Sun, 25 Feb 2007 18:48:21 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 18:48:21 -0800 Received: from [10.21.88.208] ([10.21.88.208]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 18:48:21 -0800 Message-ID: <45E24A74.8050402@cisco.com> Date: Sun, 25 Feb 2007 21:48:20 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 02:48:21.0260 (UTC) FILETIME=[93A3F4C0:01C75950] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1047; t=1172458101; x=1173322101; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotiation=3A=20Updated=20solution=20docu ment=20(-04) |Sender:=20; bh=eMK+Jlp1PWOgbsWTI7QDiedhwrDgZ/euxPQXKfcbvMQ=; b=hXlqrmb60GcuA+mueOr6iAaW6QeYU7fjNBSB2nmnh40dS4WiWLVylADKgk4lFV1mIkHy3O1X 0oKYl6gYPLbRomaw/vZWBUbfN5ha50goMsZdT/iKcR1DjC86c74uG4fd; Authentication-Results: sj-dkim-6; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [MMUSIC] SDP Capability Negotiation: Updated solution document (-04) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Greetings I have just submitted an updated solution document as draft-ietf-mmusic-sdp-capability-negotiation-04.txt, which you can retrieve from the same place as the previous versions until it appears in the archives (actual URL omitted due to some rather aggressive e-mail filtering done by some organizations - look at the -03 e-mail). The following are the major changes compared to version -03: - Added explicit ordering rules for attributes added by potential configurations. - Noted that ICE interaction issues (ice-tcp specifically) may not be as clear as originally thought. - Added considerations on using rtpmap and fmtp attributes as attribute capabilities. - Added multiple transport protocol example. - Added session-level MIKEY and media level security descriptions example. Please note that this is the second-last version before Prague and our goal is to go WGLC after Prague. If you have any comments or concerns with this draft, now would be a good time to let us know. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Feb 25 22:04:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLW9u-0003Bn-CE; Sun, 25 Feb 2007 22:04:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLW9t-0003Aj-1O for mmusic@ietf.org; Sun, 25 Feb 2007 22:04:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLW9r-0001PK-In for mmusic@ietf.org; Sun, 25 Feb 2007 22:04:13 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2007 19:04:11 -0800 X-IronPort-AV: i="4.14,217,1170662400"; d="scan'208,217"; a="393366818:sNHT119181170" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1Q34Ak8019644 for ; Sun, 25 Feb 2007 19:04:10 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1Q34AGk001037 for ; Sun, 25 Feb 2007 19:04:10 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 19:04:10 -0800 Received: from [10.21.88.208] ([10.21.88.208]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 19:04:10 -0800 Message-ID: <45E24E29.2040603@cisco.com> Date: Sun, 25 Feb 2007 22:04:09 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 26 Feb 2007 03:04:10.0386 (UTC) FILETIME=[C95D1720:01C75952] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4459; t=1172459050; x=1173323050; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotation=3A=20Minutes=20of=202/20/07=20d esign=20team=20conference=0A=20call |Sender:=20; bh=+sZIP6Vli4XSIB4cqbed6XW3PROAnpOH9y+X70XHlY0=; b=GEIuPg+Ydmw6k7DhKnBWyV/n0AVKWfhne71YmTItH3qvBtRizRsaCgtc1EHIr/PboJQgvIIZ NSUdXDLxMNdw4Qg8YCNKeNsDoH64BQCPFojXHl+t7nAguiIj6IzRIjG1; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [MMUSIC] SDP Capability Negotation: Minutes of 2/20/07 design team conference call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1025358768==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1025358768== Content-Type: multipart/alternative; boundary="------------020409080105090808020009" This is a multi-part message in MIME format. --------------020409080105090808020009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings The SDP Capability Negotiation Design team had a conference call on 2/20/07. The attendees were: Robert Gilman Flemming Andreasen Roni Even Colin Perkins 1) The core SDP Capabilities Negotiation document is close to being done. We still need to add considerations for attribute capabilities in terms of whether all attributes are allowed or not. Team consensus was to not disallow any attributes at this point (incl fmtp and rtpmap), although we may reevaluate once the media capabilities work is more complete. For now, we will just add some considerations around the use of fmtp and rtpmap in attribute capabilities. The goal is to move the document to WGLC after Prague. We will ask a few key stakeholders to review the document at this point. 2) Media Capabilities Document The team spent a bit of time talking about problem scope and underlying model for what the media capabilities docoment is trying to solve. It is currently not clearly spelled out in the document, and the team agreed to take a step back and make this clearer. Specifically, problem scope and model related to issues around layered codecs, redundancy encoding, forward error correction, composite media types, and inter-media stream constraints to name some need to be clearer. Addressing all of these can get quite complicated (experience from SDPng), and hence both the scope and model for addressing this needs to be spelled out. We may choose to limit the scope. A few specific technical issues were discussed as well: - The cptmap attribute had been removed, however it will be added back in as it can help reduce overall message size. - Roni has been looking at BFCP to see how it fits in the framework - The ABNF needs to be sanity checked Thanks -- Flemming --------------020409080105090808020009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

The SDP Capability Negotiation Design team had a conference call on 2/20/07. The attendees were:

    Robert Gilman
    Flemming Andreasen
    Roni Even
    Colin Perkins

1) The core SDP Capabilities Negotiation document is close to being done.
We still need to add considerations for attribute capabilities in terms of whether all attributes are allowed or not. Team consensus was to not disallow any attributes at this point (incl fmtp and rtpmap), although we may reevaluate once the media capabilities work is more complete. For now, we will just add some considerations around the use of fmtp and rtpmap in attribute capabilities.

The goal is to move the document to WGLC after Prague. We will ask a few key stakeholders to review the document at this point.

2) Media Capabilities Document
The team spent a bit of time talking about problem scope and underlying model for what the media capabilities docoment is trying to solve. It is currently not clearly spelled out in the document, and the team agreed to take a step back and make this clearer. Specifically, problem scope and model related to issues around layered codecs, redundancy encoding, forward error correction, composite media types, and inter-media stream constraints to name some need to be clearer. Addressing all of these can get quite complicated (experience from SDPng), and hence both the scope and model for addressing this needs to be spelled out. We may choose to limit the scope.

A few specific technical issues were discussed as well:
- The cptmap attribute had been removed, however it will be added back in as it can help reduce overall message size.
- Roni has been looking at BFCP to see how it fits in the framework
- The ABNF needs to be sanity checked


Thanks

-- Flemming




--------------020409080105090808020009-- --===============1025358768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1025358768==-- From mmusic-bounces@ietf.org Mon Feb 26 02:46:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLaXv-0005tY-6W; Mon, 26 Feb 2007 02:45:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLaXt-0005tR-Pa for mmusic@ietf.org; Mon, 26 Feb 2007 02:45:17 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLaXm-0004Ui-Mi for mmusic@ietf.org; Mon, 26 Feb 2007 02:45:17 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 115FD20145; Mon, 26 Feb 2007 08:45:06 +0100 (CET) X-AuditID: c1b4fb3e-af6d2bb0000007e1-87-45e29001d696 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E8400203FF; Mon, 26 Feb 2007 08:45:05 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 08:45:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) Date: Mon, 26 Feb 2007 08:45:05 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05047C7F9D@esealmw109.eemea.ericsson.se> In-Reply-To: <45DEFAA7.6050604@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) Thread-Index: AcdXWCMqqNSy7/7HQS+4P0XX8qRXaQCIW+yg From: "Ingemar Johansson S \(LU/EAB\)" To: "Flemming Andreasen" X-OriginalArrivalTime: 26 Feb 2007 07:45:05.0736 (UTC) FILETIME=[07EF6480:01C7597A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0983781475==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0983781475== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7597A.079FAA6E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7597A.079FAA6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 The approximate call setup time without the extra offer/answer is ~3.8s. This again assuming HSPA access and as I understand it should include everything. Note hiowever that this is no exact figure, more to be viewed as an example. =20 Ingemar ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: den 23 februari 2007 15:31 To: Ingemar Johansson S (LU/EAB) Cc: mmusic Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) =09 =09 Ingemar Johansson S (LU/EAB) wrote:=20 Hi =20 I checked out a little and _very_ rougly speaking the call setup time will be increased by ~1.0 second due to the extra offer/answer, this of course depends heaviliy on the achievable compression ratio of SigComp and the bitrate of the signaling radio bearer, the figures assume HSPA access. Thanks. To put that in perspective, what is the approximate call setup time without the extra offer/answer (and does it use preconditions, resource reservation, etc.) ?=20 =09 -- Flemming=20 =09 =20 Ingemar =20 ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: den 22 februari 2007 13:09 To: Ingemar Johansson S (LU/EAB) Cc: mmusic Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03) =09 =09 Ingemar Johansson S (LU/EAB) wrote:=20 Hi =09 If I understand things correctly (snippet below from section 3.5.3), there will be two offer/answers during call setup. The second offer/answer in order to ensure that "intermediaries" understand. This might have some issues regarding call setup times e.g in wireless access where service radio bearers might have a limited bitrate, currently I cannot tell much this might mean in extra call setup time. =09 One possible solution is that it may be possible that the call could be setup already after the first offer/answer ?, this probably assumes that possible radio resource management understands the first offer/answer. =20 That's correct. As far as the offerer and the answerer is concerned, all media stream negotiation is complete after the first exchange. The second exchange is merely done as a courtesy to any intermediaries that may not understand what was actually going on. If those intermediaries do understand it (and have a need to a know in the first place), then the second exchange is effectively a no-op for all parties. =09 -- Flemming=20 =09 =09 Regards Ingemar =09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20 If the offer/answer exchange was succesful, and if the answerer=20 selected one of the potential configurations from the offer as the=20 actual configuration, then the offerer SHOULD perform another=20 offer/answer exchange: The new offer should contain the selected=20 potential configuration as the actual configuration, i.e. with the=20 actual configuration used in the "m=3D" line and any other relevant=20 attributes. This second offer/answer exchange will not modify the=20 session in any way, however it will help intermediaries that look at=20 the SDP, but do not understand or support the capability negotiation=20 extensions, to understand the details of the media stream(s) that=20 were actually negotiated. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20 =09 =20 -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: den 20 februari 2007 04:00 To: mmusic Subject: [MMUSIC] SDP Capability Negotiation: Updated=20 solution document (-03) =09 Greetings =09 I have just submitted an updated solution document as=20 =09 draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which=20 you can retrieve from=20 =09 http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa bility-negotiation-03.txt until it appears in the archives. =09 The list of changes (from Section 9.1): o Base option tag name changed from "v0" to "cap-v0". o Added new section on extension capability attributes o=20 Firmed up offer/answer procedures. o Added security considerations o Added IANA considerations =09 =09 Thanks =09 -- Flemming =09 =09 =09 =09 =09 =09 _______________________________________________ mmusic mailing list mmusic@ietf.org =09 https://www1.ietf.org/mailman/listinfo/mmusic =09 =20 =09 =20 ------_=_NextPart_001_01C7597A.079FAA6E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
The=20 approximate call setup time without the extra offer/answer is = ~3.8s.=20 This again assuming HSPA access and as I understand it should = include=20 everything. Note hiowever that this is no exact figure, more to be = viewed as an=20 example.
 
Ingemar

From: Flemming Andreasen=20 [mailto:fandreas@cisco.com]
Sent: den 23 februari 2007=20 15:31
To: Ingemar Johansson S (LU/EAB)
Cc:=20 mmusic
Subject: Re: [MMUSIC] SDP Capability Negotiation: = Updated=20 solution document (-03)



Ingemar Johansson S (LU/EAB) wrote:=20
Hi
 
I=20 checked out a little and _very_ rougly speaking the call setup time = will be=20 increased by ~1.0 second due to the extra offer/answer, this of = course=20 depends heaviliy on the achievable compression ratio of SigComp and = the=20 bitrate of the signaling radio bearer, the figures assume = HSPA=20 access.
Thanks. To put that in = perspective,=20 what is the approximate call setup time without the extra offer/answer = (and=20 does it use preconditions, resource reservation, etc.) ?

-- = Flemming=20
 
Ingemar
 

From: Flemming Andreasen [mailto:fandreas@cisco.com]=20
Sent: den 22 februari 2007 13:09
To: Ingemar=20 Johansson S (LU/EAB)
Cc: mmusic
Subject: Re: = [MMUSIC]=20 SDP Capability Negotiation: Updated solution document=20 (-03)



Ingemar Johansson S (LU/EAB) = wrote:=20 
Hi

If I understand things correctly (snippet below from section 3.5.3),
there will be two offer/answers during call setup. The second
offer/answer in order to ensure that "intermediaries" understand. This
might have some issues regarding call setup times e.g in wireless access
where service radio bearers might have a limited bitrate, currently I
cannot tell much this might mean in extra call setup time.

One possible solution is that it may be possible that the call could be
setup already after the first offer/answer ?, this probably assumes that
possible radio resource management understands the first offer/answer.
That's correct. As far as the offerer and the=20 answerer is concerned, all media stream negotiation is complete = after the=20 first exchange. The second exchange is merely done as a courtesy = to any=20 intermediaries that may not understand what was actually going on. = If=20 those intermediaries do understand it (and have a need to a know = in the=20 first place), then the second exchange is effectively a no-op for = all=20 parties.

-- Flemming 

Regards
Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=20
   If the offer/answer exchange was succesful, and if the answerer=20
   selected one of the potential configurations from the offer as the=20
   actual configuration, then the offerer SHOULD perform another=20
   offer/answer exchange: The new offer should contain the selected=20
   potential configuration as the actual configuration, i.e. with the=20
   actual configuration used in the "m=3D" line and any other relevant=20
   attributes. This second offer/answer exchange will not modify the=20
   session in any way, however it will help intermediaries that look at=20
   the SDP, but do not understand or support the capability negotiation=20
   extensions, to understand the details of the media stream(s) that=20
   were actually negotiated. =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=20

  
-----Original =
Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]=20
Sent: den 20 februari 2007 04:00
To: mmusic
Subject: [MMUSIC] SDP Capability Negotiation: Updated=20
solution document (-03)

Greetings

I have just submitted an updated solution document as=20
draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which=20
you can retrieve from=20
h=
ttp://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa
bility-negotiation-03.txt
until it appears in the archives.

The list of changes (from Section 9.1):
o Base option tag name changed from "v0" to "cap-v0".
o Added new section on extension capability attributes o=20
Firmed up offer/answer procedures.
o Added security considerations
o Added IANA considerations


Thanks

-- Flemming





_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.=
org/mailman/listinfo/mmusic

    

  =
------_=_NextPart_001_01C7597A.079FAA6E-- --===============0983781475== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0983781475==-- From mmusic-bounces@ietf.org Mon Feb 26 02:51:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLadk-0000xT-6C; Mon, 26 Feb 2007 02:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLadj-0000xL-10 for mmusic@ietf.org; Mon, 26 Feb 2007 02:51:19 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLadh-0005Ue-0m for mmusic@ietf.org; Mon, 26 Feb 2007 02:51:19 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8CF0D201BD; Mon, 26 Feb 2007 08:51:16 +0100 (CET) X-AuditID: c1b4fb3e-ae6d0bb0000007e1-a2-45e291745dfe Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 70BF0204DA; Mon, 26 Feb 2007 08:51:16 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 08:51:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated solution document(-03) Date: Mon, 26 Feb 2007 08:51:16 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05047C7FC6@esealmw109.eemea.ericsson.se> In-Reply-To: <45E1C854.1010005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotiation: Updated solution document(-03) Thread-Index: AcdZAxApnwgkotsPQKe5rvW6yyYchAAd4wWQ From: "Ingemar Johansson S \(LU/EAB\)" To: "Flemming Andreasen" , "Dan Wing" X-OriginalArrivalTime: 26 Feb 2007 07:51:16.0280 (UTC) FILETIME=[E4CBEB80:01C7597A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0475417909==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0475417909== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7597A.E478CCDA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7597A.E478CCDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I was kind of thinking in this direction too. Doesn't this however assume that middleboxes notify the endpoints in some way that it understands the first offer/answer.=20 Ingemar ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: den 25 februari 2007 18:33 To: Dan Wing Cc: Ingemar Johansson S (LU/EAB); 'mmusic' Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document(-03) =09 =09 Dan Wing wrote:=20 But there is only this additional delay if the middleboxes don't understand the first offer/answer, exchange, right?=20 Right - and to be clear, it does not add to actual call setup delay. If the second o/a exchange can not be performed until receipt of the 200 Ok (read: no PRACK or preconditions), then there could be a clipping issue. As you note below, the solution to this problem is to upgrade the middle-boxes.=20 =09 -- Flemming=20 =09 =09 The solution seems to be upgrade the software in them so they understand the new SDP Capability Negotiation in the first exchange. =20 =09 The extra o/a is just to provide some accommodation during the transition to everything understanding SDP Cap. Neg. =20 =09 -d =09 =09 =20 -----Original Message----- From: Ingemar Johansson S (LU/EAB)=20 [mailto:ingemar.s.johansson@ericsson.com]=20 Sent: Friday, February 23, 2007 6:01 AM To: Flemming Andreasen Cc: mmusic Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated=20 solution document(-03) =09 Hi =20 I checked out a little and _very_ rougly speaking the call=20 setup time will be increased by ~1.0 second due to the extra=20 offer/answer, this of course depends heaviliy on the=20 achievable compression ratio of SigComp and the bitrate of=20 the signaling radio bearer, the figures assume HSPA access. =20 Ingemar =20 =09 =09 ________________________________ =09 From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: den 22 februari 2007 13:09 To: Ingemar Johansson S (LU/EAB) Cc: mmusic Subject: Re: [MMUSIC] SDP Capability Negotiation:=20 Updated solution document (-03) =09 =09 =09 =09 Ingemar Johansson S (LU/EAB) wrote:=20 =09 Hi =09 If I understand things correctly (snippet below=20 from section 3.5.3), there will be two offer/answers during call=20 setup. The second offer/answer in order to ensure that=20 "intermediaries" understand. This might have some issues regarding call setup=20 times e.g in wireless access where service radio bearers might have a=20 limited bitrate, currently I cannot tell much this might mean in extra call=20 setup time. =09 One possible solution is that it may be=20 possible that the call could be setup already after the first offer/answer ?,=20 this probably assumes that possible radio resource management understands=20 the first offer/answer. =20 =09 That's correct. As far as the offerer and the answerer=20 is concerned, all media stream negotiation is complete after=20 the first exchange. The second exchange is merely done as a=20 courtesy to any intermediaries that may not understand what=20 was actually going on. If those intermediaries do understand=20 it (and have a need to a know in the first place), then the=20 second exchange is effectively a no-op for all parties. =09 -- Flemming=20 =09 =09 =09 Regards Ingemar =09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20 If the offer/answer exchange was succesful,=20 and if the answerer=20 selected one of the potential configurations=20 from the offer as the=20 actual configuration, then the offerer=20 SHOULD perform another=20 offer/answer exchange: The new offer should=20 contain the selected=20 potential configuration as the actual=20 configuration, i.e. with the=20 actual configuration used in the "m=3D" line=20 and any other relevant=20 attributes. This second offer/answer=20 exchange will not modify the=20 session in any way, however it will help=20 intermediaries that look at=20 the SDP, but do not understand or support=20 the capability negotiation=20 extensions, to understand the details of the=20 media stream(s) that=20 were actually negotiated. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20 =09 =20 =09 -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: den 20 februari 2007 04:00 To: mmusic Subject: [MMUSIC] SDP Capability=20 Negotiation: Updated=20 solution document (-03) =09 Greetings =09 I have just submitted an updated=20 solution document as=20 =09 =09 draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which=20 you can retrieve from=20 =09 =09 http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa =09 bility-negotiation-03.txt until it appears in the archives. =09 The list of changes (from Section 9.1): o Base option tag name changed from=20 "v0" to "cap-v0". o Added new section on extension=20 capability attributes o=20 Firmed up offer/answer procedures. o Added security considerations o Added IANA considerations =09 =09 Thanks =09 -- Flemming =09 =09 =09 =09 =09 =09 _______________________________________________ mmusic mailing list mmusic@ietf.org =09 https://www1.ietf.org/mailman/listinfo/mmusic =09 =20 =09 =09 =20 =09 =09 =20 =09 =20 ------_=_NextPart_001_01C7597A.E478CCDA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 

I was kind of thinking in = this=20 direction too. Doesn't this however assume that middleboxes notify the = endpoints=20 in some way that it understands=20 the first offer/answer. 

Ingemar

From: Flemming Andreasen=20 [mailto:fandreas@cisco.com]
Sent: den 25 februari 2007=20 18:33
To: Dan Wing
Cc: Ingemar Johansson S = (LU/EAB);=20 'mmusic'
Subject: Re: [MMUSIC] SDP Capability Negotiation: = Updated=20 solution document(-03)



Dan Wing wrote:=20 
But there is only this additional delay if =
the middleboxes don't
understand the first offer/answer, exchange, right? =
Right =20 - and to be clear, it does not add to actual call setup delay.  = If the=20 second o/a exchange can not be performed until receipt of the 200 Ok = (read: no=20 PRACK or preconditions), then there could be a clipping issue. As you = note=20 below, the solution to this problem is to upgrade the middle-boxes. =

--=20 Flemming 

 The solution
seems to be upgrade the software in them so they understand the
new SDP Capability Negotiation in the first exchange. =20

The extra o/a is just to provide some accommodation during the
transition to everything understanding SDP Cap. Neg. =20

-d


  
-----Original Message-----
From: Ingemar Johansson S (LU/EAB)=20
[mailto:ingemar.s.johanss=
on@ericsson.com]=20
Sent: Friday, February 23, 2007 6:01 AM
To: Flemming Andreasen
Cc: mmusic
Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated=20
solution document(-03)

Hi
=20
I checked out a little and _very_ rougly speaking the call=20
setup time will be increased by ~1.0 second due to the extra=20
offer/answer, this of course depends heaviliy on the=20
achievable compression ratio of SigComp and the bitrate of=20
the signaling radio bearer, the figures assume HSPA access.
=20
Ingemar
=20


________________________________

	From: Flemming Andreasen [mailto:fandreas@cisco.com]=20
	Sent: den 22 februari 2007 13:09
	To: Ingemar Johansson S (LU/EAB)
	Cc: mmusic
	Subject: Re: [MMUSIC] SDP Capability Negotiation:=20
Updated solution document (-03)
=09
=09


	Ingemar Johansson S (LU/EAB) wrote:=20

		Hi
	=09
		If I understand things correctly (snippet below=20
from section 3.5.3),
		there will be two offer/answers during call=20
setup. The second
		offer/answer in order to ensure that=20
"intermediaries" understand. This
		might have some issues regarding call setup=20
times e.g in wireless access
		where service radio bearers might have a=20
limited bitrate, currently I
		cannot tell much this might mean in extra call=20
setup time.
	=09
		One possible solution is that it may be=20
possible that the call could be
		setup already after the first offer/answer ?,=20
this probably assumes that
		possible radio resource management understands=20
the first offer/answer.
		 =20

	That's correct. As far as the offerer and the answerer=20
is concerned, all media stream negotiation is complete after=20
the first exchange. The second exchange is merely done as a=20
courtesy to any intermediaries that may not understand what=20
was actually going on. If those intermediaries do understand=20
it (and have a need to a know in the first place), then the=20
second exchange is effectively a no-op for all parties.
=09
	-- Flemming=20
=09
=09

		Regards
		Ingemar
	=09
		=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=20
		   If the offer/answer exchange was succesful,=20
and if the answerer=20
		   selected one of the potential configurations=20
from the offer as the=20
		   actual configuration, then the offerer=20
SHOULD perform another=20
		   offer/answer exchange: The new offer should=20
contain the selected=20
		   potential configuration as the actual=20
configuration, i.e. with the=20
		   actual configuration used in the "m=3D" line=20
and any other relevant=20
		   attributes. This second offer/answer=20
exchange will not modify the=20
		   session in any way, however it will help=20
intermediaries that look at=20
		   the SDP, but do not understand or support=20
the capability negotiation=20
		   extensions, to understand the details of the=20
media stream(s) that=20
		   were actually negotiated. =20
		=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=20
	=09
		 =20

			-----Original Message-----
			From: Flemming Andreasen=20
[mailto:fandreas@cisco.com]=20
			Sent: den 20 februari 2007 04:00
			To: mmusic
			Subject: [MMUSIC] SDP Capability=20
Negotiation: Updated=20
			solution document (-03)
		=09
			Greetings
		=09
			I have just submitted an updated=20
solution document as=20
		=09
draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which=20
			you can retrieve from=20
		=09
h=
ttp://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa
			bility-negotiation-03.txt
			until it appears in the archives.
		=09
			The list of changes (from Section 9.1):
			o Base option tag name changed from=20
"v0" to "cap-v0".
			o Added new section on extension=20
capability attributes o=20
			Firmed up offer/answer procedures.
			o Added security considerations
			o Added IANA considerations
		=09
		=09
			Thanks
		=09
			-- Flemming
		=09
		=09
		=09
		=09
		=09
			_______________________________________________
			mmusic mailing list
			mmusic@ietf.org
			https://www1.ietf.=
org/mailman/listinfo/mmusic
		=09
			   =20

	=09
		 =20
------_=_NextPart_001_01C7597A.E478CCDA-- --===============0475417909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0475417909==-- From mmusic-bounces@ietf.org Mon Feb 26 03:08:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLatw-0007GE-Sw; Mon, 26 Feb 2007 03:08:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLatv-0007Er-Dr for mmusic@ietf.org; Mon, 26 Feb 2007 03:08:03 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLats-0007Py-VE for mmusic@ietf.org; Mon, 26 Feb 2007 03:08:03 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JE20039F99BX4@siemenscomms.co.uk> for mmusic@ietf.org; Mon, 26 Feb 2007 08:07:59 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Feb 2007 08:08:00 +0000 Content-return: allowed Date: Mon, 26 Feb 2007 08:07:58 +0000 From: "Elwell, John" Subject: RE: [MMUSIC] RE: SDP Capability Negotiation To: Flemming Andreasen Message-id: <50B1CBA96870A34799A506B2313F26670B1EBB78@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Francois Audet , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Flemming, See my responses below. John > 4. Section 3.1 - there is no point in listing the > supported or required base - this can be implied simply by > the presence of a=csup / a=creq. > > You could have a rule like that, but what does it then mean > when say "cap-v1" is included in a "a=csup" ? Would "cap-v0" > be supported as well ? I suppose that would be up to the > definition of "cap-v1", but let's say "cap-v1" is not 100% > backwards compatible, how would the offerer then indicate > that it supports both "cap-v0" and "cap-v1" operation ? With > the current definitions, we could have a "creq" attribute > listing "cap-v0", and then a "csup" attribute listing > "cap-v1" - the rules for "v1" could then say that you can > "upgrade" to using "v1" operation. A "v1" compliant endpoint > could do that, whereas a "v0" compliant endpoint would just > continue with the "v0" operation. > > If we infer "v0" support by presence of certain attributes > instead (I'd prefer the "pcfg" attribute since that would > then allow for omitting the "csup" and "creq" attributes in > the best-effort SRTP case today), then we can easily do > something similar, however what about the case where the > offerer supports only "v1" operation ? We would now need to > include a "creq=cap-v1" attribute, but I suppose that's fine: > We don't have to pay the price until (if) v1 actually comes along. > > I'll wait for others to chime in here, since the current > solution was agreed to by the design team, but it seems ok to > me (we still need the option tag but don't have to require > its use in an offer that supports "v0" or other independent > extensions only). [JRE] I don't have a strong opinion - I will go along with the majority. > > > 7. Section 3.1 "Potential configurations are always > preferred over actual configurations..." I find this > confusing, because the example offer to which it refers does > not have an a=acfg attribute. We should use a different term > to express what is indicated by the "regular" transport and > attributes. In fact in lots of places in the document I think > the term "actual configuration" is used with different meanings. > > I don't believe so - can you provides some examples of where > you see such inconsistencies ? The use of the term "actual > configuration" to reference what is in the offerered "m=" > line, etc. is both deliberate and in line with the overall > use of this term (AFAIK), so I would prefer not to have two > different terms here. > > The reason for having the "actual configuration" attribute > ("acfg") is because the answerer may use a different > configuration from the offer than what was actually included > as the actual configuration in the offer, and the offerer > needs to know about that in order to process both the answer > and incoming media correctly. Thus, the "selected > configuration" from the offer is now what the offerer needs > to use as the actual configuration (combined with the answer). > > In any case, I've rephrased the above referenced sentence > slightly to try and make it clearer. [JRE] I will see if the new version solves the problem. > > 14. Do we need to make any statements about > asymmetrical (direction-sensitive) attributes? I am thinking > here of things like a=sendonly and a=rcvonly. If you have an > a=acap:1 a=sendonly line, and this is used by a potential > configuration that gets selected as the actual configuration > by the answerer, then if the answerer promotes the sendonly > attribute to a regular a=sendonly line in the answer, then > this is clearly wrong (but a=rcvonly would be correct). > > Agreed. > > I don't have any practical use cases for using this, so > perhaps we just need to exclude this type of attribute from > use in a=acap lines. > > I'm not following this part - why can direction attributes > not be provided in acap lines ? Conversely, it sounds to me > like you want us to outlaw something that is already > forbidden by the existing o/a procedures (as supplemented by > the procedures here) ? [JRE] Since I do not have any other examples, I guess sendOnly and rcvOnly are the only attributes of concern. I would just like to see a brief mention of the special handling these receive (e.g., an a=acap a=sendOnly in an offer would result in an a=rcvOnly in the answer if a potential configuration in which it occurred is selected as the actual configuration in the answer). > > 15. There are some very long sections in the draft. Is > it not possible to break some of them up into sub-sections so > that specific aspects can be referenced more easily? > > Please let me know of any specific suggestions here (the > current section splits seem natural to me, and, examples > aside, most sections are 2 pages or less, and only two > sections are close to 4 pages long) [JRE] Sections 3.4.1 and 3.5.2 are quite long, but I don't see any way to split these, so I guess I can live with it. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 26 08:55:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLgJS-0004QC-8e; Mon, 26 Feb 2007 08:54:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLgJQ-0004Pw-Dx for mmusic@ietf.org; Mon, 26 Feb 2007 08:54:44 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLgJK-0004Fb-IZ for mmusic@ietf.org; Mon, 26 Feb 2007 08:54:44 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CFC7211CF; Mon, 26 Feb 2007 14:54:38 +0100 (CET) X-AuditID: c1b4fb3e-afed3bb0000007e1-e0-45e2e69eaadb Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F16CF210EA; Mon, 26 Feb 2007 14:54:37 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:54:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt Date: Mon, 26 Feb 2007 14:54:37 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05047C85CB@esealmw109.eemea.ericsson.se> In-Reply-To: <45DF76DA.8030700@avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt Thread-Index: AcdXoU1ky96BqV1sRreQdLfNALTrzgCCvNvA From: "Ingemar Johansson S \(LU/EAB\)" To: "Robert R. Gilman" X-OriginalArrivalTime: 26 Feb 2007 13:54:37.0810 (UTC) FILETIME=[A7856520:01C759AD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi And thanks for the reply, in my opinion alternative 2 below is the most attractive although I must admit that at first glance I did not understand it at all :-), is it possible to have such an example in a future version of draft-ietf-mmusic-sdp-media-capabilities or do you believe that it is too much of a special case ? I am not sure if I am driving a non-issue her, reason why is simply put as you point out below that many codecs have an abundance of possible parameters and in order to offer all permutations can easily produce really large SDP's esp. if the attributes are not mutually exclusive. Using SIP compression there is always a possibility that one don't gain that much by trying to squeeze down the SDP's in this way but this assumes that the compressor is loaded with the correct glossary. So I believe that there are benefits from trying to keep the SDP's reasonably small. Ingemar > -----Original Message----- > From: Robert R. Gilman [mailto:rrg@avaya.com]=20 > Sent: den 24 februari 2007 00:21 > To: Ingemar Johansson S (LU/EAB) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D=20 > ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt >=20 > Ingemar- > Thanks for your comments. Let me try to explain the approach we took. > Our intent was to associate each cfmt attribute with a codec=20 > in a cmed attribute, in just the same way that the fmtp=20 > attribute is associated with a codec (via payload type) in=20 > the media line. We didn't consider a mix-and-match at the=20 > codec level within the pcfg attribute. I'll most likely mess=20 > this up, but I believe the following is equivalent to your=20 > SDP (you didn't seem to use the cmft:5 and cfmt:6 lines in=20 > your description; doing so would cause the following example=20 > to perhaps be even larger): >=20 > a=3Dcreq:1 > a=3Dcmed:1 AMR AMR AMR AMR AMR AMR > a=3Dcmft:1 mode-change-capability=3D1; max-red-220; mode-set=3D0,2,4,7 > a=3Dcfmt:2 mode-change-capability=3D1; max-red=3D220; = mode-set=3D0,3,5,6 > a=3Dcfmt:3 mode-change-capability=3D1; max-red-220;=20 > octet-align=3D1; mode-set=3D0,2,4,7 > a=3Dcfmt:4 mode-change-capability=3D1; max-red=3D220;=20 > octet-align=3D1; mode-set=3D0,3,5,6 > a=3Dcfmt:5 mode-change-capability=3D2; octet-align=3D1; = mode-set=3D0,2,4,7 > a=3Dcfmt:6 mode-change-capability=3D2; octet-align=3D1; = mode-set=3D0,3,5,6 > a=3Dcenc:1 16000/1 > a=3Dcenc:2 8000/1 > a=3Dcenc:3 16000/1 > a=3Dcenc:4 8000/1 > a=3Dcenc:5 16000/1 > a=3Dcenc:6 8000/1 > m=3Daudio 49152 RTP/AVP 97 > a=3Drtpmap:97 AMR/16000/1 > a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > pcfg:1 m=3D1|2 pt=3D1:98,2:99 > pcfg:2 m=3D3|4 pt=3D3:98,4:99 > pcfg:3 m=3D5|6 pt=3D5:98,5:99 >=20 > My version takes about half again as many characters as=20 > yours. There might be a third way to do this as well -=20 > suppose the cfmt and cenc attributes were applicable to=20 > multiple codecs, and multiple lines were applicable to one=20 > codec (equivalent to your assumption). Then we might say=20 > something like: >=20 > a=3Dcreq:1 > a=3Dcmed:1 AMR AMR AMR AMR AMR AMR > a=3Dcenc:1,3,5 16000/1 > a=3Dcenc:2,4,6 8000/1 > a=3Dcfmt:1,2,3,4 mode-change-capability=3D1 > a=3Dcfmt:5,6 mode-change-capability=3D2 > a=3Dcfmt:1,2,3,5 max-red=3D220 > a=3Dcfmt:3,4,5,6 octet-align=3D1 > a=3Dcfmt:???? mode-change-neighbor=3D1 > a=3Dcfmt:???? mode-change-period=3D2 > a=3Dcfmt:1,3,5 mode-set=3D0,2,4,7 > a=3Dcfmt:2,4,6 mode-set=3D0,3,5,6 > m=3Daudio 49152 RTP/AVP 97 > a=3Drtpmap:97 AMR/16000/1 > a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > pcfg:1 m=3D1|2 pt=3D1:98,2:99 > pcfg:2 m=3D3|4 pt=3D3:98,4:99 > pcfg:3 m=3D5|6 pt=3D5:98,5:99 >=20 > This form takes slightly fewer characters than yours (I left=20 > in the two format parameters you didn't seem to use), but I'm=20 > not sure which one is more useful or readable. Both permit=20 > the SDP generator to code format parameters on multiple=20 > lines, rather than force one long line, but still permit it=20 > if desired. Codecs with lots of formatting parameters and=20 > options are always problematic in capability announcements -=20 > unless you can declare lot of "don't-care" values or use=20 > popular defaults. > It seems almost any method will do if there is little reuse=20 > of parameters. > What do you think? > -Bob > ---------------------------------------------------- > Bob Gilman rrg@avaya.com +1 303 538 3868 >=20 > Ingemar Johansson S (LU/EAB) wrote: > > Hi > >=20 > > Reading the draft I have the following simple question Would it be=20 > > possible, based on all the possible attributes given in=20 > > http://tools.ietf.org/id/draft-ietf-avt-rtp-amr-bis-06.txt > > to formulate an SDP offer like the one below.=20 > > I am not sure that it is possible to combine several cmft's in the=20 > > pcfg in the f=3Dx,y,z.. way that I written below, it is=20 > possible that it=20 > > is sematically incorrect, anyway comments welcome. > > Regards > > Ingemar > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > a=3Dcreq:v1 > > a=3Dcmed:1 AMR > > a=3Dcfmt:1 mode-change-capability=3D1; > > a=3Dcfmt:2 mode-change-capability=3D2; > > a=3Dcfmt:3 max-red=3D220; > > a=3Dcfmt:4 octet-align=3D1; > > a=3Dcfmt:5 mode-change-neighbor=3D1; > > a=3Dcfmt:6 mode-change-period=3D2; > > a=3Dcfmt:7 mode-set=3D0,2,4,7; > > a=3Dcfmt:8 mode-set=3D0,3,5,6; > > a=3Dcenc:1 16000/1 > > a=3Dcenc:2 8000/1 > > m=3Daudio 49152 RTP/AVP 97 > > a=3Drtpmap:97 AMR/16000/1 > > a=3Dfmtp:97 mode-change-capability=3D2; max-red=3D220 > > pcfg:1 m=3D(1 f=3D1,3,7 e=3D1 pt=3D98)|(1 f=3D1,3,8 e=3D2 pt=3D99) > > pcfg:2 m=3D(1 f=3D1,3,4,7 e=3D1 pt=3D98)|(1 f=3D1,3,4,8 e=3D2 = pt=3D99) > > pcfg:3 m=3D(1 f=3D2,4,7 e=3D1 pt=3D98)|(1 f=3D2,4,8 e=3D2 pt=3D99)=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > >=20 > >>-----Original Message----- > >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>Sent: den 21 februari 2007 16:50 > >>To: i-d-announce@ietf.org > >>Cc: mmusic@ietf.org > >>Subject: [MMUSIC] I-D > >>ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts=20 > >>directories. > >>This draft is a work item of the Multiparty Multimedia=20 > Session Control=20 > >>Working Group of the IETF. > >> > >> Title : SDP media capabilities Negotiation > >> Author(s) : F. Andreasen, et al. > >> Filename :=20 > >>draft-ietf-mmusic-sdp-media-capabilities-01.txt > >> Pages : 22 > >> Date : 2007-2-21 > >>=09 > >>Session Description Protocol (SDP) capability negotiation provides a > >> general framework for negotiating capabilities in SDP. The base > >> framework defines only capabilities for negotiating transport > >> protocols and attributes. In this document, we extend the=20 > >>framework > >> by defining media capabilities that can be used to=20 > negotiate media > >> types and their associated parameters. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-medi > >>a-capabilities-01.txt > >> > >>To remove yourself from the I-D Announcement list, send a=20 > message to=20 > >>i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > >>the message. > >>You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > >>to change your subscription settings. > >> > >>Internet-Drafts are also available by anonymous FTP. Login with the=20 > >>username "anonymous" and a password of your e-mail address. After=20 > >>logging in, type "cd internet-drafts" and then "get=20 > >>draft-ietf-mmusic-sdp-media-capabilities-01.txt". > >> > >>A list of Internet-Drafts directories can be found in=20 > >>http://www.ietf.org/shadow.html or=20 > >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE > >>/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-01.txt". > >>=09 > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >>Below is the data which will enable a MIME compliant mail reader=20 > >>implementation to automatically retrieve the ASCII version of the=20 > >>Internet-Draft. > >> > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 26 11:52:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLj4w-0004Th-If; Mon, 26 Feb 2007 11:51:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLj4v-0004Tb-IJ for mmusic@ietf.org; Mon, 26 Feb 2007 11:51:57 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLj4r-00068m-Tz for mmusic@ietf.org; Mon, 26 Feb 2007 11:51:57 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1QGpqPv030839 for ; Mon, 26 Feb 2007 11:51:53 -0500 Received: from [135.9.42.38] ([135.9.42.38]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Feb 2007 09:51:52 -0700 Message-ID: <45E31025.8080701@avaya.com> Date: Mon, 26 Feb 2007 09:51:49 -0700 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ingemar Johansson S (LU/EAB)" Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt References: <026F8EEDAD2C4342A993203088C1FC05047C85CB@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05047C85CB@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 16:51:52.0533 (UTC) FILETIME=[6A4F5850:01C759C6] X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Ingemar- I think it's very likely that we'll adopt one or the other of the schemes we've been discussing. We'll certainly have to incorporate examples in future versions of the media capabilities draft. I think it's important to minimize bloat in the SDP, insofar as possible, without the need to resort to compression. -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Ingemar Johansson S (LU/EAB) wrote: > Hi > > And thanks for the reply, in my opinion alternative 2 below is the most > attractive although I must admit that at first glance I did not > understand it at all :-), is it possible to have such an example in a > future version of draft-ietf-mmusic-sdp-media-capabilities or do you > believe that it is too much of a special case ? > > I am not sure if I am driving a non-issue her, reason why is simply put > as you point out below that many codecs have an abundance of possible > parameters and in order to offer all permutations can easily produce > really large SDP's esp. if the attributes are not mutually exclusive. > > Using SIP compression there is always a possibility that one don't gain > that much by trying to squeeze down the SDP's in this way but this > assumes that the compressor is loaded with the correct glossary. So I > believe that there are benefits from trying to keep the SDP's reasonably > small. > > Ingemar > > >>-----Original Message----- >>From: Robert R. Gilman [mailto:rrg@avaya.com] >>Sent: den 24 februari 2007 00:21 >>To: Ingemar Johansson S (LU/EAB) >>Cc: mmusic@ietf.org >>Subject: Re: [MMUSIC] I-D >>ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt >> >>Ingemar- >>Thanks for your comments. Let me try to explain the approach we took. >>Our intent was to associate each cfmt attribute with a codec >>in a cmed attribute, in just the same way that the fmtp >>attribute is associated with a codec (via payload type) in >>the media line. We didn't consider a mix-and-match at the >>codec level within the pcfg attribute. I'll most likely mess >>this up, but I believe the following is equivalent to your >>SDP (you didn't seem to use the cmft:5 and cfmt:6 lines in >>your description; doing so would cause the following example >>to perhaps be even larger): >> >>a=creq:1 >>a=cmed:1 AMR AMR AMR AMR AMR AMR >>a=cmft:1 mode-change-capability=1; max-red-220; mode-set=0,2,4,7 >>a=cfmt:2 mode-change-capability=1; max-red=220; mode-set=0,3,5,6 >>a=cfmt:3 mode-change-capability=1; max-red-220; >>octet-align=1; mode-set=0,2,4,7 >>a=cfmt:4 mode-change-capability=1; max-red=220; >>octet-align=1; mode-set=0,3,5,6 >>a=cfmt:5 mode-change-capability=2; octet-align=1; mode-set=0,2,4,7 >>a=cfmt:6 mode-change-capability=2; octet-align=1; mode-set=0,3,5,6 >>a=cenc:1 16000/1 >>a=cenc:2 8000/1 >>a=cenc:3 16000/1 >>a=cenc:4 8000/1 >>a=cenc:5 16000/1 >>a=cenc:6 8000/1 >>m=audio 49152 RTP/AVP 97 >>a=rtpmap:97 AMR/16000/1 >>a=fmtp:97 mode-change-capability=2; max-red=220 >>pcfg:1 m=1|2 pt=1:98,2:99 >>pcfg:2 m=3|4 pt=3:98,4:99 >>pcfg:3 m=5|6 pt=5:98,5:99 >> >>My version takes about half again as many characters as >>yours. There might be a third way to do this as well - >>suppose the cfmt and cenc attributes were applicable to >>multiple codecs, and multiple lines were applicable to one >>codec (equivalent to your assumption). Then we might say >>something like: >> >>a=creq:1 >>a=cmed:1 AMR AMR AMR AMR AMR AMR >>a=cenc:1,3,5 16000/1 >>a=cenc:2,4,6 8000/1 >>a=cfmt:1,2,3,4 mode-change-capability=1 >>a=cfmt:5,6 mode-change-capability=2 >>a=cfmt:1,2,3,5 max-red=220 >>a=cfmt:3,4,5,6 octet-align=1 >>a=cfmt:???? mode-change-neighbor=1 >>a=cfmt:???? mode-change-period=2 >>a=cfmt:1,3,5 mode-set=0,2,4,7 >>a=cfmt:2,4,6 mode-set=0,3,5,6 >>m=audio 49152 RTP/AVP 97 >>a=rtpmap:97 AMR/16000/1 >>a=fmtp:97 mode-change-capability=2; max-red=220 >>pcfg:1 m=1|2 pt=1:98,2:99 >>pcfg:2 m=3|4 pt=3:98,4:99 >>pcfg:3 m=5|6 pt=5:98,5:99 >> >>This form takes slightly fewer characters than yours (I left >>in the two format parameters you didn't seem to use), but I'm >>not sure which one is more useful or readable. Both permit >>the SDP generator to code format parameters on multiple >>lines, rather than force one long line, but still permit it >>if desired. Codecs with lots of formatting parameters and >>options are always problematic in capability announcements - >>unless you can declare lot of "don't-care" values or use >>popular defaults. >>It seems almost any method will do if there is little reuse >>of parameters. >>What do you think? >>-Bob >>---------------------------------------------------- >>Bob Gilman rrg@avaya.com +1 303 538 3868 >> >>Ingemar Johansson S (LU/EAB) wrote: >> >>>Hi >>> >>>Reading the draft I have the following simple question Would it be >>>possible, based on all the possible attributes given in >>>http://tools.ietf.org/id/draft-ietf-avt-rtp-amr-bis-06.txt >>>to formulate an SDP offer like the one below. >>>I am not sure that it is possible to combine several cmft's in the >>>pcfg in the f=x,y,z.. way that I written below, it is >> >>possible that it >> >>>is sematically incorrect, anyway comments welcome. >>>Regards >>>Ingemar >>>======================== >>>a=creq:v1 >>>a=cmed:1 AMR >>>a=cfmt:1 mode-change-capability=1; >>>a=cfmt:2 mode-change-capability=2; >>>a=cfmt:3 max-red=220; >>>a=cfmt:4 octet-align=1; >>>a=cfmt:5 mode-change-neighbor=1; >>>a=cfmt:6 mode-change-period=2; >>>a=cfmt:7 mode-set=0,2,4,7; >>>a=cfmt:8 mode-set=0,3,5,6; >>>a=cenc:1 16000/1 >>>a=cenc:2 8000/1 >>>m=audio 49152 RTP/AVP 97 >>>a=rtpmap:97 AMR/16000/1 >>>a=fmtp:97 mode-change-capability=2; max-red=220 >>>pcfg:1 m=(1 f=1,3,7 e=1 pt=98)|(1 f=1,3,8 e=2 pt=99) >>>pcfg:2 m=(1 f=1,3,4,7 e=1 pt=98)|(1 f=1,3,4,8 e=2 pt=99) >>>pcfg:3 m=(1 f=2,4,7 e=1 pt=98)|(1 f=2,4,8 e=2 pt=99) >>>======================== >>> >>> >>> >>>>-----Original Message----- >>>>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>>Sent: den 21 februari 2007 16:50 >>>>To: i-d-announce@ietf.org >>>>Cc: mmusic@ietf.org >>>>Subject: [MMUSIC] I-D >>>>ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.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 : SDP media capabilities Negotiation >>>> Author(s) : F. Andreasen, et al. >>>> Filename : >>>>draft-ietf-mmusic-sdp-media-capabilities-01.txt >>>> Pages : 22 >>>> Date : 2007-2-21 >>>> >>>>Session Description Protocol (SDP) capability negotiation provides a >>>> general framework for negotiating capabilities in SDP. The base >>>> framework defines only capabilities for negotiating transport >>>> protocols and attributes. In this document, we extend the >>>>framework >>>> by defining media capabilities that can be used to >> >>negotiate media >> >>>> types and their associated parameters. >>>> >>>>A URL for this Internet-Draft is: >>>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-medi >>>>a-capabilities-01.txt >>>> >>>>To remove yourself from the I-D Announcement list, send a >> >>message to >> >>>>i-d-announce-request@ietf.org with the word unsubscribe in >> >>the body of >> >>>>the message. >>>>You can also visit >> >>https://www1.ietf.org/mailman/listinfo/I-D-announce >> >>>>to change your subscription settings. >>>> >>>>Internet-Drafts are also available by anonymous FTP. Login with the >>>>username "anonymous" and a password of your e-mail address. After >>>>logging in, type "cd internet-drafts" and then "get >>>>draft-ietf-mmusic-sdp-media-capabilities-01.txt". >>>> >>>>A list of Internet-Drafts directories can be found in >>>>http://www.ietf.org/shadow.html or >>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>>Internet-Drafts can also be obtained by e-mail. >>>> >>>>Send a message to: >>>> mailserv@ietf.org. >>>>In the body type: >>>> "FILE >>>>/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-01.txt". >>>> >>>>NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant >> >>mail readers >> >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>>Below is the data which will enable a MIME compliant mail reader >>>>implementation to automatically retrieve the ASCII version of the >>>>Internet-Draft. >>>> >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >> >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Feb 26 14:19:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlNV-0000mh-1x; Mon, 26 Feb 2007 14:19:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlNU-0000mb-BZ for mmusic@ietf.org; Mon, 26 Feb 2007 14:19:16 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLlNT-0008IF-2F for mmusic@ietf.org; Mon, 26 Feb 2007 14:19:16 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 26 Feb 2007 11:19:15 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="467141286:sNHT44477988" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1QJJEjt004158; Mon, 26 Feb 2007 11:19:14 -0800 Received: from dwingwxp ([128.107.114.231]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1QJJDnF005362; Mon, 26 Feb 2007 11:19:13 -0800 (PST) From: "Dan Wing" To: "'Ingemar Johansson S \(LU/EAB\)'" , "'Flemming Andreasen'" Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated solution document(-03) Date: Mon, 26 Feb 2007 11:19:13 -0800 Message-ID: <002b01c759db$00332450$e7726b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdZAxApnwgkotsPQKe5rvW6yyYchAAd4wWQABeae/A= In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05047C7FC6@esealmw109.eemea.ericsson.se> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=354; t=1172517554; x=1173381554; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Update d=20solution=20document(-03) |Sender:=20; bh=mmmYrWZzk4jpYUNqzpiF7nlLH+xvffiR4as5P1hbBy4=; b=K72ZuGIlUohXwTxgGij7q7RZE2VjhKP3Hk4rmodcDemhZibC2YKEk2gkl5aQMPaokvgTKJ3y 5hWNluE+hC13lC8u1oVoDq1lzPZWuFTujhwCQCeVE0DkwCRHDCbOhPgB; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: 'mmusic' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > Hi > > I was kind of thinking in this direction too. Doesn't this > however assume that middleboxes notify the endpoints in some > way that it understands the first offer/answer. For SIP, if all the Via headers show that all intermediary devices were aware of SDP CapNeg, that should provide a way to avoid doing the second O/A. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 27 03:43:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxvF-0003CF-5s; Tue, 27 Feb 2007 03:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxvD-0003Bx-P5 for mmusic@ietf.org; Tue, 27 Feb 2007 03:42:55 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLxvB-0001rF-GA for mmusic@ietf.org; Tue, 27 Feb 2007 03:42:55 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60658 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HLxv9-0004gY-A2; Tue, 27 Feb 2007 08:42:51 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <709B22AD-55A4-4E6E-8C61-DAE3F578A1E0@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Tue, 27 Feb 2007 08:42:49 +0000 To: mmusic WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: =?ISO-8859-1?Q?J=F6rg_Ott?= , Jean-Francois Mule Subject: [MMUSIC] Agenda items for Prague IETF X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Folks, The MMUSIC working group is scheduled to meet on Monday 19th March 17:40-19:50 at the Prague IETF. Those wanting agenda time during the meeting, please contact the chairs. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 27 09:21:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3CK-0007ra-RO; Tue, 27 Feb 2007 09:20:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3CJ-0007nW-7J for mmusic@ietf.org; Tue, 27 Feb 2007 09:20:55 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM3CG-0004PB-M4 for mmusic@ietf.org; Tue, 27 Feb 2007 09:20:55 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:53451) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HM3CG-0000fk-67 for mmusic@ietf.org; Tue, 27 Feb 2007 14:20:52 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt Date: Tue, 27 Feb 2007 14:20:51 +0000 To: mmusic WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 21 Feb 2007, at 15:50, Internet-Drafts@ietf.org wrote: > 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 : SDP media capabilities Negotiation > Author(s) : F. Andreasen, et al. > Filename : draft-ietf-mmusic-sdp-media-capabilities-01.txt > Pages : 22 > Date : 2007-2-21 > > Session Description Protocol (SDP) capability negotiation provides a > general framework for negotiating capabilities in SDP. The base > framework defines only capabilities for negotiating transport > protocols and attributes. In this document, we extend the > framework > by defining media capabilities that can be used to negotiate media > types and their associated parameters. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media- > capabilities-01.txt My main concern reading this draft is that there is little discussion of the requirements, which makes it difficult to evaluate the solution. I think the introduction should be greatly expanded to include an explicit statement of what is, and is not, in scope. The introduction states that the document updates RFC 3407. I'm not sure that's accurate: surely the base capability negotiation draft obsoletes RFC 3407, and this updates the base draft? In Section 3.2.2 there is an editors note that it might be better to combine the a=cmed: and a=cenc: attributes into one, or to add them to the a=pcfg: line. I'm not sure this makes sense: remember that values in an m= line don't necessarily refer to RTP payload formats, and may not have meaningful clock rates or encoding parameters. In Section 3.2.3, what is the rationale for a=cfmt: rather than an a=acap: line with an fmtp attribute inside it? That is, rather than: a=cmed:1 video h263-1998 h263-2000 a=cfmt:1 CIF=4;QCIF=2;F=1;K=1 a=cfmt:2 profile=2;level=2.2 a=pcfg:1 m=1 pt=1:99 a=pcfg:2 m=2 pt=2:100 why not use: a=mcap:1 video 99 100 a=acap:1 rtpmap:99 h263-1998 a=acap:2 fmtp:99 CIF=4;QCIF=2;F=1;K=1 a=acap:3 rtpmap:99 h263-2000 a=acap:4 fmtp:100 profile=2;level=2.2 a=pcfg:1 m=1 a=1,2 a=pcfg:2 m=2 a=3,4 which introduces only a single new attribute (a=mcap: which takes an m= line media type and list of values)? Whether or not this changes, the rationale should be documented in the draft somewhere. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 27 09:52:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3h0-0000gp-Jt; Tue, 27 Feb 2007 09:52:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3gz-0000gh-JP for mmusic@ietf.org; Tue, 27 Feb 2007 09:52:37 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM3gw-00084y-Uu for mmusic@ietf.org; Tue, 27 Feb 2007 09:52:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt Date: Tue, 27 Feb 2007 16:52:28 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C0457C2DF@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt Thread-Index: AcdaetvKf20YNE90Skiab+oaFdW1EwAAfLPA From: "Even, Roni" To: "Colin Perkins" , "mmusic WG" X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Colin, Thanks, see inline Roni > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Tuesday, February 27, 2007 4:21 PM > To: mmusic WG > Subject: Re: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-media-capabilities- > 01.txt >=20 > On 21 Feb 2007, at 15:50, Internet-Drafts@ietf.org wrote: > > 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 : SDP media capabilities Negotiation > > Author(s) : F. Andreasen, et al. > > Filename : draft-ietf-mmusic-sdp-media-capabilities-01.txt > > Pages : 22 > > Date : 2007-2-21 > > > > Session Description Protocol (SDP) capability negotiation provides a > > general framework for negotiating capabilities in SDP. The base > > framework defines only capabilities for negotiating transport > > protocols and attributes. In this document, we extend the > > framework > > by defining media capabilities that can be used to negotiate media > > types and their associated parameters. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media- > > capabilities-01.txt >=20 > My main concern reading this draft is that there is little discussion > of the requirements, which makes it difficult to evaluate the > solution. I think the introduction should be greatly expanded to > include an explicit statement of what is, and is not, in scope. [RE:] There is draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt that covers the requirements. This draft addresses the both the base and the codec negotiation requirements. I am looking at adding some text for the scope. >=20 > The introduction states that the document updates RFC 3407. I'm not > sure that's accurate: surely the base capability negotiation draft > obsoletes RFC 3407, and this updates the base draft? [RE:] We have it here since RFC3407 addresses the codecs declaration. I think that until we finish this work we do not have a full update to RFC3407.=20 >=20 > In Section 3.2.2 there is an editors note that it might be better to > combine the a=3Dcmed: and a=3Dcenc: attributes into one, or to add = them > to the a=3Dpcfg: line. I'm not sure this makes sense: remember that > values in an m=3D line don't necessarily refer to RTP payload > formats, and may not have meaningful clock rates or encoding parameters. [RE:] We tried to reduce the size of the SDP. I think that Bob suggested to have both cenc with multiple sequence number for each cenc line so it can be used for multiple cmed line codecs. Look at the thread with Ingemar Johansson =20 >=20 > In Section 3.2.3, what is the rationale for a=3Dcfmt: rather than an > a=3Dacap: line with an fmtp attribute inside it? That is, rather than: >=20 > a=3Dcmed:1 video h263-1998 h263-2000 > a=3Dcfmt:1 CIF=3D4;QCIF=3D2;F=3D1;K=3D1 > a=3Dcfmt:2 profile=3D2;level=3D2.2 > a=3Dpcfg:1 m=3D1 pt=3D1:99 > a=3Dpcfg:2 m=3D2 pt=3D2:100 >=20 > why not use: >=20 > a=3Dmcap:1 video 99 100 > a=3Dacap:1 rtpmap:99 h263-1998 > a=3Dacap:2 fmtp:99 CIF=3D4;QCIF=3D2;F=3D1;K=3D1 > a=3Dacap:3 rtpmap:99 h263-2000 > a=3Dacap:4 fmtp:100 profile=3D2;level=3D2.2 > a=3Dpcfg:1 m=3D1 a=3D1,2 > a=3Dpcfg:2 m=3D2 a=3D3,4 >=20 > which introduces only a single new attribute (a=3Dmcap: which takes an > m=3D line media type and list of values)? Whether or not this > changes, the rationale should be documented in the draft somewhere. [RE:] We can go this way also but I think that we will have more flexibility with a separate parameter. As an example look at the Ingemar Johansson email thread, Bob propose to be able to use the cfmt for multiple codecs parameters. In your example you already assign a payload type to the fmtp while we wanted to assign the number only in the pcfg line so we can reuse for multiple streams.=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 27 10:38:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4OS-0002W9-GY; Tue, 27 Feb 2007 10:37:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4OR-0002W0-7Z for mmusic@ietf.org; Tue, 27 Feb 2007 10:37:31 -0500 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4OP-00042o-Qi for mmusic@ietf.org; Tue, 27 Feb 2007 10:37:31 -0500 Received: by an-out-0708.google.com with SMTP id d30so1332622and for ; Tue, 27 Feb 2007 07:37:29 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ssoQWXyhIOwDLfo8z0PVHAHnL8R8bRahNGwitN6a8i7l/Olc+3ov/TRZCCXhYzpWoboBG8TxMa3bYaurL4kFEnwEwg5Yujx9znmG0zJvQ8L58aKdhsjdGfodVvo2c3Jwdxu4coO6jJYeNHfpsuU6vm47j5jHNoEf5Cu6BzOdyYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Za6Vm3l6WROqeqsCDQRr1/+xPd4El0uHtwqGmaruNpuU+tMxbV4RjhQniWDmH/dSO0ajAwhlgAtxIB7C2Pk3+pbd/YfhhyRN12R4vxJos7leDeGFAklpo0wJ6n1Kab8+NUBgC5e8jOy0WE1n8bN8MpEEn4NTtB1xOEfHwh+qsXk= Received: by 10.100.133.9 with SMTP id g9mr5117991and.1172590649521; Tue, 27 Feb 2007 07:37:29 -0800 (PST) Received: by 10.100.194.13 with HTTP; Tue, 27 Feb 2007 07:37:29 -0800 (PST) Message-ID: <458913680702270737v43ac3e42t554156abc3d3a37d@mail.gmail.com> Date: Tue, 27 Feb 2007 16:37:29 +0100 From: "Xavier Marjou" To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt In-Reply-To: <45E31025.8080701@avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <026F8EEDAD2C4342A993203088C1FC05047C85CB@esealmw109.eemea.ericsson.se> <45E31025.8080701@avaya.com> X-Google-Sender-Auth: eae81640d72a4e4f X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > We'll certainly have to incorporate examples in future versions > of the media capabilities draft. I agree that examples should be provided either in the draft itself, or in a companion draft similar to RFC4317, as it may be difficult to realize all the usages made possible by these extensions. One example of usage I find important concerns the ptime attibute per media format (eg: ptime of 20 for PCMU and ptime of 30 for g729). With sdp-capability-negotiation-03 and sdp-media-capabilities-00.txt, I understood that it would look like the following lines. (I haven't check with the latest versions) a=creq:v1 a=cmed:1 audio PCMU g729 m=audio 3456 RTP/AVP 0 18 a=capar:1 ptime=20 a=capar:2 ptime=30 a=pcfg:1 m=1 a=1 pt=1:0 a=pcfg:2 m=1 a=2 pt=2:18 Xavier _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Feb 27 14:04:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7br-0006i6-RL; Tue, 27 Feb 2007 14:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7bp-0006fe-NL; Tue, 27 Feb 2007 14:03:33 -0500 Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM7bn-00072W-Ag; Tue, 27 Feb 2007 14:03:33 -0500 Received: from jonathanlmi (ool-44c5ee3a.dyn.optonline.net [68.197.238.58]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JE4002R4Y9U5880@mta3.srv.hcvlny.cv.net>; Tue, 27 Feb 2007 14:03:31 -0500 (EST) Date: Tue, 27 Feb 2007 14:03:28 -0500 From: Jonathan Lennox To: avt@ietf.org, mmusic@ietf.org Message-id: <00d201c75aa1$f7671170$ad01a8c0@jonathanlmi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_9Z/s8S3yGbLdx67nJjNTkA)" Thread-index: Acdaofbv3adEN29SSjO1+ZgRPK2rLg== X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: 'Thomas Schierl' , 'Joerg Ott' Subject: [MMUSIC] Draft on source-specific SDP attributes: draft-lennox-mmusic-sdp-source-attributes-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_9Z/s8S3yGbLdx67nJjNTkA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Joerg Ott, Thomas Schierl, and I have written an Internet-Draft on source-specific SDP attributes, draft-lennox-mmusic-sdp-source-attributes-00, now available from the I-D repository. The draft allows individual RTP sources to be described in SDP session descriptions, generalizing the mechanism used by the draft on RTCP extensions for single-source multicast (draft-ietf-avt-rtcpssm). It was also originally motivated by the desire to support ssrc-multiplexing of H.264 SVC, as originally used by draft-wenger-avt-rtp-svc-02 and draft-schierl-mmusic-layered-codec-01, though the latest revisions of those drafts have dropped support for ssrc-multiplexing for other reasons. Comments are welcome. I'm sending this annoucement to the AVT group as well as MMUSIC, as the draft's mechanisms have non-trivial interactions with RTP collision detection. Please direct followups to only one of the working group mailing lists, depending on the topic being discussed. -- Jonathan Lennox -- Layered Media jonathan@layeredmedia.com --Boundary_(ID_9Z/s8S3yGbLdx67nJjNTkA) Content-type: message/rfc822 Content-disposition: attachment Return-path: Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by spf6-5.us4.outblaze.com (Postfix) with ESMTP id 921FE1070E7 for ; Mon, 26 Feb 2007 21:51:51 +0000 (GMT) Received: from av1-4.us4.outblaze.com (av1-4.us4.outblaze.com [127.0.0.1]) by av1-4.us4.outblaze.com (Postfix) with SMTP id 8E31517C12B for <"jonathan:layeredmedia.com"@register.com.avs.int>; Mon, 26 Feb 2007 21:51:52 +0000 (GMT) Received: from metro-north.cs.columbia.edu (metro-north.cs.columbia.edu [128.59.19.61]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l1QLpm3h003615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Feb 2007 16:51:48 -0500 (EST) Received: (from lennox@localhost) by metro-north.cs.columbia.edu (8.12.10/8.12.10/Submit) id l1QLpa8R017141 for jonathan@layeredmedia.com; Mon, 26 Feb 2007 16:51:36 -0500 (EST) Received: from metro-north.cs.columbia.edu (localhost [127.0.0.1]) by metro-north.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l1QLpaxn017144; Mon, 26 Feb 2007 16:51:44 -0500 (EST) Received: (qmail 6219 invoked by uid 1001); Mon, 26 Feb 2007 21:51:54 +0000 Date: Mon, 26 Feb 2007 15:50:02 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-lennox-mmusic-sdp-source-attributes-00.txt To: i-d-announce@ietf.org Reply-to: internet-drafts@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_Q3ubY9R1oFGlPODsKK5ohw)" Thread-index: AcdZ8FQFYx56SsMpSBK5tScFld1QGw== List-Subscribe: , List-Unsubscribe: , List-Help: This is a multi-part message in MIME format. --Boundary_(ID_Q3ubY9R1oFGlPODsKK5ohw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Source-Specific Media Attributes in the Session Description Protocol (SDP) Author(s) : J. Lennox, et al. Filename : draft-lennox-mmusic-sdp-source-attributes-00.txt Pages : 20 Date : 2007-2-26 The Session Description Protocol provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, identified by their Synchronization Source Identifiers (SSRCs), in SDP, associate attributes with these sources, and express relationships among sources. It also defines a number of source-level attributes which can be used to describe properties of media sources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lennox-mmusic-sdp-source-attribute s-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lennox-mmusic-sdp-source-attributes-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lennox-mmusic-sdp-source-attributes-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_Q3ubY9R1oFGlPODsKK5ohw) Content-type: Message/External-body; name=ATT00173.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT00173.dat Content-Type: text/plain Content-ID: <2007-2-26114252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lennox-mmusic-sdp-source-attributes-00.txt --Boundary_(ID_Q3ubY9R1oFGlPODsKK5ohw) Content-type: Message/External-body; name=draft-lennox-mmusic-sdp-source-attributes-00.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-lennox-mmusic-sdp-source-attributes-00.txt Content-Type: text/plain Content-ID: <2007-2-26114252.I-D@ietf.org> --Boundary_(ID_Q3ubY9R1oFGlPODsKK5ohw) Content-type: text/plain; name=ATT00176.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00176.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_Q3ubY9R1oFGlPODsKK5ohw)-- --Boundary_(ID_9Z/s8S3yGbLdx67nJjNTkA) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --Boundary_(ID_9Z/s8S3yGbLdx67nJjNTkA)-- From mmusic-bounces@ietf.org Tue Feb 27 15:52:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM9IW-000309-9D; Tue, 27 Feb 2007 15:51:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM9Ht-0001zh-8O; Tue, 27 Feb 2007 15:51:05 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HM9Hs-0000U3-Q6; Tue, 27 Feb 2007 15:51:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 0B2451767A; Tue, 27 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HM9Gs-0001eO-P2; Tue, 27 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart 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 : SDP Capability Negotiation Author(s) : F. Andreasen Filename : draft-ietf-mmusic-sdp-capability-negotiation-04.txt Pages : 55 Date : 2007-2-27 The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-capability-negotiation-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-27125702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-capability-negotiation-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-27125702.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Wed Feb 28 07:32:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMNxt-0001p7-9Q; Wed, 28 Feb 2007 07:31:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMNxr-0001p2-MF for mmusic@ietf.org; Wed, 28 Feb 2007 07:31:23 -0500 Received: from gura.nttv6.jp ([2001:218:1:1040::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMNxq-0004bO-4b for mmusic@ietf.org; Wed, 28 Feb 2007 07:31:23 -0500 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [IPv6:2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 271091FE3F for ; Wed, 28 Feb 2007 21:31:20 +0900 (JST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 5CA371296F9 for ; Wed, 28 Feb 2007 21:31:20 +0900 (JST) Message-ID: <45E57619.1090505@nttv6.jp> Date: Wed, 28 Feb 2007 21:31:21 +0900 From: Makoto Saito User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [MMUSIC] draft-saito-mmusic-sdp-ike-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hello everyone, I submitted a new draft for media description for IKE with Dan, http://www.ietf.org/internet-drafts/draft-saito-mmusic-sdp-ike-00.txt I made a presentation about IPsec negotiation in SDP in the Montreal meeting, but that proposal was still immature. And following Dan's proposal at that time, using a certificate fingerprint in SDP (rfc4572) to bootstrap IKE setup, we wrote a new draft that is fairly simple to understand. I'd like to discuss about this mechanism in this list, and hopefully in Prague. Thanks, -- Makoto Saito NTT Communications Corporation _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 28 10:18:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQZT-0001Be-Sd; Wed, 28 Feb 2007 10:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQZR-00013t-Kg for mmusic@ietf.org; Wed, 28 Feb 2007 10:18:21 -0500 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMQZQ-0002Dn-2r for mmusic@ietf.org; Wed, 28 Feb 2007 10:18:21 -0500 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.13.4/8.13.4/ICT) with ESMTP id l1SFHkLF026252; Wed, 28 Feb 2007 16:17:47 +0100 In-Reply-To: <45E57C89.70003@alcatel-lucent.be> To: sip-implementors@cs.columbia.edu, mmusic@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel-lucent.de Date: Wed, 28 Feb 2007 16:17:45 +0100 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/28/2007 16:17:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [MMUSIC] Comparison of SDP variants between RFC 4566 and RFC 2327 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org fyi, I did some analysis in scope of SDP usage at H.248 interfaces: AVD-3020: Comparison of SDP variants between RFC 4566 and RFC 2327 http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/AVD-3020.zip -Albrecht _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 28 11:40:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRpy-00059H-7O; Wed, 28 Feb 2007 11:39:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRpw-00056O-K0 for mmusic@ietf.org; Wed, 28 Feb 2007 11:39:28 -0500 Received: from mxs2.siemens.at ([194.138.12.133] helo=atvies1zrx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMRpi-0003Is-TC for mmusic@ietf.org; Wed, 28 Feb 2007 11:39:28 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by atvies1zrx.siemens.at with ESMTP id l1SGc7ic011016; Wed, 28 Feb 2007 17:38:07 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l1SGd7q5006597; Wed, 28 Feb 2007 17:39:11 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 17:39:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-04.txt Date: Wed, 28 Feb 2007 17:39:09 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-04.txt Thread-Index: AcdQejgKXovylrbsTnSXdcUFvAR+SwAoJkBw References: From: "Stach, Thomas" To: "Flemming Andreasen" X-OriginalArrivalTime: 28 Feb 2007 16:39:11.0016 (UTC) FILETIME=[F93C9280:01C75B56] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070228173807-0AA86BB0-7487DF9E/0-0/0-15 X-purgate-size: 6165/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Fleming, this looks quite mature. Just a nit-picking(?) comment on the last paragraph of 3.5.3.=20 I propose to explicitly clarify details of the second offer/answer cycle. The text in 04 says: "This second offer/answer exchange will not modify the session in any way". However the second offer deviates from the previous one.=20 Now RFC3264 says in section 8, 3rd para: When issuing an offer that modifies the session, the "o=3D" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. ... However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), ... I think its pretty clear that an incremented SDP version number is required for the offer, but the answer could be the same. Nevertheless I'd like to spell it out again in draft. Another small issue is about keying matrial in the SDP. Should it be repeated in the second offer/answer cycle?=20 Well, in case of Sdescription and forking the key(s) from the offer are distributed to multiple targets.=20 This would merit re-keying once the INVITE received a 200OK. Without forking re-keying wouldn't be necessary. The added text could look like: ------------------------------- The second offer/answer cycle MUST be in accordance with RFC3264, this includes e.g. incrementation of the version number in the offer, but not necessarily in the answer. Attribute lines carrying keying material SHOULD repeat the keys from the previous offer, unless re-keying is necessary for e.g. a previously forked SIP INVITE request. ------------------------------- Some nits (from a quick review): page 17 4th para from the bottom last sentence replace "configs" with "configurations". In the examples of 3.5.2.1 I found 4 occurrence of the line "a=3Dtool:foo".=20 Is this intentional? If yes, what does it mean? Regards Thomas > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Wednesday, February 14, 2007 9:50 PM > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC]=20 > I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-02.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Multiparty Multimedia=20 > Session Control Working Group of the IETF. >=20 > Title : SDP Capability Negotiation > Author(s) : F. Andreasen > Filename :=20 > draft-ietf-mmusic-sdp-capability-negotiation-02.txt > Pages : 29 > Date : 2007-2-14 > =09 > The Session Description Protocol (SDP) was intended for describing=20 > multimedia sessions for the purposes of session=20 > announcement, session=20 > invitation, and other forms of multimedia session=20 > initiation. SDP was=20 > not intended to provide capability indication or capability=20 > negotiation, however over the years, SDP has seen=20 > widespread adoption=20 > and as a result it has been gradually extended to provide limited=20 > support for these. SDP and its current extensions however=20 > do not have=20 > the ability to negotiate one or more alternative transport=20 > protocols (e.g. RTP profiles) which makes it particularly=20 > difficult to deploy=20 > new RTP profiles such as secure RTP or RTP with RTCP-based=20 > feedback.=20 > The purpose of this document is to address that and other=20 > real-life=20 > limitations by extending SDP with capability negotiation=20 > parameters=20 > and associated offer/answer procedures to use those=20 > parameters in a=20 > backwards compatible manner. =20 >=20 > The solution provided in this document provides a general SDP=20 > capability negotiation framework. It also defines=20 > specifically how to=20 > provide attributes and transport protocols as capabilities and=20 > negotiate them using the framework. Extensions for other types of=20 > capabilities (e.g. media types and formats) may be=20 > provided in other=20 > documents. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capa bility-negotiation-02.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-mmusic-sdp-capability-negotiation-02.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 28 16:42:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWYU-0004Hb-6n; Wed, 28 Feb 2007 16:41:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWYS-0004HU-KB for mmusic@ietf.org; Wed, 28 Feb 2007 16:41:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMWYQ-0002qy-BO for mmusic@ietf.org; Wed, 28 Feb 2007 16:41:44 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2007 13:41:42 -0800 X-IronPort-AV: i="4.14,232,1170662400"; d="scan'208"; a="43846172:sNHT40003875" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1SLffQS028270; Wed, 28 Feb 2007 13:41:41 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1SLfeho023902; Wed, 28 Feb 2007 13:41:41 -0800 (PST) From: "Dan Wing" To: , , Subject: RE: [MMUSIC] Comparison of SDP variants between RFC 4566 and RFC 2327 Date: Wed, 28 Feb 2007 13:41:40 -0800 Message-ID: <0a2801c75b81$3bd56ca0$70a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdbTACnBmJoBL7ySFW+2bWnUTESagANFe1A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=401; t=1172698901; x=1173562901; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20Comparison=20of=20SDP=20variants=20between =20RFC=204566=20and=20RFC=202327 |Sender:=20; bh=hxuuAX4k3viB3BQ3LNoEoXmGBT6PLLbbTRfWsoJoyT4=; b=kR26vdqnPAKbD5GdEaNRlvV5Sx+Rql6HpBkDBEF20odRteltxBRSKTljnY2DbiAQukM+HdPu oqJtv9WJvO2Ds2UDgput3x+tzH06Pg78CHBJM8kUeNwpMbusJbnTryn5; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > fyi, > I did some analysis in scope of SDP usage at H.248 interfaces: > > AVD-3020: Comparison of SDP variants between RFC 4566 and RFC 2327 > > http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/AVD-3020.zip Very nice analysis. One point regarding "k=" -- I don't believe it was ever used except in closed systems (where both endpoints assumed various SRTP parameters). -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 28 18:11:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMXwk-00015Q-5P; Wed, 28 Feb 2007 18:10:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMXwj-00013n-6E; Wed, 28 Feb 2007 18:10:53 -0500 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMXwh-0007NW-S6; Wed, 28 Feb 2007 18:10:53 -0500 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l1SNAoZZ008652; Wed, 28 Feb 2007 15:10:50 -0800 (PST) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id A4C0C10C73; Wed, 28 Feb 2007 15:10:50 -0800 (PST) X-AuditID: 11807124-a0f56bb0000035e0-a9-45e60bfac6cc Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by relay6.apple.com (Apple SCV relay) with ESMTP id 529DE10C3A; Wed, 28 Feb 2007 15:10:50 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <0a2801c75b81$3bd56ca0$70a36b80@amer.cisco.com> References: <0a2801c75b81$3bd56ca0$70a36b80@amer.cisco.com> Date: Wed, 28 Feb 2007 15:09:50 -0800 To: mmusic@ietf.org From: Dave Singer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: avt@ietf.org Subject: [MMUSIC] linking two streams in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org If I have one stream which carries optional 'repair' data for another stream, and I want to send them on two separate multicast groups, or two separate streams to an RTSP client, how would I indicate that 'this media stream' is the repair data for 'that media stream' in SDP? I guess this is somewhat like scalable coding, in which I would need to say 'this stream' is an enhancement, and builds on 'that stream'. I have no idea how to write a stream reference in SDP, i.e. how to say 'that stream'. The techniques for scalable coding seem to be confined to assigning consecutive port numbers or multicast addresses, neither of which seem to apply when RTSP/SDP is used. Help? -- David Singer Apple Computer/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 28 19:12:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYtL-0000aC-T6; Wed, 28 Feb 2007 19:11:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYt5-0000Lq-JB; Wed, 28 Feb 2007 19:11:11 -0500 Received: from 206-225-85-160.dedicated.abac.net ([206.225.85.160] helo=server.zchannels.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMYsQ-0002Xe-QF; Wed, 28 Feb 2007 19:11:11 -0500 Received: from [192.168.142.102] (rrcs-67-52-150-122.west.biz.rr.com [67.52.150.122]) (authenticated bits=0) by server.zchannels.com (8.13.6/8.13.4) with ESMTP id l21083BM060836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 16:08:07 -0800 (PST) (envelope-from adamli@hyervision.com) Message-ID: <45E619EA.9060907@hyervision.com> Date: Wed, 28 Feb 2007 16:10:18 -0800 From: Adam Li User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dave Singer Subject: Re: [MMUSIC] linking two streams in SDP References: <0a2801c75b81$3bd56ca0$70a36b80@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mmusic@ietf.org, avt@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org David, For forward error correction, I think you can use RFC 4756 (FEC Semantics) with RFC 3388 (Media Line Grouping). There might be similar semantics for scalable coding. Adam Dave Singer wrote: > If I have one stream which carries optional 'repair' data for another > stream, and I want to send them on two separate multicast groups, or > two separate streams to an RTSP client, how would I indicate that > 'this media stream' is the repair data for 'that media stream' in SDP? > > I guess this is somewhat like scalable coding, in which I would need > to say 'this stream' is an enhancement, and builds on 'that stream'. > > I have no idea how to write a stream reference in SDP, i.e. how to say > 'that stream'. The techniques for scalable coding seem to be confined > to assigning consecutive port numbers or multicast addresses, neither > of which seem to apply when RTSP/SDP is used. > > Help? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 28 19:44:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYpI-0004Lg-CT; Wed, 28 Feb 2007 19:07:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYp8-0004DR-63 for mmusic@ietf.org; Wed, 28 Feb 2007 19:07:06 -0500 Received: from warlock.qualcomm.com ([129.46.50.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMYoO-00026v-T2 for mmusic@ietf.org; Wed, 28 Feb 2007 19:07:05 -0500 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by warlock.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2100TZS001127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Feb 2007 16:00:29 -0800 (PST) Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2100QTf021347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Feb 2007 16:00:27 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2100OW1021023; Wed, 28 Feb 2007 16:00:26 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 16:00:24 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] linking two streams in SDP Date: Wed, 28 Feb 2007 16:00:25 -0800 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B0297CF18@NAEX01.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] linking two streams in SDP Thread-Index: AcdbkRmMs2k1t/mKTimxEl10FDKrPwAAfJxQ References: <0a2801c75b81$3bd56ca0$70a36b80@amer.cisco.com> From: "Desineni, Harikishan" To: "Dave Singer" X-OriginalArrivalTime: 01 Mar 2007 00:00:24.0817 (UTC) FILETIME=[9CDA0610:01C75B94] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org May be the SDP signaling similar to that defined in RFC 4588 might help here. A new MIME subtype ('rpr') can be used for repair stream. I copied the example from RFC 4588 (rtx replaced with rpr) v=3D0 o=3Dmascha 2980675221 2980675778 IN IP4 host.example.net c=3DIN IP4 192.0.2.0 a=3Dgroup:FID 1 2 a=3Dgroup:FID 3 4 m=3Daudio 49170 RTP/AVPF 96 a=3Drtpmap:96 AMR/8000 a=3Dfmtp:96 octet-align=3D1 a=3Drtcp-fb:96 nack a=3Dmid:1 m=3Daudio 49172 RTP/AVPF 97 (repair stream) a=3Drtpmap:97 rpr/8000 a=3Dfmtp:97 apt=3D96 a=3Dmid:2 m=3Dvideo 49174 RTP/AVPF 98 a=3Drtpmap:98 MP4V-ES/90000 a=3Drtcp-fb:98 nack a=3Dfmtp:98 = profile-level-id=3D8;config=3D01010000012000884006682C209\ 0A21F a=3Dmid:3 m=3Dvideo 49176 RTP/AVPF 99 (repair stream) a=3Drtpmap:99 rpr /90000 a=3Dfmtp:99 apt=3D98 a=3Dmid:4 The repair stream can be sent over the same UDP port used by the actual stream. m=3Dvideo 49174 RTP/AVPF 98 99 a=3Drtpmap:98 MP4V-ES/90000 a=3Drtpmap:99 rpr/90000 a=3Dfmtp:99 apt=3D98 > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Wednesday, February 28, 2007 3:10 PM > To: mmusic@ietf.org > Cc: avt@ietf.org > Subject: [MMUSIC] linking two streams in SDP >=20 > If I have one stream which carries optional 'repair' data for another > stream, and I want to send them on two separate multicast groups, or > two separate streams to an RTSP client, how would I indicate that > 'this media stream' is the repair data for 'that media stream' in SDP? >=20 > I guess this is somewhat like scalable coding, in which I would need > to say 'this stream' is an enhancement, and builds on 'that stream'. >=20 > I have no idea how to write a stream reference in SDP, i.e. how to > say 'that stream'. The techniques for scalable coding seem to be > confined to assigning consecutive port numbers or multicast > addresses, neither of which seem to apply when RTSP/SDP is used. >=20 > Help? > -- > David Singer > Apple Computer/QuickTime >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Feb 28 22:00:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMbWS-0001Qk-NU; Wed, 28 Feb 2007 22:00:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMbWR-0001Qe-Qw for mmusic@ietf.org; Wed, 28 Feb 2007 21:59:59 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMbWQ-0007kH-7X for mmusic@ietf.org; Wed, 28 Feb 2007 21:59:59 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2007 18:59:55 -0800 X-IronPort-AV: i="4.14,233,1170662400"; d="scan'208"; a="363426689:sNHT54565016" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l212xtVo008005 for ; Wed, 28 Feb 2007 18:59:55 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l212xknJ013750 for ; Wed, 28 Feb 2007 18:59:55 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 21:59:50 -0500 Received: from [192.168.1.104] ([10.86.241.21]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 21:59:50 -0500 Message-ID: <45E641A5.2040409@cisco.com> Date: Wed, 28 Feb 2007 21:59:49 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing References: <06ba01c73c2a$1c8fd630$aaa36b80@amer.cisco.com> In-Reply-To: <06ba01c73c2a$1c8fd630$aaa36b80@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2007 02:59:50.0106 (UTC) FILETIME=[AD76C3A0:01C75BAD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6086; t=1172717995; x=1173581995; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20review=20of=20ICE-13 |Sender:=20; bh=xlgB4+UtNUT2kdNPuez2rX8rLZ8qB/z3TbnyZsl1nZA=; b=R7ubcE9M8qkF2zvsJHSVTrn1vikRj/nBfSFderw1vUQMhElwiuv0L5z4/8x65STuZllt2v+N SffMmzqRrYvlkLKoEZnS3dVWiVU0oNRfwDbUb4USpvBeU1287XIFkjOR; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: 'MMusic' Subject: [MMUSIC] Re: review of ICE-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Sorry for the long delay in responding to this and Ekr's reviews. Responses inline on just the main comments. I'll reply privately to Dan on the nits, unless there is anything that requires discussion, in which case I'll bring it out. Dan Wing wrote: > An impressive document, Jonathan. > The most impressive thing will be to FINISH it. > > Primary comment: > > * After doing a binding discovery, the agent needs to keep those > bindings open until it's sure they're no longer used. Consider the > case of a little old lady from Pasadena who takes 35 seconds to type > in a phone number; if you obtained the binding as soon as she went > offhook, the binding will have timed out by the time the Invite is > sent. Similarly, SIP retransmissions could cause a healthy delay in > the Invite reaching the called party or all of the called parties > (when forking) or the final target (if retargeting). > > I suggest this keepalive should be a STUN Binding Request, so that > if an implementation keeps this binding open for a long time it > is aware of a reassignment of public transport address by the NAT > (due to NAT crashing, new DHCP lease for the NAT, whatever). Yes, that makes sense. I added the following to the end of section 4.1.1: Once server reflexive and relayed candidates are allocated, they MUST be kept alive until ICE processing has completed. For server reflexive candidates learned through the Binding Discovery usage, this MUST be another Binding Request from the Binding Discovery usage. For relayed candidates learned through the Relay Usage, this MUST be a new Allocate request. The Allocate request will also refresh the server reflexive candidate. > > General comments: > > * As Eric said, more headings and lists would be useful; some of these > sections run two pages and the text is dense. OK, I'll need to get specific comments on where it gets bad. > > * I noticed both "lite" and "passive" are used almost interchangably > in the document, with the intention they mean the same thing. It > would be useful to eliminate one of those terms. Oops, bug. Passive should have been completely removed. I removed the stragglers. > > * I found using "L" and "R" to refer to the agents a bit confusing > because it's difficult to say a sentence like "R takes its local > candidate and sends it its remote peer, L". I did notice some of > the examples use A and B, and others use L and R. It would be > useful to stick with one unless there is a reason to switch between > A/B and L/R. I liked L and R since it allowed you to visualize. We've been using that for some time now. I agree it should be consistent, though. I've changed to L/R. > > * Run http://tools.ietf.org/tools/idnits/ against the document; > boilerplate is wrong, a few lines exceed the maximum. Will do before submission. > > * In several places different terminology was used which appears to > mean the same thing: > - Triggered / tentative actually they're not the same; in the paragraphs where it is described, the triggered check is called tentative since you need to figure out whether you'll actually do it based on current states. Anyway it was possible to describe this without the word tentative, so I removed it. > - Ignore duplicates / prune / eliminate redundant candidates pruning is different; thats the process of removing PAIRS. Ignore duplicants/eliminate redundant were the same. I consolidated that to eliminate redundant. > - Intermediary / media relay / (and "gateway", when talking about > the SIP option tag in 12.2). intermediary is the most general term. Media relay is a form of an intermediary - a TURN server. Gateway in 12.2 can be eliminated. I substituted that for intermediary. > - Active / in-use This one is really messed up. in-use actually had two different definitions. I've cleaned this up. Now, 'default' refers to the candidates in the m/c-line, a much more natural term for what their role is now. in-use refers to a media stream that has a non-zero port. Active is gone. > - Lite / passive / passive-only Per above, passive and passive-only are gone. > - Callee / answerer (in section 12) These are well defined. I don't see the issue here. > > * Is the plan for TURN, or for ICE, to explain that TURN is only > needed if the two agents are behind NATs that perform Address and > Port Dependent Mapping (previously called "symmetric NAT")? Right > now there isn't a discussion of this in ICE, but it might be useful > to provide guidance on when the 'provider variance' is permissable. I added words on that. It now says: Agents SHOULD obtain relayed candidates and MUST obtain server reflexive candidates. The requirement to obtain relayed candidates is at SHOULD strength to allow for provider variation. Use of relays is expensive, and when ICE is being used, relays will only be required when both endpoints are behind NATs that perform address and port dependent mapping. Consequently, some deployments might consider this use case to be marginal, and elect not to use relays. If they are not used, it is RECOMMENDED that it be implemented and just disabled through configuration, so that it can re-enabled through configuration if conditions change in the future. > > * There isn't a discussion of what happens when a lite implementation > encounters a lite implementation. I assume there aren't any > connectivity checks sent by either side. (Should be added to 5.2) Its at the end of 5.1. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic