From mmusic-bounces@ietf.org Fri Jun 01 02:05:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu0GH-0005pD-Ir; Fri, 01 Jun 2007 02:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu0GG-0005p5-4b for mmusic@ietf.org; Fri, 01 Jun 2007 02:05:20 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu0GE-0006Tc-Js for mmusic@ietf.org; Fri, 01 Jun 2007 02:05:20 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5165A7v016575; Fri, 1 Jun 2007 09:05:11 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 09:05:06 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 09:05:06 +0300 Received: from [172.21.154.97] ([172.21.154.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 09:05:06 +0300 Message-ID: <465FB712.2030505@nsn.com> Date: Fri, 01 Jun 2007 09:05:06 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Joe Stone (joestone)" Subject: Re: [MMUSIC] New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 06:05:06.0344 (UTC) FILETIME=[CD431280:01C7A412] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 Joe: Thanks for your valuable comments. Some more inline discussion. Joe Stone (joestone) wrote: > Hi Miguel, > > [js] Comments in line... > > More seriously now... I didn't want to have a discussion on the exact > semantics on those attributes, I understand that I a summary of a few > words may offer the wrong impression. > > [js] Yes, I'm simply suggesting that we could more accurately paraphrase > rather than take a single sentence out of context. Fine, point taken. > > The idea with that text is to highlight that the same problem has been > discussed in the past elsewhere with different type of solutions. If the > text is offensive, I can remove the references in a future version of > the draft. > > [js] I certainly wouldn't remove the references. These references > contain viable solutions. > > [js] I'd also like to point out the PacketCable Call Management Server > Signaling Specification, > > > http://www.packetcable.com/downloads/specs/PKT-SP-CMSS1.5-I04-070412.pdf > > [js] Section 8.4.10 of this specification deals with SIP-NCS/TGCP SDP > interworking. We could consider this in the (slightly) more general > context of SIP-xGCP SDP interworking where xGCP refers to MGCP and its > variants (including NCS, TGCP, ...). For example, section 8.4.10.1 > deals with the fact that preferred SIP call hold SDP syntax > ("a=sendonly" SDP attribute, IP address "0.0.0.0", ...) is commonly > ignored or rejected by xGCP implementations. I wanted to highlight > section 8.4.10.2 which deals with ptime and mptime SDP interworking. > This section addresses the relationship between the packetization period > *value* of the "a=ptime" SDP attribute and the possible packetization > period *values* of the per media format "a=mptime" SDP attribute > assuming the two co-exist as part of the same media description for > backward compatibility. This issue would need to be addressed with any > per media format packetization period approach. Thanks for the pointer, I think this is good input when we start discussing solutions. > >> I think that you've understated the problem of existing packetization >> period semantics being nothing more than a preference or >> recommendation (as it relates to actually sending based on the > "negotiated" >> packetization period). If we can agree on per media format >> packetization period syntax and semantics, have we really solved the >> problem if the "negotiated" packetization period is nothing more than > a recommendation? > > This is a point for discussion. The text about ptime in RFC 4566 says: > "It should not be necessary to know ptime to decode RTP or vat audio, > and it is intended as a recommendation for the encoding/packetisation of > audio. " > > If you agree with the text, then there is nothing to negotiate. It is > only that the SDP creator should have the means to express: "hey, I > would understand any packetization time you send me for this media > format, but if you happen to be able to use xx ms. packetization time, I > will get better performance, so please, please, please, use that > packetization time.". But at the end of the day, it is up to the RTP > sender to decide the packetization time for that particular media type. > > [js] There's the world of I-Ds and RFCs and then there's reality. Dan > Wing's E-mail points out the reality that some implementations can't > change between codecs on-the-fly. There's a similar reality in that some > implementations can only send and receive using a finite set of > packetization periods (in some cases a single packetization period). I'm > sure that we've all seen cases of one-way audio (or no audio) in which > the two parties failed to agree on a common, bi-directional > packetization period. RFC 3551 suggests, "A receiver SHOULD accept > packets representing between 0 and 200 ms of audio data". The reality is > that not all implementations can accept packets over that entire range. > We can dismiss these implementations as non-compliant or we can > recognize these as real problems in need of a solution. In addition, > intermediary devices which shape or police may depend on a negotiated > packetization period which is more than simply a recommendation. I agree with you: sometimes there are statements in RFCs that are not easy to implement. You just pointed out one. So, I think this is the most important issue we should be discussing. If the packetization time is a plea the solution is much simpler than if it is a negotiation. I acknowledge the implementation report, which we can't just simple obviate. This gives background to further discuss the problem and try to derive requirements. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 01 02:16:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu0RJ-0002ZH-89; Fri, 01 Jun 2007 02:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu0RI-0002ZB-8Z for mmusic@ietf.org; Fri, 01 Jun 2007 02:16:44 -0400 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 1Hu0RG-0001mC-OQ for mmusic@ietf.org; Fri, 01 Jun 2007 02:16:44 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l516GYqE004791; Fri, 1 Jun 2007 09:16:40 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 09:16:33 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 09:16:33 +0300 Received: from [172.21.154.97] ([172.21.154.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 09:16:32 +0300 Message-ID: <465FB9C0.40306@nsn.com> Date: Fri, 01 Jun 2007 09:16:32 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [MMUSIC] New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt References: <465C0342.3010602@nsn.com> <7374777208BDC7449D5620EF9423256704991181@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256704991181@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 06:16:32.0640 (UTC) FILETIME=[66538800:01C7A414] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: mmusic , "Willekens, Marc" 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 Christer. Thanks for pointing out yet another solution. I am not familiar with RFC 3108. We need to consider this solution together with all the other existing solutions. BR, Miguel Christer Holmberg (JO/LMF) wrote: > Hi, > > RFC3108 defines a "vsel" attribute (and also a "onewaySel" attribute), > which allows you to to specify Packet Length and Packet Time per code. > > Now, I know RFC3108 was written for ATM, but I don't think there is > anything ATM specific with these attributes (and, if there is, at least > we should look whether we can use the attributes as base for our work). > > Regards, > > Christer > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: 29. toukokuuta 2007 13:41 >> To: mmusic >> Cc: Willekens, Marc >> Subject: [MMUSIC] New draft: multiple times problem >> description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt >> >> Hi: >> >> We have just submitted a new short draft that describes the >> problem with the lack of multiple packetization times in SDP. >> >> The draft should be soon available in the traditional repositories. >> Until that time, you can fetch a copy from: >> >> http://people.nokia.net/~miguel/drafts/draft-garcia-mmusic-mul >> tiple-ptimes-problem-00.txt >> http://people.nokia.net/~miguel/drafts/draft-garcia-mmusic-mul >> tiple-ptimes-problem-00.html >> >> We are aware that the issue has been discussed in the past, >> without a clear conclusion on whether a problem exists. We >> believe there is an interoperability problem, and thus, we >> are soliciting comments about it. >> At this stage, we are not discussing solutions yet, we rather >> agree first that there is a problem that needs to be solved. >> >> /Miguel >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> Nokia Siemens Networks Espoo, Finland >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 01 09:58:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu7dZ-0000ku-Qi; Fri, 01 Jun 2007 09:57:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu7dY-0000kf-47 for mmusic@ietf.org; Fri, 01 Jun 2007 09:57:52 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu7dV-0004pa-FP for mmusic@ietf.org; Fri, 01 Jun 2007 09:57:52 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:56562) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Hu7dU-0006qa-Im; Fri, 01 Jun 2007 14:57:48 +0100 In-Reply-To: <465FB9C0.40306@nsn.com> References: <465C0342.3010602@nsn.com> <7374777208BDC7449D5620EF9423256704991181@esealmw113.eemea.ericsson.se> <465FB9C0.40306@nsn.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] New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt Date: Fri, 1 Jun 2007 14:57:50 +0100 To: Miguel Garcia X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mmusic , "Christer Holmberg \(JO/LMF\)" 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 It would be helpful, and might reduce duplication of effort, if people involved in defining SDP extensions elsewhere would register those extensions with IANA. Colin On 1 Jun 2007, at 07:16, Miguel Garcia wrote: > Hi Christer. > > Thanks for pointing out yet another solution. I am not familiar > with RFC 3108. We need to consider this solution together with all > the other existing solutions. > > BR, > > Miguel > > > > Christer Holmberg (JO/LMF) wrote: >> Hi, >> RFC3108 defines a "vsel" attribute (and also a "onewaySel" >> attribute), >> which allows you to to specify Packet Length and Packet Time per >> code. Now, I know RFC3108 was written for ATM, but I don't think >> there is >> anything ATM specific with these attributes (and, if there is, at >> least >> we should look whether we can use the attributes as base for our >> work). >> Regards, >> Christer >>> -----Original Message----- >>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] Sent: 29. >>> toukokuuta 2007 13:41 >>> To: mmusic >>> Cc: Willekens, Marc >>> Subject: [MMUSIC] New draft: multiple times problem >>> description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt >>> >>> Hi: >>> >>> We have just submitted a new short draft that describes the >>> problem with the lack of multiple packetization times in SDP. >>> >>> The draft should be soon available in the traditional >>> repositories. Until that time, you can fetch a copy from: >>> >>> http://people.nokia.net/~miguel/drafts/draft-garcia-mmusic-mul >>> tiple-ptimes-problem-00.txt >>> http://people.nokia.net/~miguel/drafts/draft-garcia-mmusic-mul >>> tiple-ptimes-problem-00.html >>> >>> We are aware that the issue has been discussed in the past, >>> without a clear conclusion on whether a problem exists. We >>> believe there is an interoperability problem, and thus, we are >>> soliciting comments about it. At this stage, we are not >>> discussing solutions yet, we rather agree first that there is a >>> problem that needs to be solved. >>> >>> /Miguel >>> -- >>> Miguel A. Garcia tel:+358-50-4804586 >>> Nokia Siemens Networks Espoo, Finland >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, Finland > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 01 13:15:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuAiq-0004kW-Gq; Fri, 01 Jun 2007 13:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuAio-0004h2-A1; Fri, 01 Jun 2007 13:15:30 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuAin-0008Gv-1H; Fri, 01 Jun 2007 13:15:30 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:56988) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HuAig-0007Vf-Ez; Fri, 01 Jun 2007 18:15:22 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 1 Jun 2007 18:15:23 +0100 To: IETF AVT WG , behave@ietf.org, mmusic X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Cullen Jennings , Magnus Westerlund , Xavier Marjou , Roni Even , Tom Taylor , Joerg Ott , Jean-Francois Mule , "Dan Wing \(\(dwing\)\)" Subject: [MMUSIC] Moving draft-marjou-behave-app-rtp-keepalive to AVT 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 There has been some private discussion on adopting the draft on Application Mechanisms for maintaining alive NAT mappings associated with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an AVT working group draft. This has previously been discussed in AVT, BEHAVE and MMUSIC. Opinions on whether this draft should become a working group draft, and on the appropriate home for it, are solicited by 8 June 2007. Colin (as AVT co-chair) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 01 14:09:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBYz-0005qD-V2; Fri, 01 Jun 2007 14:09:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBYx-0005pV-Ae; Fri, 01 Jun 2007 14:09:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuBYx-0006XO-1f; Fri, 01 Jun 2007 14:09:23 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Jun 2007 11:09:22 -0700 X-IronPort-AV: i="4.16,373,1175497200"; d="scan'208"; a="157623593:sNHT46360602" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l51I9M8m025733; Fri, 1 Jun 2007 11:09:22 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l51I9G20023088; Fri, 1 Jun 2007 18:09:16 GMT From: "Dan Wing" To: "'Colin Perkins'" , "'IETF AVT WG'" , , "'mmusic'" Date: Fri, 1 Jun 2007 11:09:16 -0700 Message-ID: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcekcHgB7Z2/vHEaSLOivZMtDF4I4gABfTZQ In-Reply-To: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1760; t=1180721362; x=1181585362; c=relaxed/simple; s=sjdkim3002; 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=20Moving=20draft-marjou-behave-app-rtp-keepalive=20to=2 0AVT |Sender:=20; bh=27wsY7m54nhgtgcQ6ZG99GA7h+ssM7bK44h6cpMNfGU=; b=tw4mAUjhG6RgV9K9h4gq66cbC8jALyBSZ+EXUrkAlqp0weiOOUl7Zdw8G4td11XmyQrg2OvO wj5eQ9tk1howHHa3ac5eaBOgn+ymsnOPhV1oyXM15oBtGOggOUvpA+8D; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'Cullen Jennings' , 'Magnus Westerlund' , 'Xavier Marjou' , 'Roni Even' , 'Tom Taylor' , 'Joerg Ott' , 'Jean-Francois Mule' Subject: [MMUSIC] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT 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 > There has been some private discussion on adopting the draft on > Application Mechanisms for maintaining alive NAT mappings associated > with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an > AVT working group draft. This has previously been discussed in AVT, > BEHAVE and MMUSIC. Opinions on whether this draft should become a > working group draft, and on the appropriate home for it, are > solicited by 8 June 2007. > > Colin (as AVT co-chair) We need a document that consolidates NAT keepalive mechanisms for UDP-based protocols, most notably RTP (and, to a lesser extent, SIP). Currently this is spread in various documents and there is no consolidated guidance to implementtors on the strength or weakness of various approaches. Section 4 of Xavier's document shows the current state of the art -- 7 different keepalive techniques are in various levels of active use. Most of the keepalive techniques apply to RTP, and thus AVT seems the best home. There are a few exceptions which don't fit into AVT, such as the keepalive technique used by SIP Outbound (draft-ietf-sip-outbound), but I don't see the exceptions as significant enough to resist making this an AVT WG item. If we had an "RAIWG" (akin to TSVWG), it might fit best there, but we don't have one. It doesn't quite fit into BEHAVE, as NATs only care to see a UDP packet is occasionally sent to the peer and NATs don't care what sort of UDP packet is sent; however, the receiving peer may very much care if it's a STUN packet, a 0-byte packet, or the 5 other types of packets described in Xavier's document. I support adding a milestone to AVT for keepalives, and adopting that document to meet that milestone. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jun 02 11:43:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuVl0-0000Vi-Lc; Sat, 02 Jun 2007 11:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuVkz-0000Vd-Q3 for mmusic@ietf.org; Sat, 02 Jun 2007 11:43:09 -0400 Received: from neptune.azu.com ([67.15.54.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuVkv-00086v-Gf for mmusic@ietf.org; Sat, 02 Jun 2007 11:43:09 -0400 Received: (qmail 25295 invoked by uid 89); 3 Jun 2007 00:42:57 +0900 Received: from unknown (HELO IBM-T42) (59.143.41.119) by 0 with SMTP; 3 Jun 2007 00:42:57 +0900 Date: Sun, 3 Jun 2007 00:43:01 +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: 4bbdb236f788407ff689fcae8109fe34 Subject: [MMUSIC] [IAT 2007] Deadline Extended: June 16, 2007! 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] Dear Colleague, In response to many requests for an extension, we are pleased to extend the paper submission deadline for IAT 2007 to ** June 16, 2007 **. Submission can be done online at: http://www.cs.sjsu.edu/wi07/iat/ We look forward to receiving your submissions soon. With best regards, Tsau Young (T.Y.) Lin PC chair of WI-IAT'07 ##################################################################### IEEE/WIC/ACM Intelligent Agent Technology 2007 CALL FOR PAPERS ##################################################################### 2007 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT'07) Silicon Valley, USA, November 2-5, 2007 Official: http://www.cs.sjsu.edu/wi07/iat/ Mirror: http://www.maebashi-it.org/wi07/iat/ (to be collocated with WI'07, BIBM'07 and GrC'07) 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, San Jose State University/UC Berkeley, USA # 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, Manager, IBM Almaden Research Center # # IAT-WI Joint Keynote Speakers (Tentative) # # Vinton G. Cerf, Turing Award Winner, # VP and Chief Internet Evangelist, Google # Richard M. Karp, Turing Award Winner, # University of California Berkeley # Anant Jhingran, VP and CTO, IBM Silicon Valley Laboratory # # (More IAT 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. ###################################################################### The 2007 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT'07) will be jointly held with the 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07), the 2007 IEEE International Conference on Bioinformatics 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. IAT 2007 provides a leading international forum to bring together researchers and practitioners from diverse fields, such as computer science, information technology, business, education, human factors, systems engineering, and robotics, to (1) examine the design principles and performance characteristics of various approaches in intelligent agent technology, and (2) increase the cross-fertilization of ideas on the development of autonomous agents and multi-agent systems among different domains. By encouraging idea-sharing and discussions on the underlying logical, cognitive, physical, and sociological foundations as well as the enabling technologies of intelligent agents, IAT 2007 will foster the development of novel paradigms and advanced solutions in agent-based computing. +++++++++++ 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 demo session 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: * Autonomy-Oriented Computing (AOC) - Agent-Based Complex Systems Modeling and Development - Agent-Based Simulation - Autonomy-Oriented Modeling and Computation Methods - Behavioral Self-Organization - Complex Behavior Characterization and Engineering - Emergent Behavior - Hard Computational Problem Solving - Nature-Inspired Paradigms - Self-Organized Criticality - Self-Organized Intelligence - Swarm Intelligence * Autonomous Knowledge and Information Agents - Agent-Based Distributed Data Mining - Agent-Based Knowledge Discovery And Sharing - Autonomous Information Services - Distributed Knowledge Systems - Emergent Natural Law Discovery in Multi-Agent Systems - Evolution of Knowledge Networks - Human-Agent Interaction - Information Filtering Agents - Knowledge Aggregation - Knowledge Discovery - Ontology-Based Information Services * Agent Systems Modeling and Methodology - Agent Interaction Protocols - Cognitive Architectures - Cognitive Modeling of Agents - Emotional Modeling - Fault-Tolerance in Multi-Agent Systems - Formal Framework for Multi-Agent Systems - Information Exchanges in Multi-Agent Systems - Learning and Self-Adaptation in Multi-Agent Systems - Mobile Agent Languages and Protocols - Multi-Agent Autonomic Architectures - Multi-Agent Coordination Techniques - Multi-Agent Planning and Re-Planning - Peer-to-Peer Models for Multi-Agent Systems - Reinforcement Learning - Social Interactions in Multi-Agent Systems - Task-Based Agent Context - Task-Oriented Agents * Distributed Problem Solving - Agent-Based Grid Computing - Agent Networks in Distributed Problem Solving - Collective Group Behavior - Coordination and Cooperation - Distributed Intelligence - Distributed Search - Dynamics of Agent Groups and Populations - Efficiency and Complexity Issues - Market-Based Computing - Problem-Solving in Dynamic Environments * Autonomous Auctions and Negotiation - Agent-Based Marketplaces - Auction Markets - Combinatorial Auctions - Hybrid Negotiation - Integrative Negotiation - Mediating Agents - Pricing Agents - Thin Double Auctions * Applications - Agent-Based Assistants - Agent-Based Virtual Enterprise - Embodied Agents and Agent-Based Systems Applications - Interface Agents - Knowledge and Data Intensive Systems - Perceptive Animated Interfaces - Scalability - Social Simulation - Socially Situated Planning - Software and Pervasive Agents - Tools and Standards - Ubiquitous Systems and E-Technology Agents - Ubiquitous Software Services - Virtual Humans - XML-Based Agent Systems ++++++++++++++++++++++++++++++++++++ On-Line Submissions and Publication ++++++++++++++++++++++++++++++++++++ High-quality papers in all IAT 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/iat06.xml). All submitted papers will be reviewed by the Program Committee on the basis of technical quality, relevance, significance, and clarity. Note that IAT'07 will accept ONLY on-line submissions, containing PDF versions. Please use the Submission Form on the IAT'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 IAT'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 IAT'07 homepage: http://www.cs.sjsu.edu/wi07/iat/. +++++++++++++++++++++++++ IAT'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., only one conference registration covers everything). ---------------------- WI-IAT 2007 Workshops: ---------------------- Title: Educating the Web-Generation (Edu4WebGen 2007) Organisers: Elisabeth Heinemann Email: elisabeth.heinemann@googlemail.com Web page: http://www.effactory.com/Edu4WebGen/ Title: Collective Intelligence on Semantic Web (CISW 2007) Organisers: Geun Sik Jo; Jason J. Jung; Ngoc Thanh Nguyen Email: gsjo@inha.ac.kr; j2jung@intelligent.pe.kr; thanh@pwr.wroc.pl Web page: http://intelligent.pe.kr/CISW07/ Title: New Computing Paradigms for Web Intelligence and Brain Informatics (WImBI 2007) Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter Fensel Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: http://www.maebashi-it.org/wimbi07/WImBI2007.htm Title: Web Personalization and Recommender Systems (WPRS 2007) Organisers: Yue Xu Email: yue.xu@qut.edu.au Web page: http://www.wprs07.fit.qut.edu.au/ Title: Service Composition & SWS Challenge (SerComp & SWS Challenge 2007) Organisers: M. Brian Blake; Dumitru Roman; Charles Petrie Email: blakeb@cs.georgetown.edu; dumitru.roman@deri.org Web page: http://events.deri.at/sercomp2007/ Title: Biomedicine Applications of Web technologies (BMWT 2007) Organisers: Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu Email: chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw; whlu@mail.ncku.edu.tw Web page: http://chunnan.iis.sinica.edu.tw/BMWT2007.html Title: Intelligent Web Interaction (IWI 2007) 1st Organiser: Prof. Seiji YAMADA Email: seiji@nii.ac.jp Web site: http://ymd.ex.nii.ac.jp/ws/iwi/07/ Title: Cyberinfrastucture for e-Science (CyIneS 2007) Organisers: Prof. Vasant Honavar; A/prof. Kei Cheung Email: honavar@cs.iastate.edu; kei.cheung@yale.edu Web page: http://www.cild.iastate.edu/events/CyIneS2007/ Title: Social Media Analysis (SMA 2007) Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu Email: sma@comp.hkbu.edu.hk Web page: http://www.comp.hkbu.edu.hk/~sma/ Title: Web Security, Integrity, Privacy and Trust (WSIPT 2007) Organisers: Dr. Yiuming Cheung, Prof. Michael Chau, and Prof. Yong Zhang Email: ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk; zhangyong076@gmail.com Web page: http://isec.hitsz.edu.cn/wsipt07/ Title: Communication between Human and Artificial Agents (CHAA 2007) Organisers: Christel Kemke Email: ckemke@cs.umanitoba.ca Web page: http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ Title: Rational, Robust, and Secure Negotiations in Multi-Agent Systems (RRS 2007) Organisers: Takayuki Ito Email: ito.takayuki@nitech.ac.jp Web page: http://www-itolab.mta.nitech.ac.jp/RRS2007/ Title: P2P Computing and Autonomous Agents (P2PAA 2007) Organisers: Tarek Helmy, Khaled Ragab Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa Web Page: http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html Title: (Multi-)Agent Systems in E-Business: Concepts, Technologies and Applications (MASeB 2007) Organisers: Costin Badica; Maria Ganzha; Marcin Paprzycki Email: badica_costin@software.ucv.ro; ganzha@euh-e.edu.pl; marcin.parzycki@swps.edu.pl Web page: http://software.ucv.ro/~badica_costin/maseb2007/ Title: Agent & Data Mining Interaction (ADMI 2007) Organisers: Pericles A. Mitkas, Longbing Cao, Vladimir Gorodetsky, Justin Zhan Email: mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page: http://issel.ee.auth.gr/ADMI For more information, please visit the conference website at http://www.maebashi-it.org/wi07/iat/?index=workshop. ++++++++++ Tutorials ++++++++++ IAT'07 also welcomes Tutorial proposals. IAT'07 will include tutorials providing in-depth background on subjects that are of broad interest to the intelligent agent 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: July 22, 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 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 IAT Program Vice Co-chairs * Longbing cao University of Technology Sydney Australia * Joseph A. Giampapa Carnegie Mellon University USA * Maria Gini University of Minnesota USA * Vladimir Gorodetsky St. Petersburg Institute for Informatics and Automation Russia * Alessio Lomuscio Imperial College London UK * Zbigniew Ras University of North Carolina USA * Marius C. Silaghi Florida Institute of Technology USA * Makoto Yokoo Kyushu University Japan WI Program Co-Chairs: * Laura Haas, IBM Almaden Research Center, USA * Janusz Kacprzyk, Polish Academy of Science, Poland * Rajeev Motwani, Stanford University, USA WI Program Vice Co-chairs * Ajith Abraham Yonsei University South Korea * Peter Brusilovsky University of Pittsburgh USA * Ashish Goel Stanford University USA * Ramanathan V. Guha Google USA * Jane Yung-jen Hsu National Taiwan University Taiwan * Ravi Kumar Yahoo! Research USA * Jie Lu University of Technology Sydney Australia * Tsuyoshi Murata Tokyo Institute of Technology Japan * York Sure Institute AIFB, University of Karlsruhe Germany * Pang-Ning Tan Michigan State University USA * Bhavani Thuraisingham University of Texas at Dallas USA * Mohammed Zaki Rensselaer Polytechnic Institute USA 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, York University, Canada * Dieter Fensel, University of Innsbruck/Digital Enterprise Research Institute, Austria * 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 Abbreviation: IAT 2007, IAT2007, IAT'2007, IAT'07, IAT07, IAT 07, IAT-07, IAT-2007 *** 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 Mon Jun 04 04:25:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv7rv-000414-Hw; Mon, 04 Jun 2007 04:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv79t-0005k1-9o; Mon, 04 Jun 2007 03:39:21 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv79r-00067C-GX; Mon, 04 Jun 2007 03:39:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l547cvtY029761; Mon, 4 Jun 2007 10:39:07 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 10:38:53 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 10:38:52 +0300 Received: from [172.21.34.187] (esdhcp034187.research.nokia.com [172.21.34.187]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l547coL1003802; Mon, 4 Jun 2007 10:38:50 +0300 In-Reply-To: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> References: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <273FB34D-25A1-4A12-937B-1AAE5B35F9DA@nokia.com> From: Lars Eggert Date: Mon, 4 Jun 2007 10:38:39 +0300 To: ext Dan Wing X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Jun 2007 07:38:52.0837 (UTC) FILETIME=[66270550:01C7A67B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Mon, 04 Jun 2007 04:24:50 -0400 Cc: Godred Fairhurst , Behave WG , mmusic , Xavier Marjou , Tom Taylor , Joerg Ott , IETF AVT WG , Jean-Francois Mule , Colin Perkins , tsvwg chair Subject: [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT 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="===============2123214440==" Errors-To: mmusic-bounces@ietf.org --===============2123214440== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-31-772056426; protocol="application/pkcs7-signature" --Apple-Mail-31-772056426 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-6-1, at 21:09, ext Dan Wing wrote: > We need a document that consolidates NAT keepalive mechanisms for > UDP-based protocols, most notably RTP (and, to a lesser extent, > SIP). Currently this is spread in various documents and there > is no consolidated guidance to implementtors on the strength > or weakness of various approaches. I'm wondering if it'd make sense to add this guidance as a section in http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines? Lars --Apple-Mail-31-772056426 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MDQwNzM4MzlaMCMGCSqGSIb3DQEJBDEWBBQ3AprJIczkdHUp ni8ajjCJeBImUDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAGyyaVzI2wBbZlEYPdD/0EdWeZlAEAjaelavKYe5hZGBbxm9hroSL ZOkkqUjEwbge+A0fQTTLEr4o1aMAipM8jYdq8jxKzAjc7KEwYliu64EAUCtaRX9sYPK93Juf/ZwX X0i5Oo1m78WjfqMgmJbTC0LRc2urWWB2w1SoYTMACvdm1WE0d00mb7QM5jP4tLbkpawq5bDj8djO EBbP1oqYfDZj+jHS+qc8jGzzNJtQRPBUwK4WQNRSELzsEShAV9fDVxcJ0Rv5SsE+v/hSxtyevVqx 4UF2mqWuer4H4p1s4YJ7ufyKSO+qiwXlcihAe0l4c8CcY0P1zxPYLOPU91ZM5QAAAAAAAA== --Apple-Mail-31-772056426-- --===============2123214440== 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 --===============2123214440==-- From mmusic-bounces@ietf.org Mon Jun 04 12:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFIi-00084L-R2; Mon, 04 Jun 2007 12:21:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFIh-00083N-Aw; Mon, 04 Jun 2007 12:20:59 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFIY-0006xf-LC; Mon, 04 Jun 2007 12:20:51 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id 511EA7D3D2A; Mon, 4 Jun 2007 09:19:57 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id F0215300A9; Mon, 4 Jun 2007 09:20:49 -0700 (PDT) X-AuditID: 11807125-9ef62bb000000801-90-46643be11b81 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by relay7.apple.com (Apple SCV relay) with ESMTP id A0E81300A6; Mon, 4 Jun 2007 09:20:49 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7374777208BDC7449D5620EF9423256704991181@esealmw113.eemea.ericsson.se> <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> References: <465C0342.3010602@nsn.com> <7374777208BDC7449D5620EF9423256704991181@esealmw113.eemea.ericsson.se> <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> Date: Mon, 4 Jun 2007 09:19:15 -0700 To: mmusic , IETF AVT WG From: Dave Singer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Clinton Priddle \(KI/EAB\)" Subject: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed 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 we have a need to group together two media streams, in the style of RFC 3388 but we're unsure whether an existing group type is suitable or not, and if it's not, we'd like to agree on a new one, and document it (presumably in an RFC). What we have is a normal media stream, and a separate 'repair' or 'entry' stream, that can be used when tuning in, or after loss, but is otherwise un-needed. An example might be a video stream with a low I-frame interval (say every 15 seconds), with a repair stream which has only I-frames that are equivalent to the time-parallel non-I frame, at a frequency of say 1 per second. It's not clear to us whether this is "one media flow" in the sense of FID, or not. The example offers AMR and GSM audio, which are alternatives, and DTMF tones along with audio, which are supplementary to each other. Perhaps we fall afoul of this restriction: "An application that encodes the same media using different codecs simultaneously MUST NOT use FID to group those media lines." or this one, for layered encoding: "FID MUST NOT be used to group "m" lines that do not represent the same information." (Though how DTMF tones and their associated audio pass this test is not clear). Nor is it clear that the FEC group of RFC 4756 is right, either. For a start, we may wish to use this new ID in combination with FEC, and secondly this tune-in stream has different characteristics. For example, one can typically ignore all FEC and (as long as there are no errors) decode the stream correctly. Ignoring the tune-in stream entirely may mean that you will never find a tune-in point, making the normal stream useless. So, can we use FID for associating a repair stream with its base (we tag the streams so we know which is which, of course)? p.s. RFC 4756 claims in the IANA section that the FEC group is registered under SDP characteristics, but actually I can find no registry anywhere in IANA of group types. -- David Singer Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 04 15:22:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvI7s-0006Pg-ES; Mon, 04 Jun 2007 15:22:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvI7r-0006Ox-Vo for mmusic@ietf.org; Mon, 04 Jun 2007 15:21:59 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvI7q-0007DA-K0 for mmusic@ietf.org; Mon, 04 Jun 2007 15:21:59 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 15:21:57 -0400 To: "Dan Wing" References: <0a2801c75b81$3bd56ca0$70a36b80@amer.cisco.com> From: Randell Jesup Date: Mon, 04 Jun 2007 15:21:55 -0400 In-Reply-To: <0a2801c75b81$3bd56ca0$70a36b80@amer.cisco.com> (Dan Wing's message of "Wed, 28 Feb 2007 13:41:40 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 04 Jun 2007 19:21:57.0785 (UTC) FILETIME=[9E574090:01C7A6DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de Subject: [MMUSIC] Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org "Dan Wing" writes: >> 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 item that's mentioned obliquely but not commented upon is the change in token, and the impact that has on attribute (a=) names. We've run across a problem talking to a vendor's RFC 2327 implementation, which rejects any invite with a=key-mgmt. Their point-of-view is that dashes in an attribute name violate the BNF in RFC 2327. They suggest using a=keymgmt (which no one else uses, and isn't registered). My commentary: RFC 2327 is internally inconsistent, in that it allows X-* attributes but the BNF given doesn't allow them (alpha-numerics only for attribute names). In this case, the text would seem to override the BNF, at least for X-. The text also says to ignore unknown atributes, but that assumes you've been able to parse the attribute name. RFC 4566 allows '-' (and a lot of other characters) in attribute names. There's no discussion of the compatibility impact of this. RFC 4567 defines a=key-mgmt, with no reference to RFC 2327. RFC 4568 suggests people use "a=keymgt" (referencing RFC 4567), which doesn't actually exist in RFC 4567(!) Houston, we have a problem. :-) So: how do we resolve the disagreements between specs (4567 and 4568 in particular), and why is there no commentary in 4566 or especially 4567 about compatibility with attribute names? And why was a name chosen that might break backwards compatibility? Was this issue known before it became an RFC? And how will this be handled for the next attribute named? Should we suggest people stay away from non-alpha-numerics in attribute names? And what are our options dealing with a *strict* 2327 grammar implementation? They don't expect to support 4566 until the end of 2009, if it doesn't slip.... :-( We could use a "private" attribute as suggested, at least for them, but then interconnections with other networks may be an issue, and that would be a violation (though very minor) of RFC 4566. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 04 16:12:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIuv-0005jK-Bt; Mon, 04 Jun 2007 16:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIut-0005iL-Sr for mmusic@ietf.org; Mon, 04 Jun 2007 16:12:40 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIut-00087P-I5 for mmusic@ietf.org; Mon, 04 Jun 2007 16:12:39 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 16:12:38 -0400 To: "Dan Wing" References: <04be01c7a6e2$c4ce42a0$c2f0200a@amer.cisco.com> From: Randell Jesup Date: Mon, 04 Jun 2007 16:12:37 -0400 In-Reply-To: <04be01c7a6e2$c4ce42a0$c2f0200a@amer.cisco.com> (Dan Wing's message of "Mon, 4 Jun 2007 12:58:44 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 04 Jun 2007 20:12:38.0645 (UTC) FILETIME=[B2D5AA50:01C7A6E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de Subject: [MMUSIC] Re: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org "Dan Wing" writes: >Randell Jesup wrote: >> One item that's mentioned obliquely but not commented upon is >> the change in token, and the impact that has on attribute (a=) names. >> We've run across a problem talking to a vendor's RFC 2327 implementation, >> which rejects any invite with a=key-mgmt. Their point-of-view is that >> dashes in an attribute name violate the BNF in RFC 2327. They suggest >> using a=keymgmt (which no one else uses, and isn't registered). > >Such an implementation would also reject: [ huge list of a= values with dashes removed ] >This vendor needs to reconsider their desire for interoperability. Agreed. >> My commentary: >> RFC 2327 is internally inconsistent, in that it allows X-* >> attributes but the BNF given doesn't allow them (alpha-numerics >> only for attribute names). In this case, the text would seem to >> override the BNF, at least for X-. The text also says to ignore >> unknown atributes, but that assumes you've been able to parse >> the attribute name. >> >> RFC 4566 allows '-' (and a lot of other characters) in >> attribute names. >> There's no discussion of the compatibility impact of this. >> >> RFC 4567 defines a=key-mgmt, with no reference to RFC 2327. RFC 4568 >> suggests people use "a=keymgt" (referencing RFC 4567), which doesn't >> actually exist in RFC 4567(!) >> >> Houston, we have a problem. :-) >> >> So: how do we resolve the disagreements between specs (4567 >> and 4568 in particular), and why is there no commentary in 4566 >> or especially 4567 about compatibility with attribute names? And >> why was a name chosen that might break backwards compatibility? Was >> this issue known before it became an RFC? And how will this be >> handled for the next attribute named? Should we suggest people >> stay away from non-alpha-numerics in attribute names? > >I think it's too late for such encouragement. Sure, but there's still an issue here, or at least something needing clarification: Is RFC 4568 trying to refer to a=key-mgmt when it uses a=keymgt? It seems like RFC 4566 section 10 (Summary of changes since RFC 2327) should have mentioned this issue, and others where complying with 4566 would make you (at least in theory) not interoperable with RFC 2327. All 4566 says about it is: The ABNF grammar in Section 9 has been extensively revised and updated, correcting a number of mistakes and incorporating the RFC 3266 IPv6 extensions. Known inconsistencies between the grammar and the specification text have been resolved. >> And what are our options dealing with a *strict* 2327 grammar >> implementation? They don't expect to support 4566 until the >> end of 2009, if it doesn't slip.... :-( > >Full compliance with RFC4566 isn't necessary to be more liberal >in accepting "-" in an unknown attribute name. Agreed. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 04 16:20:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJ2e-00005Y-6E; Mon, 04 Jun 2007 16:20:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIhb-0001Bf-0s for mmusic@ietf.org; Mon, 04 Jun 2007 15:58:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIhX-0005BT-P5 for mmusic@ietf.org; Mon, 04 Jun 2007 15:58:54 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2007 12:58:49 -0700 X-IronPort-AV: i="4.16,381,1175497200"; d="scan'208"; a="160748841:sNHT66413601" 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 l54JwnVY019058; Mon, 4 Jun 2007 12:58:49 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l54Jwi06013200; Mon, 4 Jun 2007 19:58:48 GMT From: "Dan Wing" To: "'Randell Jesup'" Date: Mon, 4 Jun 2007 12:58:44 -0700 Message-ID: <04be01c7a6e2$c4ce42a0$c2f0200a@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: Acem3akys+hyHcGjRkGF3IMuS77tzgAAc/Og DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5317; t=1180987129; x=1181851129; c=relaxed/simple; s=sjdkim6002; 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=20Problems=20with=20RFC=202327=20vs=20RFC=204566, =20and =20between=204567=20and=204568 |Sender:=20; bh=lUaOoJIrooiKys+jYQ4LNRKTmLQoM0AwA3fGA7KFhRE=; b=bKYXDu5hzWYi8+3/umdkshTDoxZcAuLwxxHTWJn0nBdDkFHXWTfB8gnXelRiP02uS6iaUynV LLE6UVB4ppyfrF3xZh2Diu4F03XyASbt72fu+2L33g9jIUp4SQBP0Qa7; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de Subject: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 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 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Monday, June 04, 2007 12:22 PM > To: Dan Wing > Cc: Albrecht.Schwarz@alcatel-lucent.de; > sip-implementors@cs.columbia.edu; mmusic@ietf.org > Subject: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 > > "Dan Wing" writes: > >> 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 item that's mentioned obliquely but not commented upon is > the change in token, and the impact that has on attribute (a=) names. > We've run across a problem talking to a vendor's RFC 2327 implementation, > which rejects any invite with a=key-mgmt. Their point-of-view is that > dashes in an attribute name violate the BNF in RFC 2327. They suggest > using a=keymgmt (which no one else uses, and isn't registered). Such an implementation would also reject: a=rtcp-xr (RFC3611, standards track) a=phone-context (RFC2848, standards track) a=Q763-nature (RFC2848, standards track) a=Q763-plan (RFC2848, standards track) a=source-filter (RFC4570, standards track) a=rtcp-fb (RFC4585, standards track) Working Group Internet Drafts: a=accept-types (draft-ietf-mmusic-file-transfer-mech) (draft-ietf-simple-message-sessions) (draft-niemi-simple-chat) a=accept-wrapped-types(draft-ietf-mmusic-file-transfer-mech) (draft-niemi-simple-chat) a=file-selector (draft-ietf-mmusic-file-transfer-mech) a=file-disposition (draft-ietf-mmusic-file-transfer-mech) a=file-date (draft-ietf-mmusic-file-transfer-mech) a=file-icon (draft-ietf-mmusic-file-transfer-mech) a=file-range (draft-ietf-mmusic-file-transfer-mech) a=loopback-source (draft-ietf-mmusic-media-loopback) a=loopback-mirror (draft-ietf-mmusic-media-loopback) a=loopback-mode (draft-ietf-mmusic-media-loopback) a=ice-pwd (draft-ietf-mmusic-ice) a=ice-ufrag (draft-ietf-mmusic-ice) a=-m (draft-ietf-mmusic-sdp-capability-negotiation) a=dccp-service-code (draft-ietf-dccp-rtp) Individual Internet Drafts: a=qos-mech-send (draft-polk-mmusic-qos-mechanism-identification) a=qos-mech-recv (draft-polk-mmusic-qos-mechanism-identification) a=flute-tsi (draft-mehta-rmt-flute-sdp) a=flute-ch (draft-mehta-rmt-flute-sdp) a=FEC-declaration (draft-mehta-rmt-flute-sdp) a=FEC-OTI-extension (draft-mehta-rmt-flute-sdp) a=content-desc (draft-mehta-rmt-flute-sdp) a=udp-setup (draft-saito-mmusic-sdp-ike) a=switch-context-id (draft-einarsson-mmusic-rtsp-macuri) a=ssrc-group (draft-lennox-mmusic-sdp-source-attributes) a=floor-control (draft-even-xcon-pnc) a=zrtp-zid (draft-zimmermann-avt-zrtp) a=zrtp-sas (draft-zimmermann-avt-zrtp) This vendor needs to reconsider their desire for interoperability. > My commentary: > RFC 2327 is internally inconsistent, in that it allows X-* > attributes but the BNF given doesn't allow them (alpha-numerics > only for attribute names). In this case, the text would seem to > override the BNF, at least for X-. The text also says to ignore > unknown atributes, but that assumes you've been able to parse > the attribute name. > > RFC 4566 allows '-' (and a lot of other characters) in > attribute names. > There's no discussion of the compatibility impact of this. > > RFC 4567 defines a=key-mgmt, with no reference to RFC 2327. RFC 4568 > suggests people use "a=keymgt" (referencing RFC 4567), which doesn't > actually exist in RFC 4567(!) > > Houston, we have a problem. :-) > > So: how do we resolve the disagreements between specs (4567 > and 4568 in particular), and why is there no commentary in 4566 > or especially 4567 about compatibility with attribute names? And > why was a name chosen that might break backwards compatibility? Was > this issue known before it became an RFC? And how will this be > handled for the next attribute named? Should we suggest people > stay away from non-alpha-numerics in attribute names? I think it's too late for such encouragement. > And what are our options dealing with a *strict* 2327 grammar > implementation? They don't expect to support 4566 until the > end of 2009, if it doesn't slip.... :-( Full compliance with RFC4566 isn't necessary to be more liberal in accepting "-" in an unknown attribute name. > We could use a "private" attribute as suggested, at least for > them, but then interconnections with other networks may be an > issue, and that would be a violation (though very minor) of > RFC 4566. Untenable, as this isn't the only attribute name affected by a strict parser. -d > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged > out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 04 16:31:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJCe-0006tI-L7; Mon, 04 Jun 2007 16:31:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJCd-0006tD-0E for mmusic@ietf.org; Mon, 04 Jun 2007 16:30:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJCb-0002L7-NX for mmusic@ietf.org; Mon, 04 Jun 2007 16:30:58 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2007 13:30:57 -0700 X-IronPort-AV: i="4.16,382,1175497200"; d="scan'208"; a="160765172:sNHT41832072" 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 l54KUv3Y028744; Mon, 4 Jun 2007 13:30:57 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l54KUpV1029850; Mon, 4 Jun 2007 20:30:52 GMT From: "Dan Wing" To: "'Randell Jesup'" Date: Mon, 4 Jun 2007 13:30:50 -0700 Message-ID: <058d01c7a6e7$4105bde0$c2f0200a@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: Acem5LQ9bvbyo/dnRQOClUR+0F/FHwAAXFOA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1303; t=1180989057; x=1181853057; 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=20Problems=20with=20RFC=202327=20vs=20RFC=204566, =20and =20between=204567=20and=204568 |Sender:=20; bh=U8gLBaSI353SnCPqNssSgSUxHGATM8TRnVYymU2IOow=; b=ARRc3uzuz6UqKfAd52d/0qEDY0ZVl0cVgjay/46G6rYOS41vnUHBmHMwqvKMANBAiSLG/w8m p7ZLiTcjNUGQ7ibSRZxgmHVj+n+gPr80Mh0IrQutVlzZplrl/zp6KMrP; 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de Subject: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 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 ... > Sure, but there's still an issue here, or at least something needing > clarification: Is RFC 4568 trying to refer to a=key-mgmt when it uses > a=keymgt? I can only expect that was the intent, yes. This should be noted via http://www.rfc-editor.org/errata.html (which isn't ideal, but it's all we have). Might want to ping the authors first to make sure that was their intent. > It seems like RFC 4566 section 10 (Summary of changes since RFC 2327) > should have mentioned this issue, and others where complying with 4566 > would make you (at least in theory) not interoperable with RFC 2327. > All 4566 says about it is: > > The ABNF grammar in Section 9 has been extensively revised and > updated, correcting a number of mistakes and incorporating the RFC > 3266 IPv6 extensions. Known inconsistencies between the > grammar and > the specification text have been resolved. Without going into a case-by-case analysis of those changes, I dunno if there would be much value in highlighting "-" in attribute names; highlighting it might cause some readers of the errata to assume that was the only change, which could make RFC4566 'compliance' worse (if that was thought by some implementor to be the only substantive change to the grammar). -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 04 16:41:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJMS-0001xB-FU; Mon, 04 Jun 2007 16:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJMQ-0001wO-Ij; Mon, 04 Jun 2007 16:41:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJMQ-00045w-6c; Mon, 04 Jun 2007 16:41:06 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2007 13:41:05 -0700 X-IronPort-AV: i="4.16,382,1175497200"; d="scan'208"; a="160770180:sNHT54685206" 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 l54Kf5Ov005235; Mon, 4 Jun 2007 13:41:05 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l54Kex07029042; Mon, 4 Jun 2007 20:41:00 GMT In-Reply-To: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> References: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DE8B4B0-B579-4FAA-9AB2-82E397AD13F9@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 4 Jun 2007 13:40:11 -0700 To: Dan Wing X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2500; t=1180989665; x=1181853665; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[AVT]=20RE=3A=20Moving=20draft-marjou-behave-app-rtp- keepalive=20to=20AVT |Sender:=20; bh=NWWhTaNLaS5PTFm+5mpf/qMbRp7zk2g0mkob446KcQk=; b=O+5Q1Fa0xI0DzjAAaXIhf8fTWnjMSg+EuwO/2pg9IGm79x09tLz+siD8v1YmGfh+1lcBkCx3 4zBEc8l/s7XVCz1EjPBfvSWnveuYM+jOnFj6EEv6h5AjTC/G70V6oiCY; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'Magnus Westerlund' , behave@ietf.org, 'mmusic' , 'Xavier Marjou' , 'Roni Even' , 'IETF AVT WG' , 'Joerg Ott' , 'Tom Taylor' , 'Jean-Francois Mule' , 'Colin Perkins' Subject: [MMUSIC] Re: [AVT] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT 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 think that the AVT WG has the right people to review and recommend way(s) to do keep alive for RTP flows - so if we are doing this work anywhere, AVT would be my preferred WG to do it in. Now that Behave has published, RFC 4787, I think it is easy for the AVT group to ensure that whatever the recommendation is, it will work with NATs that are compliant with BEHAVE. This helps resolve the issues of making sure that enough NAT people are involved with the discussion. On Jun 1, 2007, at 11:09 AM, Dan Wing wrote: >> There has been some private discussion on adopting the draft on >> Application Mechanisms for maintaining alive NAT mappings associated >> with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an >> AVT working group draft. This has previously been discussed in AVT, >> BEHAVE and MMUSIC. Opinions on whether this draft should become a >> working group draft, and on the appropriate home for it, are >> solicited by 8 June 2007. >> >> Colin (as AVT co-chair) > > We need a document that consolidates NAT keepalive mechanisms for > UDP-based protocols, most notably RTP (and, to a lesser extent, > SIP). Currently this is spread in various documents and there > is no consolidated guidance to implementtors on the strength > or weakness of various approaches. Section 4 of Xavier's > document shows the current state of the art -- 7 different > keepalive techniques are in various levels of active use. > > Most of the keepalive techniques apply to RTP, and thus AVT seems > the best home. There are a few exceptions which don't fit into > AVT, such as the keepalive technique used by SIP Outbound > (draft-ietf-sip-outbound), but I don't see the exceptions as > significant enough to resist making this an AVT WG item. If we > had an "RAIWG" (akin to TSVWG), it might fit best there, but we > don't have one. It doesn't quite fit into BEHAVE, as NATs only > care to see a UDP packet is occasionally sent to the peer and > NATs don't care what sort of UDP packet is sent; however, the > receiving peer may very much care if it's a STUN packet, a > 0-byte packet, or the 5 other types of packets described in > Xavier's document. > > I support adding a milestone to AVT for keepalives, and adopting > that document to meet that milestone. > > -d > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 04 16:55:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJa1-0000jQ-DR; Mon, 04 Jun 2007 16:55:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJa0-0000iK-3J; Mon, 04 Jun 2007 16:55:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJZS-0006AJ-CT; Mon, 04 Jun 2007 16:54:35 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2007 13:54:33 -0700 X-IronPort-AV: i="4.16,382,1175497200"; d="scan'208"; a="160777649:sNHT49214277" 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 l54KsX4t009539; Mon, 4 Jun 2007 13:54:33 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l54KsVV1009178; Mon, 4 Jun 2007 20:54:32 GMT From: "Dan Wing" To: "'Lars Eggert'" Date: Mon, 4 Jun 2007 13:54:29 -0700 Message-ID: <05cf01c7a6ea$8cb552c0$c2f0200a@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: <273FB34D-25A1-4A12-937B-1AAE5B35F9DA@nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceme3lSljjfwKCrSgiInEGwlxLVWAAbigQw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1085; t=1180990473; x=1181854473; 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[BEHAVE]=20RE=3A=20Moving=20draft-marjou-behave-app-r tp-keepalive=20to=20AVT |Sender:=20; bh=v4oCKRhZr00gXsdQY/MtUNXXVDumdNrVvvNytpt7ZdM=; b=boi1Bs5fnaQIZ88Zh7QNPMZYVQeya5lmGY6yOE6MrzgobkTIQ5qze3yKsX90uSuxu4usQMka mQSsbYYpYbLmRoQB+9wWWYkvK0fTwtG3kTVHSdSUAfG9VdHvWfaEw8Ec; 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'Godred Fairhurst' , draft-ford-behave-app@tools.ietf.org, 'Behave WG' , 'mmusic' , 'Xavier Marjou' , 'Tom Taylor' , 'Joerg Ott' , 'IETF AVT WG' , 'Jean-Francois Mule' , 'Colin Perkins' , 'tsvwg chair' Subject: [MMUSIC] RE: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT 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 2007-6-1, at 21:09, ext Dan Wing wrote: > > We need a document that consolidates NAT keepalive mechanisms for > > UDP-based protocols, most notably RTP (and, to a lesser extent, > > SIP). Currently this is spread in various documents and there > > is no consolidated guidance to implementtors on the strength > > or weakness of various approaches. > > I'm wondering if it'd make sense to add this guidance as a > section in > http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines? I agree "send periodic UDP traffic" would be good in that document. REQ-6 of draft-ford-behave-app-05 may provide the beginnings of some useful text (CC'ing the authors of that document). As with all applications on today's Internet, an RTP application needs to be robust and able to deal with whatever is sent to it, so perhaps you're right -- an application- specific keepalive document may well be overly specific and we should, rather, document what any UDP-based application should do to prevent middleboxes (such as NATs) from clobbering a flow. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 04 21:40:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvO1r-00044A-18; Mon, 04 Jun 2007 21:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvO1p-000413-3k for mmusic@ietf.org; Mon, 04 Jun 2007 21:40:09 -0400 Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvO1n-0001km-B1 for mmusic@ietf.org; Mon, 04 Jun 2007 21:40:09 -0400 X-IronPort-AV: E=Sophos;i="4.16,383,1175437800"; d="scan'208";a="138801533" Received: from ppp195-197.lns3.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.195.197]) by ipmail01.adl2.internode.on.net with ESMTP; 05 Jun 2007 11:10:01 +0930 Message-ID: <4664BEF0.4000207@nteczone.com> Date: Tue, 05 Jun 2007 11:40:00 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 References: <058d01c7a6e7$4105bde0$c2f0200a@amer.cisco.com> In-Reply-To: <058d01c7a6e7$4105bde0$c2f0200a@amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de 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, The document Albrecht originally pointed to is now an Appendix to ITU-T H.248.49. This was done to ensure that Albrecht's work was captured. The latest draft can be found at: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip I think Randell's point that the use of "-" in attribute names between RFC2327 and RFC4566 should also be captured in the Appendix. Better that these sorts of issues are documented. Something along the lines of: "I.2.2.1 RFC 4566, “a=” attribute The syntax of RFC2327 does not support the use of “-“ in an attribute name however the syntax of RFC4566 has been updated to support the inclusion of “-“. Therefore the use of attribute names containing “-“ is problematic for RFC2327 implementations however several examples of attribute names containing “-“ were registered prior to the definition of RFC4566. RFC2327 Implementors may consider exceptions when parsing an “a=” where these attribute names containing “-“ are involved. " Another way to lessen the problem would be that the internet drafts using "-" in the attribute name remove "-" from the draft before going RFC and the IANA registration procedures be updated to ensure that "-" isn't used in the future for names. From looking at the IANA registrations the widespread use of "-" seems to be a relatively recent phenomena. I guess those who have implemented the drafts wouldn't be happy though :)..... Regards, Christian Dan Wing wrote: > ... > >> Sure, but there's still an issue here, or at least something needing >> clarification: Is RFC 4568 trying to refer to a=key-mgmt when it uses >> a=keymgt? >> > > I can only expect that was the intent, yes. This should be noted > via http://www.rfc-editor.org/errata.html (which isn't ideal, but it's > all we have). Might want to ping the authors first to make sure that > was their intent. > > >> It seems like RFC 4566 section 10 (Summary of changes since RFC 2327) >> should have mentioned this issue, and others where complying with 4566 >> would make you (at least in theory) not interoperable with RFC 2327. >> All 4566 says about it is: >> >> The ABNF grammar in Section 9 has been extensively revised and >> updated, correcting a number of mistakes and incorporating the RFC >> 3266 IPv6 extensions. Known inconsistencies between the >> grammar and >> the specification text have been resolved. >> > > Without going into a case-by-case analysis of those changes, I dunno > if there would be much value in highlighting "-" in attribute names; > highlighting it might cause some readers of the errata to assume that > was the only change, which could make RFC4566 'compliance' worse (if > that was thought by some implementor to be the only substantive > change to the grammar). > > -d > > _______________________________________________ > 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 Jun 04 22:22:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvOh1-0000aK-Mi; Mon, 04 Jun 2007 22:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvOh0-0000aF-Gn for mmusic@ietf.org; Mon, 04 Jun 2007 22:22:42 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvOgz-0000oT-1i for mmusic@ietf.org; Mon, 04 Jun 2007 22:22:42 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2007 19:22:40 -0700 X-IronPort-AV: i="4.16,383,1175497200"; d="scan'208"; a="160892215:sNHT48324807" 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 l552MeoR025314; Mon, 4 Jun 2007 19:22:40 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l552Mb06015360; Tue, 5 Jun 2007 02:22:37 GMT From: "Dan Wing" To: "'Christian Groves'" Subject: RE: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 Date: Mon, 4 Jun 2007 19:22:36 -0700 Message-ID: <075d01c7a718$63b63e10$c2f0200a@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: <4664BEF0.4000207@nteczone.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcenEnNbCFdoEC0MTUWYOPp8pNBpJgABY9nA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3943; t=1181010160; x=1181874160; c=relaxed/simple; s=sjdkim6002; 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]=20RE=3A=20Problems=20with=20RFC=202327=20vs= 20RFC=204566,=09and=20between=204567=20and=204568 |Sender:=20; bh=dc/7jFcp6kwZ3DYcUpIq3DdTcOTeHUnfqwixMbY9qMY=; b=jS3p5d1IK1o0N40C4NVZVnWKqORn2mrzMKtoKlq9vKLHfBTpyVpextzYpfBrHKUqFUb8+Rsj GuIzREGXL0QkEFEYKdE53hsOVpNeBtHn0yAkmWtQVJYZP2Spi1Y4dgcU; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de 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 agree such issues should be documented. Add a caveat like: Beyond the addition of "-" in attribute names, there are additional grammar differences between RFC2327 and RFC4566; enumerating those changes is left as an exercise for the reader and everything would be covered. -d > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Monday, June 04, 2007 6:40 PM > To: Dan Wing > Cc: 'Randell Jesup'; sip-implementors@cs.columbia.edu; > mmusic@ietf.org; Albrecht.Schwarz@alcatel-lucent.de > Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, > and between 4567 and 4568 > > Hello, > > The document Albrecht originally pointed to is now an > Appendix to ITU-T > H.248.49. This was done to ensure that Albrecht's work was > captured. The > latest draft can be found at: > http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip > > I think Randell's point that the use of "-" in attribute > names between > RFC2327 and RFC4566 should also be captured in the Appendix. > Better that > these sorts of issues are documented. Something along the lines of: > > > "I.2.2.1 RFC 4566, "a=" attribute > > The syntax of RFC2327 does not support the use of "-" in an attribute > name however the syntax of RFC4566 has been updated to support the > inclusion of "-". Therefore the use of attribute names > containing "-" is > problematic for RFC2327 implementations however several examples of > attribute names containing "-" were registered prior to the > definition > of RFC4566. RFC2327 Implementors may consider exceptions when > parsing an > "a=" where these attribute names containing "-" are involved. " > > Another way to lessen the problem would be that the internet drafts > using "-" in the attribute name remove "-" from the draft > before going > RFC and the IANA registration procedures be updated to ensure > that "-" > isn't used in the future for names. From looking at the IANA > registrations the widespread use of "-" seems to be a > relatively recent > phenomena. I guess those who have implemented the drafts wouldn't be > happy though :)..... > > Regards, Christian > > Dan Wing wrote: > > ... > > > >> Sure, but there's still an issue here, or at least > something needing > >> clarification: Is RFC 4568 trying to refer to a=key-mgmt > when it uses > >> a=keymgt? > >> > > > > I can only expect that was the intent, yes. This should be noted > > via http://www.rfc-editor.org/errata.html (which isn't > ideal, but it's > > all we have). Might want to ping the authors first to make > sure that > > was their intent. > > > > > >> It seems like RFC 4566 section 10 (Summary of changes > since RFC 2327) > >> should have mentioned this issue, and others where > complying with 4566 > >> would make you (at least in theory) not interoperable with > RFC 2327. > >> All 4566 says about it is: > >> > >> The ABNF grammar in Section 9 has been extensively revised and > >> updated, correcting a number of mistakes and > incorporating the RFC > >> 3266 IPv6 extensions. Known inconsistencies between the > >> grammar and > >> the specification text have been resolved. > >> > > > > Without going into a case-by-case analysis of those changes, I dunno > > if there would be much value in highlighting "-" in attribute names; > > highlighting it might cause some readers of the errata to > assume that > > was the only change, which could make RFC4566 'compliance' worse (if > > that was thought by some implementor to be the only substantive > > change to the grammar). > > > > -d > > > > _______________________________________________ > > 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 Jun 05 01:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRep-0006UT-J5; Tue, 05 Jun 2007 01:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvReo-0006UN-Fa for mmusic@ietf.org; Tue, 05 Jun 2007 01:32:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvRem-0007HE-7H for mmusic@ietf.org; Tue, 05 Jun 2007 01:32:37 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9BE2420400; Tue, 5 Jun 2007 07:32:35 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-5d-4664f5734356 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6B036203CE; Tue, 5 Jun 2007 07:32:35 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 07:32:35 +0200 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: [Sip-implementors] [MMUSIC] RE: Problems with RFC 2327 vs RFC4566, and between 4567 and 4568 Date: Tue, 5 Jun 2007 07:32:32 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704BCEA7A@esealmw113.eemea.ericsson.se> In-Reply-To: <075d01c7a718$63b63e10$c2f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] [MMUSIC] RE: Problems with RFC 2327 vs RFC4566, and between 4567 and 4568 thread-index: AcenEnNbCFdoEC0MTUWYOPp8pNBpJgABY9nAAAavQ7A= References: <4664BEF0.4000207@nteczone.com> <075d01c7a718$63b63e10$c2f0200a@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , "Christian Groves" X-OriginalArrivalTime: 05 Jun 2007 05:32:35.0256 (UTC) FILETIME=[EBF9AB80:01C7A732] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de 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, Another difference between 2327 and 4566 is that some of the media types = were removed from 4566, based on claims they aren't used anywhere.=20 At least one of them is. But, since that didn't affect the ABNF I guess it shouldn't be a problem = from a parser perspective. Regards, Christer=20 > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu=20 > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf=20 > Of Dan Wing > Sent: 5. kes=E4kuuta 2007 5:23 > To: 'Christian Groves' > Cc: sip-implementors@cs.columbia.edu; mmusic@ietf.org;=20 > Albrecht.Schwarz@alcatel-lucent.de > Subject: Re: [Sip-implementors] [MMUSIC] RE: Problems with=20 > RFC 2327 vs RFC4566, and between 4567 and 4568 >=20 > I agree such issues should be documented. Add a caveat like: >=20 > Beyond the addition of "-" in attribute names, there are > additional grammar differences between RFC2327 and > RFC4566; enumerating those changes is left as an exercise > for the reader >=20 > and everything would be covered. >=20 > -d >=20 >=20 > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > > Sent: Monday, June 04, 2007 6:40 PM > > To: Dan Wing > > Cc: 'Randell Jesup'; sip-implementors@cs.columbia.edu;=20 > > mmusic@ietf.org; Albrecht.Schwarz@alcatel-lucent.de > > Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and=20 > > between 4567 and 4568 > >=20 > > Hello, > >=20 > > The document Albrecht originally pointed to is now an Appendix to=20 > > ITU-T H.248.49. This was done to ensure that Albrecht's work was=20 > > captured. The latest draft can be found at: > > http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip > >=20 > > I think Randell's point that the use of "-" in attribute=20 > names between > > RFC2327 and RFC4566 should also be captured in the Appendix.=20 > > Better that > > these sorts of issues are documented. Something along the lines of: > >=20 > >=20 > > "I.2.2.1 RFC 4566, "a=3D" attribute > >=20 > > The syntax of RFC2327 does not support the use of "-" in an=20 > attribute=20 > > name however the syntax of RFC4566 has been updated to support the=20 > > inclusion of "-". Therefore the use of attribute names=20 > containing "-"=20 > > is problematic for RFC2327 implementations however several=20 > examples of=20 > > attribute names containing "-" were registered prior to the=20 > definition=20 > > of RFC4566. RFC2327 Implementors may consider exceptions=20 > when parsing=20 > > an "a=3D" where these attribute names containing "-" are involved. " > >=20 > > Another way to lessen the problem would be that the internet drafts=20 > > using "-" in the attribute name remove "-" from the draft=20 > before going=20 > > RFC and the IANA registration procedures be updated to=20 > ensure that "-" > > isn't used in the future for names. From looking at the IANA=20 > > registrations the widespread use of "-" seems to be a relatively=20 > > recent phenomena. I guess those who have implemented the drafts=20 > > wouldn't be happy though :)..... > >=20 > > Regards, Christian > >=20 > > Dan Wing wrote: > > > ... > > > =20 > > >> Sure, but there's still an issue here, or at least > > something needing > > >> clarification: Is RFC 4568 trying to refer to a=3Dkey-mgmt > > when it uses > > >> a=3Dkeymgt? > > >> =20 > > > > > > I can only expect that was the intent, yes. This should be noted=20 > > > via http://www.rfc-editor.org/errata.html (which isn't > > ideal, but it's > > > all we have). Might want to ping the authors first to make > > sure that > > > was their intent. > > > > > > =20 > > >> It seems like RFC 4566 section 10 (Summary of changes > > since RFC 2327) > > >> should have mentioned this issue, and others where > > complying with 4566 > > >> would make you (at least in theory) not interoperable with > > RFC 2327. > > >> All 4566 says about it is: > > >> > > >> The ABNF grammar in Section 9 has been extensively revised and > > >> updated, correcting a number of mistakes and > > incorporating the RFC > > >> 3266 IPv6 extensions. Known inconsistencies between the=20 > > >> grammar and > > >> the specification text have been resolved. > > >> =20 > > > > > > Without going into a case-by-case analysis of those=20 > changes, I dunno=20 > > > if there would be much value in highlighting "-" in=20 > attribute names;=20 > > > highlighting it might cause some readers of the errata to > > assume that > > > was the only change, which could make RFC4566=20 > 'compliance' worse (if=20 > > > that was thought by some implementor to be the only substantive=20 > > > change to the grammar). > > > > > > -d > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > =20 > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 03:02:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT4B-0002HO-3Y; Tue, 05 Jun 2007 03:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT49-0002H6-09; Tue, 05 Jun 2007 03:02:53 -0400 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 1HvT48-0002ip-AK; Tue, 05 Jun 2007 03:02:52 -0400 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] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed Date: Tue, 5 Jun 2007 10:03:31 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed Thread-Index: AcemxHiQHUF4zzUiTS2DsZiVU+iS5gAd0gDQ From: "Even, Roni" To: "Dave Singer" , "mmusic" , "IETF AVT WG" X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: "Clinton Priddle \(KI/EAB\)" 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 Dave, For layered encoding there is a proposal for a new grouping attribute in http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx t I looked at RFC3388 and I think that FID is not the answer to your requirement as you mentioned To me it looks like what you are looking for is a way to specify alternate offers. If this is the case I have similar requirements and would be happy to support such work. You also need a way to give semantics to the "repair" stream, this can be done based on the content attribute from RFC 4796 or using a dependency attribute see in Schierl's draft. The mid tag is not enough for the receiver to know what you meant by this offer and which stream is the repair. Here is an example for a solution using a new Alternatives grouping attribute and giving semantics to the repair stream=20 By using the grouping attribute in the offer you can know if the answerer understood the grouping since if he does not than he will send an answer with no a=3Dgroup v=3D0=20 o=3Dbob 280744730 28977631 IN IP4 host.example.com=20 s=3D=20 t=3D0 0=20 a=3Dgroup:ALTS 1 2=20 a=3Dgroup:ALTS 1 3=20 m=3Daudio 6886 RTP/AVP 0=20 c=3DIN IP6 2001:0600::1=20 a=3Dmid:1=20 m=3Dvideo 9000 RTP/AVP 100 c=3DIN IP4 192.0.2.2=20 a=3Drtpmap:100 H263-1998=20 a=3Dmid:2=20 m=3Dvideo 9002 RTP/AVP 101=20 c=3DIN IP4 192.0.2.2=20 a=3Drtpmap:101 H263-1998=20 a=3Dmid:3 a=3Dcontent:repair=3D2 or a=3Ddepend:repair=3D2 Roni Even > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Monday, June 04, 2007 7:19 PM > To: mmusic; IETF AVT WG > Cc: Clinton Priddle (KI/EAB) > Subject: [MMUSIC] questions about grouping media streams in RTP and SDP > (RFC3388 etc), advice needed >=20 > Hi >=20 > we have a need to group together two media streams, in the style of RFC > 3388 but we're unsure whether an > existing group type is suitable or not, and if it's not, we'd like to > agree on a new one, and document it (presumably in an RFC). >=20 > What we have is a normal media stream, and a separate 'repair' or > 'entry' stream, that can be used when tuning in, or after loss, but is > otherwise un-needed. An example might be a video stream with a low > I-frame interval (say every 15 seconds), with a repair stream which has > only I-frames that are equivalent to the time-parallel non-I frame, at a > frequency of say 1 per second. >=20 > It's not clear to us whether this is "one media flow" in the sense of > FID, or not. The example offers AMR and GSM audio, which are > alternatives, and DTMF tones along with audio, which are supplementary > to each other. Perhaps we fall afoul of this restriction: >=20 > "An application that encodes the same media using different codecs > simultaneously MUST NOT use FID to group those media lines." >=20 > or this one, for layered encoding: >=20 > "FID MUST NOT be used to group "m" lines that do not represent the same > information." (Though how DTMF tones and their associated audio pass > this test is not clear). >=20 > Nor is it clear that the FEC group of RFC 4756 is right, either. For a > start, we may wish to use this new ID in combination with FEC, and > secondly this tune-in stream has different characteristics. For > example, one can typically ignore all FEC and (as long as there are no > errors) decode the stream correctly. Ignoring the tune-in stream > entirely may mean that you will never find a tune-in point, making the > normal stream useless. >=20 > So, can we use FID for associating a repair stream with its base (we tag > the streams so we know which is which, of course)? >=20 > p.s. RFC 4756 claims in the IANA section that the FEC group is > registered under SDP characteristics, but actually I can find no > registry anywhere in IANA of group types. >=20 >=20 > -- > David Singer > Apple/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 Tue Jun 05 03:23:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTNV-0004fV-9u; Tue, 05 Jun 2007 03:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTNR-0004es-2s for mmusic@ietf.org; Tue, 05 Jun 2007 03:22:50 -0400 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvTNP-0006U8-PF for mmusic@ietf.org; Tue, 05 Jun 2007 03:22:49 -0400 Received: by an-out-0708.google.com with SMTP id c17so398884anc for ; Tue, 05 Jun 2007 00:22:47 -0700 (PDT) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=bMG5Lu9fS//GLptoDusb74u9/DEhLj55VjjnntwrFpJG76+pZ8OEMiEw50vTxAdsBRi3/QoXRz6ePx10uRTbD+QDH6YJ+3hJlbX090taA2sEQhZiVq+yj6UdSHkRNWVgeRFld2ekEtIkMqzdz53CaM0465RcadFQty4joivSpsY= 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=Jc4RBYyrNwMN77ubFQ7+pPNfGtEy9Zc6d6hjRI0ECyQ5ZnpFrj766D0/Y7zlmgVrn4AVWy5E/hcoTXJxuRtxMFgr5lZ5/dsX9JZV5jYOBR/Gwj4hZpeBvw/0QFMgR/U475LaAgEAM6TGzazBRyCNfj93pbjryu3HzsTZ9zvfQIA= Received: by 10.100.141.13 with SMTP id o13mr3075886and.1181028167370; Tue, 05 Jun 2007 00:22:47 -0700 (PDT) Received: by 10.100.190.17 with HTTP; Tue, 5 Jun 2007 00:22:47 -0700 (PDT) Message-ID: <458913680706050022i6ede971bo748f451356c2ab04@mail.gmail.com> Date: Tue, 5 Jun 2007 09:22:47 +0200 From: "Xavier Marjou" To: "Lars Eggert" In-Reply-To: <273FB34D-25A1-4A12-937B-1AAE5B35F9DA@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> <273FB34D-25A1-4A12-937B-1AAE5B35F9DA@nokia.com> X-Google-Sender-Auth: 8d3e5b3b16cba61d X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Godred Fairhurst , Behave WG , mmusic , Xavier Marjou , Tom Taylor , Joerg Ott , IETF AVT WG , Jean-Francois Mule , ext Dan Wing , Colin Perkins , tsvwg chair Subject: [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT 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 there was a consensus about using a very easy RTP-keepalive mechanism that could even be re-used for other UDP protocols than RTP itslef (eg: an empty UDP packet), I think it could be integrated in the tsvwg-udp-guidelines document. However, there is no consensus on such a mechanism and some of the possible mechanisms really need AVT people expertise. So I would also be in favor of moving the draft to AVT. Xavier On 6/4/07, Lars Eggert wrote: > On 2007-6-1, at 21:09, ext Dan Wing wrote: > > We need a document that consolidates NAT keepalive mechanisms for > > UDP-based protocols, most notably RTP (and, to a lesser extent, > > SIP). Currently this is spread in various documents and there > > is no consolidated guidance to implementtors on the strength > > or weakness of various approaches. > > I'm wondering if it'd make sense to add this guidance as a section in > http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines? > > Lars > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 04:16:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUDd-0005jj-1i; Tue, 05 Jun 2007 04:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUDb-0005ik-Fz for mmusic@ietf.org; Tue, 05 Jun 2007 04:16:43 -0400 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 1HvUAS-0004Zz-PU for mmusic@ietf.org; Tue, 05 Jun 2007 04:13:31 -0400 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] New ID, related to media stream dependencies Date: Tue, 5 Jun 2007 11:13:54 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C049E770D@IsrExch01.israel.polycom.com> In-Reply-To: <052601c73bf9$50c3c050$aaa36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] New ID, related to media stream dependencies Thread-Index: AcE8+q9WSC0EcqjREdWWxAAADv2DOIv9iK3QAACrAzAADco4oBrT9okA From: "Even, Roni" To: "Dan Wing" , "Schmidt, Christian" X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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, The Capability negotiation draft addresses potential configurations and = not real offers. I think that this draft talks about specifying = dependencies in offers. Still the capability negotiation work should = address it. As for this draft, I suggest to look at RFC 3388 and = http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.txt= I think that the example you gave about video and the text subtitles are = handled by the FID attribute in RFC 3388. If you want to add some semantics to the streams then look at the = content attribute in RFC4796 and the layered codecs. Roni Even > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, January 19, 2007 8:41 PM > To: 'Schmidt, Christian' > Cc: 'MMusic' > Subject: RE: [MMUSIC] New ID, related to media stream dependencies >=20 > (removed internet-drafts from CC list.) >=20 > Can draft-ietf-mmusic-sdp-capability-negotiation-00 provide the same > functionality? >=20 > -d >=20 > > -----Original Message----- > > From: Schmidt, Christian [mailto:christian-schmidt@siemens.com] > > Sent: Friday, January 19, 2007 4:04 AM > > To: internet-drafts@ietf.org > > Cc: MMusic; Joerg Ott > > Subject: [MMUSIC] New ID, related to media stream dependencies > > > > Dear editor, > > > > we would like to submit a new Internet Draft related to work in the > > MMUSIC Working Group (although it is not an official product > > of the WG). > > > > <> > > > > Abstract: > > 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. > > Together with Offer/Answer model it defines a mechanism, how two > > entities can reach a common view of a multimedia session between > > them. > > > > In certain cases, there are dependencies between media streams, for > > example a text stream for subtitling make sense only together with a > > video stream. To avoid senseless connections, the SDP mechanism can > > be extended with a new Session Description Protocol (SDP) = media-level > > attribute: "dependency". The "dependency" attribute allows the > > offerer to define dependencies of media streams. The updated offer/ > > answer mechanism used with new "dependency" attribute can be used > > furthermore, that in a multi-party SIP session all participants = share > > at least one common media type. > > > > Mit freundlichen Gr=FC=DFen > > Christian Schmidt > > > > Siemens Networks GmbH & Co. KG > > St.-Martin-Str. 76 > > 81541 M=FCnchen, Germany > > Tel.: +49 89 636-75192 > > Fax: +49 89 636-75577 > > christian-schmidt@siemens.com > > > > Siemens Networks GmbH & Co. KG > > Gesch=E4ftsf=FChrer: Joachim Malterer, Roland Meinzer, Christian > > Unterberger > > Sitz der Gesellschaft: M=FCnchen > > Registergericht: M=FCnchen, HRA 88537 > > WEEE-Reg.-Nr. DE 52984304 > > Pers=F6nlich haftende Gesellschafterin: Siemens Networks > > Management GmbH > > Sitz der Gesellschaft: M=FCnchen > > Registergericht: M=FCnchen, HRB 163416 > > > > > > >=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 Jun 05 04:57:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUr9-0005ui-3y; Tue, 05 Jun 2007 04:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUr7-0005se-Jy for mmusic@ietf.org; Tue, 05 Jun 2007 04:57:33 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvUr6-0003wW-9X for mmusic@ietf.org; Tue, 05 Jun 2007 04:57:33 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60063 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HvUr3-00050s-9e; Tue, 05 Jun 2007 09:57:29 +0100 In-Reply-To: <4664BEF0.4000207@nteczone.com> References: <058d01c7a6e7$4105bde0$c2f0200a@amer.cisco.com> <4664BEF0.4000207@nteczone.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Colin Perkins Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 Date: Tue, 5 Jun 2007 09:57:33 +0100 To: Christian Groves X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Albrecht.Schwarz@alcatel-lucent.de, sip-implementors@cs.columbia.edu, mmusic@ietf.org, Dan Wing 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 Jun 2007, at 02:40, Christian Groves wrote: > The document Albrecht originally pointed to is now an Appendix to =20 > ITU-T H.248.49. This was done to ensure that Albrecht's work was =20 > captured. The latest draft can be found at: > http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip > > I think Randell's point that the use of "-" in attribute names =20 > between RFC2327 and RFC4566 should also be captured in the =20 > Appendix. Better that these sorts of issues are documented. =20 > Something along the lines of: > > > "I.2.2.1 RFC 4566, =93a=3D=94 attribute > > The syntax of RFC2327 does not support the use of =93-=93 in an =20 > attribute name however the syntax of RFC4566 has been updated to =20 > support the inclusion of =93-=93. Therefore the use of attribute names = =20 > containing =93-=93 is problematic for RFC2327 implementations however =20= > several examples of attribute names containing =93-=93 were registered = =20 > prior to the definition of RFC4566. RFC2327 Implementors may =20 > consider exceptions when parsing an =93a=3D=94 where these attribute =20= > names containing =93-=93 are involved. " It's not that simple, since RFC 2327 is inconsistent. The ABNF allows =20= only alphanumeric characters in attribute names, but the text only =20 states that attribute names "must be in the US-ASCII subset of =20 ISO-10646/UTF-8". --=20 Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 05:01:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUv7-0001fB-SK; Tue, 05 Jun 2007 05:01:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUv6-0001f6-KL for mmusic@ietf.org; Tue, 05 Jun 2007 05:01:40 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvUv5-0004q3-06 for mmusic@ietf.org; Tue, 05 Jun 2007 05:01:40 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60090 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HvUv0-00063p-7h; Tue, 05 Jun 2007 10:01:34 +0100 In-Reply-To: <7374777208BDC7449D5620EF9423256704BCEA7A@esealmw113.eemea.ericsson.se> References: <4664BEF0.4000207@nteczone.com> <075d01c7a718$63b63e10$c2f0200a@amer.cisco.com> <7374777208BDC7449D5620EF9423256704BCEA7A@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Colin Perkins Subject: Re: [Sip-implementors] [MMUSIC] RE: Problems with RFC 2327 vs RFC4566, and between 4567 and 4568 Date: Tue, 5 Jun 2007 10:01:37 +0100 To: Christer Holmberg (JO/LMF) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Albrecht.Schwarz@alcatel-lucent.de, sip-implementors@cs.columbia.edu, mmusic@ietf.org, Dan Wing , Christian Groves 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 Christer, There were some media type values referenced in RFC 2327, but removed =20= in RFC 4566. This was because they were under-specified, due to not =20 being valid top-level media types, not because they were unused. If =20 they're used, then someone should document their semantics (i.e. =20 register them as top-level media types). Colin On 5 Jun 2007, at 06:32, Christer Holmberg (JO/LMF) wrote: > Another difference between 2327 and 4566 is that some of the media =20 > types were removed from 4566, based on claims they aren't used =20 > anywhere. > > At least one of them is. > > But, since that didn't affect the ABNF I guess it shouldn't be a =20 > problem from a parser perspective. > > Regards, > > Christer > >> -----Original Message----- >> From: sip-implementors-bounces@cs.columbia.edu >> [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf >> Of Dan Wing >> Sent: 5. kes=E4kuuta 2007 5:23 >> To: 'Christian Groves' >> Cc: sip-implementors@cs.columbia.edu; mmusic@ietf.org; >> Albrecht.Schwarz@alcatel-lucent.de >> Subject: Re: [Sip-implementors] [MMUSIC] RE: Problems with >> RFC 2327 vs RFC4566, and between 4567 and 4568 >> >> I agree such issues should be documented. Add a caveat like: >> >> Beyond the addition of "-" in attribute names, there are >> additional grammar differences between RFC2327 and >> RFC4566; enumerating those changes is left as an exercise >> for the reader >> >> and everything would be covered. >> >> -d >> >> >>> -----Original Message----- >>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>> Sent: Monday, June 04, 2007 6:40 PM >>> To: Dan Wing >>> Cc: 'Randell Jesup'; sip-implementors@cs.columbia.edu; >>> mmusic@ietf.org; Albrecht.Schwarz@alcatel-lucent.de >>> Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and >>> between 4567 and 4568 >>> >>> Hello, >>> >>> The document Albrecht originally pointed to is now an Appendix to >>> ITU-T H.248.49. This was done to ensure that Albrecht's work was >>> captured. The latest draft can be found at: >>> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip >>> >>> I think Randell's point that the use of "-" in attribute >> names between >>> RFC2327 and RFC4566 should also be captured in the Appendix. >>> Better that >>> these sorts of issues are documented. Something along the lines of: >>> >>> >>> "I.2.2.1 RFC 4566, "a=3D" attribute >>> >>> The syntax of RFC2327 does not support the use of "-" in an >> attribute >>> name however the syntax of RFC4566 has been updated to support the >>> inclusion of "-". Therefore the use of attribute names >> containing "-" >>> is problematic for RFC2327 implementations however several >> examples of >>> attribute names containing "-" were registered prior to the >> definition >>> of RFC4566. RFC2327 Implementors may consider exceptions >> when parsing >>> an "a=3D" where these attribute names containing "-" are involved. " >>> >>> Another way to lessen the problem would be that the internet drafts >>> using "-" in the attribute name remove "-" from the draft >> before going >>> RFC and the IANA registration procedures be updated to >> ensure that "-" >>> isn't used in the future for names. =46rom looking at the IANA >>> registrations the widespread use of "-" seems to be a relatively >>> recent phenomena. I guess those who have implemented the drafts >>> wouldn't be happy though :)..... >>> >>> Regards, Christian >>> >>> Dan Wing wrote: >>>> ... >>>> >>>>> Sure, but there's still an issue here, or at least >>> something needing >>>>> clarification: Is RFC 4568 trying to refer to a=3Dkey-mgmt >>> when it uses >>>>> a=3Dkeymgt? >>>>> >>>> >>>> I can only expect that was the intent, yes. This should be noted >>>> via http://www.rfc-editor.org/errata.html (which isn't >>> ideal, but it's >>>> all we have). Might want to ping the authors first to make >>> sure that >>>> was their intent. >>>> >>>> >>>>> It seems like RFC 4566 section 10 (Summary of changes >>> since RFC 2327) >>>>> should have mentioned this issue, and others where >>> complying with 4566 >>>>> would make you (at least in theory) not interoperable with >>> RFC 2327. >>>>> All 4566 says about it is: >>>>> >>>>> The ABNF grammar in Section 9 has been extensively revised and >>>>> updated, correcting a number of mistakes and >>> incorporating the RFC >>>>> 3266 IPv6 extensions. Known inconsistencies between the >>>>> grammar and >>>>> the specification text have been resolved. >>>>> >>>> >>>> Without going into a case-by-case analysis of those >> changes, I dunno >>>> if there would be much value in highlighting "-" in >> attribute names; >>>> highlighting it might cause some readers of the errata to >>> assume that >>>> was the only change, which could make RFC4566 >> 'compliance' worse (if >>>> that was thought by some implementor to be the only substantive >>>> change to the grammar). >>>> >>>> -d >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 06:55:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvWhY-0006lT-0X; Tue, 05 Jun 2007 06:55:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvWhW-0006lO-OK for mmusic@ietf.org; Tue, 05 Jun 2007 06:55:46 -0400 Received: from ipmail02.adl2.internode.on.net ([203.16.214.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvWhV-00047B-A2 for mmusic@ietf.org; Tue, 05 Jun 2007 06:55:46 -0400 X-IronPort-AV: E=Sophos;i="4.16,385,1175437800"; d="scan'208";a="134314496" Received: from ppp249-12.lns4.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.249.12]) by ipmail02.adl2.internode.on.net with ESMTP; 05 Jun 2007 20:25:39 +0930 Message-ID: <4665412B.1040103@nteczone.com> Date: Tue, 05 Jun 2007 20:55:39 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 References: <075d01c7a718$63b63e10$c2f0200a@amer.cisco.com> In-Reply-To: <075d01c7a718$63b63e10$c2f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de 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 Dan, Are you referring to additional differences between the grammar of attribute names or differences between the RFC2327 and RFC4566 syntax in general? If you are referring to the general case as H.248.49 Appendix I.2 (and in particular I.2.4) does enumerate the other changes. I think your text is good for a stand alone description of the problem but given that it will be integrated into the existing document I think the spirit of your proposal is covered in the existing text. Regards, Christian Dan Wing wrote: > I agree such issues should be documented. Add a caveat like: > > Beyond the addition of "-" in attribute names, there are > additional grammar differences between RFC2327 and > RFC4566; enumerating those changes is left as an exercise > for the reader > > and everything would be covered. > > -d > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 07:13:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvWyR-0007yJ-GE; Tue, 05 Jun 2007 07:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvWyQ-0007xy-B4 for mmusic@ietf.org; Tue, 05 Jun 2007 07:13:14 -0400 Received: from ipmail02.adl2.internode.on.net ([203.16.214.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvWyN-0007xR-Mb for mmusic@ietf.org; Tue, 05 Jun 2007 07:13:14 -0400 X-IronPort-AV: E=Sophos;i="4.16,385,1175437800"; d="scan'208";a="134325551" Received: from ppp249-12.lns4.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.249.12]) by ipmail02.adl2.internode.on.net with ESMTP; 05 Jun 2007 20:43:06 +0930 Message-ID: <46654545.2010101@nteczone.com> Date: Tue, 05 Jun 2007 21:13:09 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 References: <058d01c7a6e7$4105bde0$c2f0200a@amer.cisco.com> <4664BEF0.4000207@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Albrecht.Schwarz@alcatel-lucent.de, sip-implementors@cs.columbia.edu, mmusic@ietf.org, Dan Wing 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 Colin, Thanks for the extra information. Would the following text capture your clarification? Dan: I've also added some additional text to address your proposal. "I.2.2.1 RFC 4566, "a=" attribute The ABNF syntax of RFC2327 does not support the use of "-" in an attribute name however despite stating that attributes names must be in the US-ASCII subset of ISO-10646/UTF-8. The ABNF syntax of RFC4566 was updated to support the inclusion of "-" to address this inconsistency. Therefore the use of attribute names containing "-" is problematic for RFC2327 implementations as several examples of attribute names containing "-" were registered prior to the definition of RFC4566. RFC2327 Implementors may consider exceptions when parsing an "a=" where attribute names containing "-" are involved. Beyond the addition of "-" in attribute names, the RFC4566 ABNF "token" syntax defines additional characters (see item 22/I.2.4.2) that would also pose similar problems." Regards, Christian Colin Perkins wrote: > On 5 Jun 2007, at 02:40, Christian Groves wrote: >> The document Albrecht originally pointed to is now an Appendix to >> ITU-T H.248.49. This was done to ensure that Albrecht's work was >> captured. The latest draft can be found at: >> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip >> >> I think Randell's point that the use of "-" in attribute names >> between RFC2327 and RFC4566 should also be captured in the Appendix. >> Better that these sorts of issues are documented. Something along the >> lines of: >> >> >> "I.2.2.1 RFC 4566, “a=” attribute >> >> The syntax of RFC2327 does not support the use of “-“ in an attribute >> name however the syntax of RFC4566 has been updated to support the >> inclusion of “-“. Therefore the use of attribute names containing “-“ >> is problematic for RFC2327 implementations however several examples >> of attribute names containing “-“ were registered prior to the >> definition of RFC4566. RFC2327 Implementors may consider exceptions >> when parsing an “a=” where these attribute names containing “-“ are >> involved. " > > It's not that simple, since RFC 2327 is inconsistent. The ABNF allows > only alphanumeric characters in attribute names, but the text only > states that attribute names "must be in the US-ASCII subset of > ISO-10646/UTF-8". > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 08:57:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYao-0002tv-RI; Tue, 05 Jun 2007 08:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYam-0002by-EK; Tue, 05 Jun 2007 08:56:56 -0400 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 1HvYak-0007KH-So; Tue, 05 Jun 2007 08:56:56 -0400 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: Tue, 5 Jun 2007 15:57:45 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C049E77B3@IsrExch01.israel.polycom.com> In-Reply-To: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving draft-marjou-behave-app-rtp-keepalive to AVT Thread-Index: AcekcI3nU1nGOa0RQoq47/CcfLvnbgC/3a7Q From: "Even, Roni" To: "Colin Perkins" , "IETF AVT WG" , , "mmusic" X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [MMUSIC] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT 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 think that defining the keepalive for RTP that will not break RTP is an important work and can be done in AVT.=20 I read the draft and it looks like a good start. I support as having it an AVT working group draft Roni Even=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Friday, June 01, 2007 8:15 PM > To: IETF AVT WG; behave@ietf.org; mmusic > Cc: Even, Roni; Tom Taylor; Dan Wing ((dwing)); Cullen Jennings; Joerg > Ott; Xavier Marjou; Jean-Francois Mule; Magnus Westerlund > Subject: Moving draft-marjou-behave-app-rtp-keepalive to AVT >=20 > There has been some private discussion on adopting the draft on > Application Mechanisms for maintaining alive NAT mappings associated > with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an > AVT working group draft. This has previously been discussed in AVT, > BEHAVE and MMUSIC. Opinions on whether this draft should become a > working group draft, and on the appropriate home for it, are > solicited by 8 June 2007. >=20 > Colin (as AVT co-chair) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 09:50:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZQB-0002bn-Ay; Tue, 05 Jun 2007 09:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZQA-0002bR-5f for mmusic@ietf.org; Tue, 05 Jun 2007 09:50:02 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZQ8-0007mI-G0 for mmusic@ietf.org; Tue, 05 Jun 2007 09:50:02 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61598 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HvZQ5-0002nN-AF; Tue, 05 Jun 2007 14:49:57 +0100 In-Reply-To: <46654545.2010101@nteczone.com> References: <058d01c7a6e7$4105bde0$c2f0200a@amer.cisco.com> <4664BEF0.4000207@nteczone.com> <46654545.2010101@nteczone.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Colin Perkins Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 Date: Tue, 5 Jun 2007 14:49:59 +0100 To: Christian Groves X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Dan Wing , sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de 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 Christian, The text, as with much of the text in this document, gives the =20 impression that there are meaningful "RFC 2327 implementations", and =20 that the compatibility issues are due to RFC 4566 changing the =20 specification. I think that's greatly misleading, and gives the =20 impression that there are more issues than actually exist. In reality, RFC 2327 is self-contradictory and unclear in a number of =20= places, and useful implementations rely on a large number of =20 extensions and interpretations of the standard. RFC 4566, while not =20 perfect, greatly clarifies the text to fix those problems, and to =20 reflect existing practice. It's my belief that there are no more =20 compatibility issues between an "RFC 2327 implementation" and one =20 based on RFC 4566, than between any two RFC 2327 implementations. Colin On 5 Jun 2007, at 12:13, Christian Groves wrote: > Thanks for the extra information. Would the following text capture =20 > your clarification? > > Dan: I've also added some additional text to address your proposal. > > "I.2.2.1 RFC 4566, "a=3D" attribute > > The ABNF syntax of RFC2327 does not support the use of "-" in an =20 > attribute name however despite stating that attributes names must =20 > be in the US-ASCII subset of ISO-10646/UTF-8. The ABNF syntax of =20 > RFC4566 was updated to support the inclusion of "-" to address this =20= > inconsistency. Therefore the use of attribute names containing "-" =20 > is problematic for RFC2327 implementations as several examples of =20 > attribute names containing "-" were registered prior to the =20 > definition of RFC4566. RFC2327 Implementors may consider exceptions =20= > when parsing an "a=3D" where attribute names containing "-" are =20 > involved. > > Beyond the addition of "-" in attribute names, the RFC4566 ABNF =20 > "token" syntax defines additional characters (see item 22/I.2.4.2) =20= > that would also pose similar problems." > > Regards, Christian > > Colin Perkins wrote: >> On 5 Jun 2007, at 02:40, Christian Groves wrote: >>> The document Albrecht originally pointed to is now an Appendix to =20= >>> ITU-T H.248.49. This was done to ensure that Albrecht's work was =20 >>> captured. The latest draft can be found at: >>> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip >>> >>> I think Randell's point that the use of "-" in attribute names =20 >>> between RFC2327 and RFC4566 should also be captured in the =20 >>> Appendix. Better that these sorts of issues are documented. =20 >>> Something along the lines of: >>> >>> >>> "I.2.2.1 RFC 4566, =93a=3D=94 attribute >>> >>> The syntax of RFC2327 does not support the use of =93-=93 in an =20 >>> attribute name however the syntax of RFC4566 has been updated to =20 >>> support the inclusion of =93-=93. Therefore the use of attribute =20 >>> names containing =93-=93 is problematic for RFC2327 implementations =20= >>> however several examples of attribute names containing =93-=93 were =20= >>> registered prior to the definition of RFC4566. RFC2327 =20 >>> Implementors may consider exceptions when parsing an =93a=3D=94 = where =20 >>> these attribute names containing =93-=93 are involved. " >> >> It's not that simple, since RFC 2327 is inconsistent. The ABNF =20 >> allows only alphanumeric characters in attribute names, but the =20 >> text only states that attribute names "must be in the US-ASCII =20 >> subset of ISO-10646/UTF-8". >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 10:15: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 1HvZoz-0005xh-2J; Tue, 05 Jun 2007 10:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZoy-0005xc-1F for mmusic@ietf.org; Tue, 05 Jun 2007 10:15:40 -0400 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 1HvZox-0004vv-1n for mmusic@ietf.org; Tue, 05 Jun 2007 10:15:40 -0400 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 l55EFWXf004809 for ; Tue, 5 Jun 2007 17:15:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 17:15:33 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 17:15:33 +0300 Received: from [172.21.154.97] ([172.21.154.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 17:15:32 +0300 Message-ID: <46657005.4040802@nsn.com> Date: Tue, 05 Jun 2007 17:15:33 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 14:15:33.0029 (UTC) FILETIME=[FA95DD50:01C7A77B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [MMUSIC] File transfer version -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 Hi: I have just submitted version -03 of the file transfer mechanism draft. Until it becomes available in your favorite repository, you can fetch a copy from: http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03.txt http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03.html A diff version is also available: http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03-from-2.html These are the changes in this version: - new attribute 'file-transfer'. It determines whether a "new" file transfer is requested, or the SDP is there because of an "existing" file transfer. - ABNF in name selector considers double quotes now. - ABNF of hash changes to be equal to RFC 4572 (Comedia). - File disposition 'not-render' is now 'attachment'. No need to invent a new disposition value. - Hash of file is locally computed and checked for errors with that in the SDP. - All available hash algorithms are sent. - Clarifications on the usage of the max-size attribute in MSRP - Added considerations about the 'file-icon' attribute and their requirements for multipart MIME bodies. Other minor changes: - Addition of definitions of Push and Pull operations - Clarification that the file selector need not contain all four selectors To my knowledge, this completes the round of discussions we had in the past. There is only one open issue that I will be discussing in a separate thread. BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 10:22:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZvR-0006mF-Fx; Tue, 05 Jun 2007 10:22:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZvQ-0006m9-4s for mmusic@ietf.org; Tue, 05 Jun 2007 10:22:20 -0400 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 1HvZvO-0006VT-Mb for mmusic@ietf.org; Tue, 05 Jun 2007 10:22:20 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l55EM0ki017968 for ; Tue, 5 Jun 2007 17:22:16 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 17:22:12 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 17:22:12 +0300 Received: from [172.21.154.97] ([172.21.154.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 17:22:12 +0300 Message-ID: <46657194.3060103@nsn.com> Date: Tue, 05 Jun 2007 17:22:12 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 14:22:12.0100 (UTC) FILETIME=[E8734440:01C7A77C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [MMUSIC] File-transfer issue 37: mandating (or not) message/cpim 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 The current file-transfer draft does not explicitly indicates the mandate for a message/cpim wrapper. There have been discussions seeking for clarification on the level of requirement with respect message/cpim. Here we rely on MSRP, which mandates the implementation of message/cpim but does not mandate its usage, except when one of the endpoints is a CPIM gateway. Should the file-transfer draft mandate it? I think mandating message/cpim at this stage will make our life much easier in the future, for example, if we think of sending a file on a multiparty connection, of via a CPIM gateway. However, since it is not really mandated in MSRP, I am not sure what to say. MSRP says: Furthermore, when one endpoint of the session is a CPIM gateway, instant messages SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST include "message/cpim" as the first entry in its SDP accept-types attribute. MSRP endpoints sending instant messages to a peer that has included "message/cpim" as the first entry in the accept-types attribute SHOULD encapsulate all instant message bodies in "message/ cpim" wrappers. All MSRP endpoints MUST support the message/cpim type, and SHOULD support the S/MIME[7] features of that format. Any views on this? Whatever is the decision, we should document it. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 10:42:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvaEU-0008R8-9n; Tue, 05 Jun 2007 10:42:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvaET-0008Nz-56 for mmusic@ietf.org; Tue, 05 Jun 2007 10:42:01 -0400 Received: from brixmail.brixnet.com ([63.122.27.37] helo=brixmail.ma.brixnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvaES-0000zU-SX for mmusic@ietf.org; Tue, 05 Jun 2007 10:42:01 -0400 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] Comments on draft-ietf-mmusic-media-loopback-06.txt Date: Tue, 5 Jun 2007 10:41:53 -0400 Message-ID: In-Reply-To: <0D1719326D64BD4E9F92A0C120237678020127FC@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-06.txt Thread-Index: AceSZjcU0H3IX9sQSaiFy6vkISdVVQVGQ5qg From: "Venna, Nagarjuna" To: "Rick Porter" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Rick, Here is an attempt at addressing your comments: 1. While it is plausible to compare plaintext/encrypted performance, there is no guarantee that in direct loopback mode the mirror would actually decrypt the payload. In the general case, you can not depend on it.=20 2. In media loopback mode, the packets go through the jitter buffer. Using the inner timestamp portion as you suggested would work only for encapsulated payload format. 3. I think the authors chose a different m=3Dline as the start loopback stream is logically a different media stream. 4. The overhead is only for encapsulated format, there is no overhead if you are using direct loopback. With direct loopback, the sender can put data in the payload that can help it compute metrics it is interested in (after setting the appropriate payload type) as this data will be returned unchanged by the mirror. This mode however has limitations (related to MTU) as specified in the draft.=20 Thanks, Nagarjuna -----Original Message----- From: Rick Porter [mailto:rporter@covergence.com]=20 Sent: Wednesday, May 09, 2007 2:17 PM To: mmusic@ietf.org Subject: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-06.txt Here are a few comments/questions... 1. Where does SRTP encryption/decryption come when doing packet loopback? For media loopback, you obviously need to decrypt any encrypted packets. If you're on a link that "always" does SRTP, I would think that you'd want to be able to see how much jitter/loss/latency is introduced by encryption/decryption and possibly compare plaintext/encrypted performance. 2. Should looped back packets go thru the jitter buffer on the mirror? If they do not, the jitter for a call will be compounded. If they do, the latency is increased--depending on implementation, you may be able to subtract jitter-buffer delay if the inner timestamp portion of the encapsulated packet is set to the received timestamp (instead of simply repeating the RTP timestamp).=20 3. Can we reduce SDP to have a single media-description, even when mirror initially sends packets? I think the session should only have one media stream, and the second media-description/stream may confuse non-loopback aware devices who handle the media (e.g. SBCs). 4. With packet loopback, can/should the mirror truncate the last 16 bytes of RTP payload to preserve RTP characteristics? In many situations, I think the RTP header should be sufficient for processing. However, I do see some situations where a device in the middle could potentially transcode RTP packets so that the mirror does not receive the original RTP and it may be desirable to have the whole RTP payload.=20 Cheers, Rick _______________________________________________ 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 Jun 05 11:05:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvabD-000058-SL; Tue, 05 Jun 2007 11:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvabC-0008WP-7M; Tue, 05 Jun 2007 11:05:30 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvab9-0005eW-SC; Tue, 05 Jun 2007 11:05:30 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62774 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Hvab7-00056S-V8; Tue, 05 Jun 2007 16:05:26 +0100 In-Reply-To: <05cf01c7a6ea$8cb552c0$c2f0200a@amer.cisco.com> References: <05cf01c7a6ea$8cb552c0$c2f0200a@amer.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 Date: Tue, 5 Jun 2007 16:05:29 +0100 To: Lars Eggert , Dan Wing X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Godred Fairhurst , draft-ford-behave-app@tools.ietf.org, Behave WG , mmusic , Xavier Marjou , Tom Taylor , Joerg Ott , IETF AVT WG , Jean-Francois Mule , tsvwg chair Subject: [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT 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 4 Jun 2007, at 21:54, Dan Wing wrote: >> On 2007-6-1, at 21:09, ext Dan Wing wrote: >>> We need a document that consolidates NAT keepalive mechanisms for >>> UDP-based protocols, most notably RTP (and, to a lesser extent, >>> SIP). Currently this is spread in various documents and there >>> is no consolidated guidance to implementtors on the strength >>> or weakness of various approaches. >> >> I'm wondering if it'd make sense to add this guidance as a >> section in >> http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines? > > I agree "send periodic UDP traffic" would be good in that > document. REQ-6 of draft-ford-behave-app-05 may provide the > beginnings of some useful text (CC'ing the authors of that > document). > > As with all applications on today's Internet, an RTP > application needs to be robust and able to deal with whatever > is sent to it, so perhaps you're right -- an application- > specific keepalive document may well be overly specific and > we should, rather, document what any UDP-based application > should do to prevent middleboxes (such as NATs) from > clobbering a flow. The udp-guidelines draft should probably outline what sort of keep alive mechanism is needed, but the implementation is likely protocol specific, and should be done by the group designing that protocol, I think. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 11:08:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvae2-0000k2-3r; Tue, 05 Jun 2007 11:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVoy-00009D-SA; Tue, 05 Jun 2007 05:59:24 -0400 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVou-0005kr-Mm; Tue, 05 Jun 2007 05:59:24 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zqx.siemens.at with ESMTP id l559xF3g000331; Tue, 5 Jun 2007 11:59:15 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l559xAPn013789; Tue, 5 Jun 2007 11:59:15 +0200 Received: from nets13ka.ww300.siemens.net ([158.226.250.80]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 11:59:12 +0200 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: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed Date: Tue, 5 Jun 2007 11:54:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] questions about grouping media streams in RTP and SDP(RFC3388 etc), advice needed Thread-Index: AcemxHiQHUF4zzUiTS2DsZiVU+iS5gAd0gDQAAbvC4w= References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com> From: "Kalleitner, Franz" To: "Even, Roni" , "Dave Singer" , "mmusic" , "IETF AVT WG" X-OriginalArrivalTime: 05 Jun 2007 09:59:12.0727 (UTC) FILETIME=[2B360670:01C7A758] 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::070605115915-6ED2FBB0-3E5039F0/0-0/0-15 X-purgate-size: 4660/0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-Mailman-Approved-At: Tue, 05 Jun 2007 11:08:24 -0400 Cc: "Clinton Priddle \(KI/EAB\)" 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, dave, =20 you can find some work and ideas on how to handle a "repair" stream in = parallel to an orignal RTP stream in RFC4588 too. =20 cheers, franz ________________________________ Von: Even, Roni [mailto:roni.even@polycom.co.il] Gesendet: Di 05.06.2007 09:03 An: Dave Singer; mmusic; IETF AVT WG Cc: Clinton Priddle (KI/EAB) Betreff: [AVT] RE: [MMUSIC] questions about grouping media streams in = RTPand SDP (RFC3388 etc), advice needed Dave, For layered encoding there is a proposal for a new grouping attribute in http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx t I looked at RFC3388 and I think that FID is not the answer to your requirement as you mentioned To me it looks like what you are looking for is a way to specify alternate offers. If this is the case I have similar requirements and would be happy to support such work. You also need a way to give semantics to the "repair" stream, this can be done based on the content attribute from RFC 4796 or using a dependency attribute see in Schierl's draft. The mid tag is not enough for the receiver to know what you meant by this offer and which stream is the repair. Here is an example for a solution using a new Alternatives grouping attribute and giving semantics to the repair stream By using the grouping attribute in the offer you can know if the answerer understood the grouping since if he does not than he will send an answer with no a=3Dgroup v=3D0 o=3Dbob 280744730 28977631 IN IP4 host.example.com s=3D t=3D0 0 a=3Dgroup:ALTS 1 2 a=3Dgroup:ALTS 1 3 m=3Daudio 6886 RTP/AVP 0 c=3DIN IP6 2001:0600::1 a=3Dmid:1 m=3Dvideo 9000 RTP/AVP 100 c=3DIN IP4 192.0.2.2 a=3Drtpmap:100 H263-1998 a=3Dmid:2 m=3Dvideo 9002 RTP/AVP 101 c=3DIN IP4 192.0.2.2 a=3Drtpmap:101 H263-1998 a=3Dmid:3 a=3Dcontent:repair=3D2 or a=3Ddepend:repair=3D2 Roni Even > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Monday, June 04, 2007 7:19 PM > To: mmusic; IETF AVT WG > Cc: Clinton Priddle (KI/EAB) > Subject: [MMUSIC] questions about grouping media streams in RTP and SDP > (RFC3388 etc), advice needed > > Hi > > we have a need to group together two media streams, in the style of RFC > 3388 but we're unsure whether an > existing group type is suitable or not, and if it's not, we'd like to > agree on a new one, and document it (presumably in an RFC). > > What we have is a normal media stream, and a separate 'repair' or > 'entry' stream, that can be used when tuning in, or after loss, but is > otherwise un-needed. An example might be a video stream with a low > I-frame interval (say every 15 seconds), with a repair stream which has > only I-frames that are equivalent to the time-parallel non-I frame, at a > frequency of say 1 per second. > > It's not clear to us whether this is "one media flow" in the sense of > FID, or not. The example offers AMR and GSM audio, which are > alternatives, and DTMF tones along with audio, which are supplementary > to each other. Perhaps we fall afoul of this restriction: > > "An application that encodes the same media using different codecs > simultaneously MUST NOT use FID to group those media lines." > > or this one, for layered encoding: > > "FID MUST NOT be used to group "m" lines that do not represent the same > information." (Though how DTMF tones and their associated audio pass > this test is not clear). > > Nor is it clear that the FEC group of RFC 4756 is right, either. For a > start, we may wish to use this new ID in combination with FEC, and > secondly this tune-in stream has different characteristics. For > example, one can typically ignore all FEC and (as long as there are no > errors) decode the stream correctly. Ignoring the tune-in stream > entirely may mean that you will never find a tune-in point, making the > normal stream useless. > > So, can we use FID for associating a repair stream with its base (we tag > the streams so we know which is which, of course)? > > p.s. RFC 4756 claims in the IANA section that the FEC group is > registered under SDP characteristics, but actually I can find no > registry anywhere in IANA of group types. > > > -- > David Singer > Apple/QuickTime > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 11:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvagO-0001HO-Uz; Tue, 05 Jun 2007 11:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvagN-0001Gb-0u; Tue, 05 Jun 2007 11:10:51 -0400 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 1HvagL-0006bI-J4; Tue, 05 Jun 2007 11:10:50 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l55FAITB020666; Tue, 5 Jun 2007 18:10:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 18:10:34 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 18:10:33 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 18:10:33 +0300 Received: from [172.21.39.184] (esdhcp039184.research.nokia.com [172.21.39.184]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l55FAVKK006865; Tue, 5 Jun 2007 18:10:31 +0300 In-Reply-To: References: <05cf01c7a6ea$8cb552c0$c2f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <73F566CA-38E1-4E83-958F-147D56283036@nokia.com> From: Lars Eggert Date: Tue, 5 Jun 2007 18:10:19 +0300 To: "ext Colin Perkins" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jun 2007 15:10:33.0232 (UTC) FILETIME=[A9A8E100:01C7A783] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Godred Fairhurst , draft-ford-behave-app@tools.ietf.org, Behave WG , mmusic , Xavier Marjou , Tom Taylor , Joerg Ott , IETF AVT WG , Jean-Francois Mule , Dan Wing , tsvwg chair Subject: [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT 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="===============1642258281==" Errors-To: mmusic-bounces@ietf.org --===============1642258281== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-66-885556731; protocol="application/pkcs7-signature" --Apple-Mail-66-885556731 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-6-5, at 18:05, ext Colin Perkins wrote: > The udp-guidelines draft should probably outline what sort of keep > alive mechanism is needed, but the implementation is likely > protocol specific, and should be done by the group designing that > protocol, I think. Makes sense to me. Lars --Apple-Mail-66-885556731 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MDUxNTEwMjBaMCMGCSqGSIb3DQEJBDEWBBRbj05Hu7iAJBLQ 7bGQRy7UcNWDWzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAp1uwyPmKHMl8siPcSELxzVj6XfhFRWcVSxcaft3yD+5QNVuJ2rab ASyq+rULH1fzS81a6jW+A9g4YaKnexx8PvHYWQ6UAF1FHfqmnPL7D2exGYUUxpfqCtXjgVYu1UaD HUPRn50xzIm4bmQsnD59RBacjOQfNl3qEGsBjwJBYNpbcIEs3DR0XBIYqyqfntSuILFhQHaq1cHa PptT12kZEcPQ4+l1/r+ObHhMTKvIdH3muQtiCEuLx5MmZRji8NkQO+S2pGvdBJGcfwkCRBDnKhN+ RE1JU7AzsnN1lhTf5Zr5GJ3rqT4PUaFj4/S/mHJEWfCrPJ+2Il/5NBRlbs55XwAAAAAAAA== --Apple-Mail-66-885556731-- --===============1642258281== 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 --===============1642258281==-- From mmusic-bounces@ietf.org Tue Jun 05 11:35:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvb4E-0005UF-Gz; Tue, 05 Jun 2007 11:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvb4C-0005Lw-Un; Tue, 05 Jun 2007 11:35:28 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvb4C-0005Zz-Ce; Tue, 05 Jun 2007 11:35:28 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (Postfix) with ESMTP id AED427F511F; Tue, 5 Jun 2007 08:34:33 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id E632329C002; Tue, 5 Jun 2007 08:35:27 -0700 (PDT) X-AuditID: 11807123-9d01cbb000000a23-7a-466582bf36d2 Received: from [17.202.35.52] (unknown [17.151.66.148]) by relay5.apple.com (Apple SCV relay) with ESMTP id 58E4830400E; Tue, 5 Jun 2007 08:35:27 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com> References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com> Date: Tue, 5 Jun 2007 08:34:08 -0700 To: "Even, Roni" , mmusic , IETF AVT WG From: Dave Singer Subject: RE: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: "Clinton Priddle \(KI/EAB\)" 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 At 10:03 +0300 5/06/07, Even, Roni wrote: >Dave, >For layered encoding there is a proposal for a new grouping attribute in >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx >t I don't think this is a layered coding issue, either, alas. >I looked at RFC3388 and I think that FID is not the answer to your >requirement as you mentioned > >To me it looks like what you are looking for is a way to specify >alternate offers. No, these streams are not alternatives to each other in the regular sense. Nor is this really used in offer/answer; it's more an issue for multicast. In multicast, you open the tune-in stream and the base stream, grab the first I-frame that arrives (in either) and then drop the tune-in stream. Yes, we're aware that the recipient needs to be able to tell which is the base and which is the tune-in. >If this is the case I have similar requirements and >would be happy to support such work. > >You also need a way to give semantics to the "repair" stream, this can >be done based on the content attribute from RFC 4796 or using a >dependency attribute see in Schierl's draft. The mid tag is not enough >for the receiver to know what you meant by this offer and which stream >is the repair. > >Here is an example for a solution using a new Alternatives grouping >attribute and giving semantics to the repair stream > >By using the grouping attribute in the offer you can know if the >answerer understood the grouping since if he does not than he will send >an answer with no a=group > >v=0 >o=bob 280744730 28977631 IN IP4 host.example.com >s= >t=0 0 > >a=group:ALTS 1 2 >a=group:ALTS 1 3 > >m=audio 6886 RTP/AVP 0 >c=IN IP6 2001:0600::1 >a=mid:1 > >m=video 9000 RTP/AVP 100 >c=IN IP4 192.0.2.2 >a=rtpmap:100 H263-1998 >a=mid:2 > >m=video 9002 RTP/AVP 101 >c=IN IP4 192.0.2.2 >a=rtpmap:101 H263-1998 >a=mid:3 >a=content:repair=2 or a=depend:repair=2 > > >Roni Even > >> -----Original Message----- >> From: Dave Singer [mailto:singer@apple.com] >> Sent: Monday, June 04, 2007 7:19 PM >> To: mmusic; IETF AVT WG >> Cc: Clinton Priddle (KI/EAB) >> Subject: [MMUSIC] questions about grouping media streams in RTP and >SDP >> (RFC3388 etc), advice needed >> >> Hi >> >> we have a need to group together two media streams, in the style of >RFC >> 3388 but we're unsure whether an >> existing group type is suitable or not, and if it's not, we'd like to >> agree on a new one, and document it (presumably in an RFC). >> >> What we have is a normal media stream, and a separate 'repair' or >> 'entry' stream, that can be used when tuning in, or after loss, but is >> otherwise un-needed. An example might be a video stream with a low >> I-frame interval (say every 15 seconds), with a repair stream which >has >> only I-frames that are equivalent to the time-parallel non-I frame, at >a >> frequency of say 1 per second. >> >> It's not clear to us whether this is "one media flow" in the sense of >> FID, or not. The example offers AMR and GSM audio, which are >> alternatives, and DTMF tones along with audio, which are supplementary >> to each other. Perhaps we fall afoul of this restriction: >> >> "An application that encodes the same media using different codecs >> simultaneously MUST NOT use FID to group those media lines." >> >> or this one, for layered encoding: >> >> "FID MUST NOT be used to group "m" lines that do not represent the >same >> information." (Though how DTMF tones and their associated audio pass >> this test is not clear). >> >> Nor is it clear that the FEC group of RFC 4756 is right, either. For >a >> start, we may wish to use this new ID in combination with FEC, and >> secondly this tune-in stream has different characteristics. For >> example, one can typically ignore all FEC and (as long as there are no >> errors) decode the stream correctly. Ignoring the tune-in stream > > entirely may mean that you will never find a tune-in point, making the >> normal stream useless. >> >> So, can we use FID for associating a repair stream with its base (we >tag >> the streams so we know which is which, of course)? >> >> p.s. RFC 4756 claims in the IANA section that the FEC group is >> registered under SDP characteristics, but actually I can find no >> registry anywhere in IANA of group types. >> >> >> -- >> David Singer >> Apple/QuickTime >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic -- David Singer Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 13:17:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvcf9-0005ef-8U; Tue, 05 Jun 2007 13:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvcf8-0005cQ-3L for mmusic@ietf.org; Tue, 05 Jun 2007 13:17:42 -0400 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 1Hvcf5-000231-Cj for mmusic@ietf.org; Tue, 05 Jun 2007 13:17:42 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 05 Jun 2007 10:17:39 -0700 X-IronPort-AV: i="4.16,386,1175497200"; d="scan'208"; a="377300691:sNHT68730388" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l55HHc7c011910; Tue, 5 Jun 2007 10:17:38 -0700 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 l55HHPV5006390; Tue, 5 Jun 2007 17:17:30 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:17:27 -0700 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] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 Date: Tue, 5 Jun 2007 10:17:25 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 Thread-Index: AceneH3ZuIzkXO4hRzuNTj05K6puQwAGre9Q From: "Joe Stone \(joestone\)" To: "Colin Perkins" , "Christian Groves" X-OriginalArrivalTime: 05 Jun 2007 17:17:27.0519 (UTC) FILETIME=[6420DEF0:01C7A795] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4466; t=1181063858; x=1181927858; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=joestone@cisco.com; z=From:=20=22Joe=20Stone=20\(joestone\)=22=20 |Subject:=20RE=3A=20[MMUSIC]=20RE=3A=20Problems=20with=20RFC=202327=20vs= 20RFC=204566,and=20between=204567=20and=204568 |Sender:=20; bh=i4WcdnPeM4fzvjDh4/UPNAWyNIVbqumY7FZK0BQ5dhQ=; b=HR7PND1m9RguZVQ/B8l00qIEYnxW3+pFgi+1CUb1u0Xyp2wzAzxCOvNty9v633VmnX7Oqrgu 2x15xwGcHP2HWo9P5ahc8GMtLzU38rw80AiS2CLdncBf7gPWRCjWbGNEGjJ0aNo+ERKVPh+I1D Lr7RgCW5tupypEZl9+QI7IiYE=; Authentication-Results: sj-dkim-1; header.From=joestone@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Albrecht.Schwarz@alcatel-lucent.de, sip-implementors@cs.columbia.edu, mmusic@ietf.org, "Dan Wing \(dwing\)" 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 we're keeping score, here's a RFC 2327 <-> 4566 compatibility issue... RFC 4566 opted to add the following sentence to the definition of the "a=3Dfmtp" SDP attribute, At most one instance of this attribute is allowed for each format. There are countless I-Ds and RFCs which leverage multiple instances of the "a=3Dfmtp" SDP attribute per media format.=20 Joe -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: Tuesday, June 05, 2007 8:50 AM To: Christian Groves Cc: Dan Wing (dwing); sip-implementors@cs.columbia.edu; mmusic@ietf.org; Albrecht.Schwarz@alcatel-lucent.de Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566,and between 4567 and 4568 Christian, The text, as with much of the text in this document, gives the impression that there are meaningful "RFC 2327 implementations", and that the compatibility issues are due to RFC 4566 changing the specification. I think that's greatly misleading, and gives the impression that there are more issues than actually exist. In reality, RFC 2327 is self-contradictory and unclear in a number of places, and useful implementations rely on a large number of extensions and interpretations of the standard. RFC 4566, while not perfect, greatly clarifies the text to fix those problems, and to reflect existing practice. It's my belief that there are no more compatibility issues between an "RFC 2327 implementation" and one based on RFC 4566, than between any two RFC 2327 implementations. Colin On 5 Jun 2007, at 12:13, Christian Groves wrote: > Thanks for the extra information. Would the following text capture=20 > your clarification? > > Dan: I've also added some additional text to address your proposal. > > "I.2.2.1 RFC 4566, "a=3D" attribute > > The ABNF syntax of RFC2327 does not support the use of "-" in an=20 > attribute name however despite stating that attributes names must be=20 > in the US-ASCII subset of ISO-10646/UTF-8. The ABNF syntax of > RFC4566 was updated to support the inclusion of "-" to address this=20 > inconsistency. Therefore the use of attribute names containing "-" > is problematic for RFC2327 implementations as several examples of=20 > attribute names containing "-" were registered prior to the definition > of RFC4566. RFC2327 Implementors may consider exceptions when parsing=20 > an "a=3D" where attribute names containing "-" are involved. > > Beyond the addition of "-" in attribute names, the RFC4566 ABNF=20 > "token" syntax defines additional characters (see item 22/I.2.4.2)=20 > that would also pose similar problems." > > Regards, Christian > > Colin Perkins wrote: >> On 5 Jun 2007, at 02:40, Christian Groves wrote: >>> The document Albrecht originally pointed to is now an Appendix to=20 >>> ITU-T H.248.49. This was done to ensure that Albrecht's work was=20 >>> captured. The latest draft can be found at: >>> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip >>> >>> I think Randell's point that the use of "-" in attribute names=20 >>> between RFC2327 and RFC4566 should also be captured in the Appendix. >>> Better that these sorts of issues are documented. >>> Something along the lines of: >>> >>> >>> "I.2.2.1 RFC 4566, "a=3D" attribute >>> >>> The syntax of RFC2327 does not support the use of "-" in an =20 >>> attribute name however the syntax of RFC4566 has been updated to =20 >>> support the inclusion of "-". Therefore the use of attribute =20 >>> names containing "-" is problematic for RFC2327 implementations =20 >>> however several examples of attribute names containing "-" were =20 >>> registered prior to the definition of RFC4566. RFC2327 =20 >>> Implementors may consider exceptions when parsing an "a=3D" where =20 >>> these attribute names containing "-" are involved. " >> >> It's not that simple, since RFC 2327 is inconsistent. The ABNF =20 >> allows only alphanumeric characters in attribute names, but the =20 >> text only states that attribute names "must be in the US-ASCII =20 >> subset of ISO-10646/UTF-8". >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ _______________________________________________ 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 Jun 05 16:15:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvfRC-0006LP-4o; Tue, 05 Jun 2007 16:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvfRA-0006L6-RM for mmusic@ietf.org; Tue, 05 Jun 2007 16:15:28 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvfR8-0002N2-IM for mmusic@ietf.org; Tue, 05 Jun 2007 16:15:28 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:63937 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HvfR5-0004W8-Hr; Tue, 05 Jun 2007 21:15:23 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09896490-209E-4661-B0DC-6FBD6B9BAB36@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 Date: Tue, 5 Jun 2007 21:15:27 +0100 To: Joe Stone ((joestone)) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Dan Wing \(dwing\)" , sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de, Christian Groves 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 Jun 2007, at 18:17, Joe Stone ((joestone)) wrote: > If we're keeping score, here's a RFC 2327 <-> 4566 compatibility > issue... > > RFC 4566 opted to add the following sentence to the definition of the > "a=fmtp" SDP attribute, > > At most one instance of this attribute is allowed for each > format. Yes, because otherwise the usual mapping to media type parameters is lost. > There are countless I-Ds and RFCs which leverage multiple instances of > the "a=fmtp" SDP attribute per media format. The only case I'm aware of is a mistake RFC 3189. Do you know of other examples? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 05 18:50:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvhqs-00083m-8R; Tue, 05 Jun 2007 18:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvhqk-00081h-I9; Tue, 05 Jun 2007 18:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvhqk-0000vu-81; Tue, 05 Jun 2007 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 36AA232946; Tue, 5 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hvhqk-0006un-31; Tue, 05 Jun 2007 18:50:02 -0400 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, 05 Jun 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-file-transfer-mech-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 : 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-03.txt Pages : 43 Date : 2007-6-5 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-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-file-transfer-mech-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-file-transfer-mech-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-6-5151130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-file-transfer-mech-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-file-transfer-mech-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-5151130.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 Tue Jun 05 22:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvl6M-0001iL-3J; Tue, 05 Jun 2007 22:18:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvl6J-0001iF-EL for mmusic@ietf.org; Tue, 05 Jun 2007 22:18:19 -0400 Received: from ipmail02.adl2.internode.on.net ([203.16.214.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hvl6F-0006XQ-AV for mmusic@ietf.org; Tue, 05 Jun 2007 22:18:19 -0400 X-IronPort-AV: E=Sophos;i="4.16,387,1175437800"; d="scan'208";a="134643107" Received: from unknown (HELO [127.0.0.1]) ([121.44.229.11]) by ipmail02.adl2.internode.on.net with ESMTP; 06 Jun 2007 11:48:02 +0930 Message-ID: <46661957.9080808@nteczone.com> Date: Wed, 06 Jun 2007 12:17:59 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [MMUSIC] RE: Problems with RFC 2327 vs RFC 4566, and between 4567 and 4568 References: <058d01c7a6e7$4105bde0$c2f0200a@amer.cisco.com> <4664BEF0.4000207@nteczone.com> <46654545.2010101@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Dan Wing , sip-implementors@cs.columbia.edu, mmusic@ietf.org, Albrecht.Schwarz@alcatel-lucent.de 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 Colin, I agree there are going to be compatibility issues between RFC2327 implementations, or RFC4566 implementations or SIP implementations etc. If humans are involved then there will be some error. Its not the scope of the Appendix to discuss this. The Appendix documents the compatibility issues which resulted from the text of the RFC upgrade. There are compatibility issues between the text of the two RFCs. Even if I had a "meaningful" RFC2327 implementation (based on extensions and "interpretations") the result of adopting RFC4566 would be that I would need to look to see what the impacts are. The place I would start to look is by comparing the two RFCs for changes. Isn't it better to highlight what the differences are so that they are known? Several people have commented that Albrecht's analysis has been helpful for them because the summary of changes documented in RFC4566 wasn't detailed enough. That's partly why we've adopted it. Albrecht's analysis is usually thorough and methodical so I can't see that there was any desire to be misleading. If there's specific text in the Appendix that's erroneous or misleading please flag it so we can address it, or if you have some modified text even better :) . As co-author of RFC4566 I'm sure people will appreciate any extra guidance you can propose for the text. Regards, Christian Colin Perkins wrote: > Christian, > > The text, as with much of the text in this document, gives the > impression that there are meaningful "RFC 2327 implementations", and > that the compatibility issues are due to RFC 4566 changing the > specification. I think that's greatly misleading, and gives the > impression that there are more issues than actually exist. > > In reality, RFC 2327 is self-contradictory and unclear in a number of > places, and useful implementations rely on a large number of > extensions and interpretations of the standard. RFC 4566, while not > perfect, greatly clarifies the text to fix those problems, and to > reflect existing practice. It's my belief that there are no more > compatibility issues between an "RFC 2327 implementation" and one > based on RFC 4566, than between any two RFC 2327 implementations. > > Colin > > > > On 5 Jun 2007, at 12:13, Christian Groves wrote: >> Thanks for the extra information. Would the following text capture >> your clarification? >> >> Dan: I've also added some additional text to address your proposal. >> >> "I.2.2.1 RFC 4566, "a=" attribute >> >> The ABNF syntax of RFC2327 does not support the use of "-" in an >> attribute name however despite stating that attributes names must be >> in the US-ASCII subset of ISO-10646/UTF-8. The ABNF syntax of RFC4566 >> was updated to support the inclusion of "-" to address this >> inconsistency. Therefore the use of attribute names containing "-" is >> problematic for RFC2327 implementations as several examples of >> attribute names containing "-" were registered prior to the >> definition of RFC4566. RFC2327 Implementors may consider exceptions >> when parsing an "a=" where attribute names containing "-" are involved. >> >> Beyond the addition of "-" in attribute names, the RFC4566 ABNF >> "token" syntax defines additional characters (see item 22/I.2.4.2) >> that would also pose similar problems." >> >> Regards, Christian >> >> Colin Perkins wrote: >>> On 5 Jun 2007, at 02:40, Christian Groves wrote: >>>> The document Albrecht originally pointed to is now an Appendix to >>>> ITU-T H.248.49. This was done to ensure that Albrecht's work was >>>> captured. The latest draft can be found at: >>>> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-62.zip >>>> >>>> I think Randell's point that the use of "-" in attribute names >>>> between RFC2327 and RFC4566 should also be captured in the >>>> Appendix. Better that these sorts of issues are documented. >>>> Something along the lines of: >>>> >>>> >>>> "I.2.2.1 RFC 4566, “a=” attribute >>>> >>>> The syntax of RFC2327 does not support the use of “-“ in an >>>> attribute name however the syntax of RFC4566 has been updated to >>>> support the inclusion of “-“. Therefore the use of attribute names >>>> containing “-“ is problematic for RFC2327 implementations however >>>> several examples of attribute names containing “-“ were registered >>>> prior to the definition of RFC4566. RFC2327 Implementors may >>>> consider exceptions when parsing an “a=” where these attribute >>>> names containing “-“ are involved. " >>> >>> It's not that simple, since RFC 2327 is inconsistent. The ABNF >>> allows only alphanumeric characters in attribute names, but the text >>> only states that attribute names "must be in the US-ASCII subset of >>> ISO-10646/UTF-8". >>> >> >> _______________________________________________ >> 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 Jun 06 02:33:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvp5N-0004Q6-74; Wed, 06 Jun 2007 02:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvp5L-0004KH-FT; Wed, 06 Jun 2007 02:33:35 -0400 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 1Hvp5J-0004r1-2W; Wed, 06 Jun 2007 02:33:35 -0400 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] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed Date: Wed, 6 Jun 2007 09:34:12 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C049E78C5@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed Thread-Index: Acenh0L0V4NbyfevQQuzIOSQ/dMA4AAevHPg From: "Even, Roni" To: "Dave Singer" , "mmusic" , "IETF AVT WG" X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: "Clinton Priddle \(KI/EAB\)" 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 Dave, From your response: "No, these streams are not alternatives to each other in the regular sense. Nor is this really used in offer/answer; it's more an issue for multicast. In multicast, you open the tune-in stream and the base stream, grab the first I-frame that arrives (in either) and then drop the tune-in stream. Yes, we're aware that the recipient needs to be able to tell which is the base and which is the tune-in." Reading your application I will try to generalize it. To me you have two streams that have a relationship and there is semantics for the relation between the streams. You say that typically a user will only use the tune-in stream for synchronization; I would think that this can happen when joining the session or when losing synchronization.=20 In the general case these two streams are coming from the same source and the user may use one or the other. This is why I called them alternate streams After specifying the two streams (as alternate since the receiver may chose one or the other), you want to apply a specific semantics to the content of one stream (a repair stream). Again, I think that we need to specify the general mechanism for semantics to enable implementations from different vendors to understand what to do with the streams coming from the same source. In the current work at MMUSIC, the Label attribute (RFC 4574) define tags to a stream but with no semantics. The content attribute RFC 4796 defines semantic to a stream. I think that we now have a requirement for adding semantics to the relationship between streams; examples are the repair streams and the layered codecs. I think that by using grouping and dependency attributes we can define a general framework that will enable these general requirements and use them for the specific applications like repair stream, layered codecs and just alternate offers. Roni > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Tuesday, June 05, 2007 6:34 PM > To: Even, Roni; mmusic; IETF AVT WG > Cc: Clinton Priddle (KI/EAB) > Subject: RE: [MMUSIC] questions about grouping media streams in RTP and > SDP (RFC3388 etc), advice needed >=20 > At 10:03 +0300 5/06/07, Even, Roni wrote: > >Dave, > >For layered encoding there is a proposal for a new grouping attribute in > >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.t x > >t >=20 > I don't think this is a layered coding issue, either, alas. >=20 > >I looked at RFC3388 and I think that FID is not the answer to your > >requirement as you mentioned > > > >To me it looks like what you are looking for is a way to specify > >alternate offers. >=20 > No, these streams are not alternatives to each other in the regular > sense. Nor is this really used in offer/answer; it's more an issue > for multicast. In multicast, you open the tune-in stream and the > base stream, grab the first I-frame that arrives (in either) and then > drop the tune-in stream. >=20 > Yes, we're aware that the recipient needs to be able to tell which is > the base and which is the tune-in. >=20 > >If this is the case I have similar requirements and > >would be happy to support such work. > > > >You also need a way to give semantics to the "repair" stream, this can > >be done based on the content attribute from RFC 4796 or using a > >dependency attribute see in Schierl's draft. The mid tag is not enough > >for the receiver to know what you meant by this offer and which stream > >is the repair. > > > >Here is an example for a solution using a new Alternatives grouping > >attribute and giving semantics to the repair stream > > > >By using the grouping attribute in the offer you can know if the > >answerer understood the grouping since if he does not than he will send > >an answer with no a=3Dgroup > > > >v=3D0 > >o=3Dbob 280744730 28977631 IN IP4 host.example.com > >s=3D > >t=3D0 0 > > > >a=3Dgroup:ALTS 1 2 > >a=3Dgroup:ALTS 1 3 > > > >m=3Daudio 6886 RTP/AVP 0 > >c=3DIN IP6 2001:0600::1 > >a=3Dmid:1 > > > >m=3Dvideo 9000 RTP/AVP 100 > >c=3DIN IP4 192.0.2.2 > >a=3Drtpmap:100 H263-1998 > >a=3Dmid:2 > > > >m=3Dvideo 9002 RTP/AVP 101 > >c=3DIN IP4 192.0.2.2 > >a=3Drtpmap:101 H263-1998 > >a=3Dmid:3 > >a=3Dcontent:repair=3D2 or a=3Ddepend:repair=3D2 > > > > > >Roni Even > > > >> -----Original Message----- > >> From: Dave Singer [mailto:singer@apple.com] > >> Sent: Monday, June 04, 2007 7:19 PM > >> To: mmusic; IETF AVT WG > >> Cc: Clinton Priddle (KI/EAB) > >> Subject: [MMUSIC] questions about grouping media streams in RTP and > >SDP > >> (RFC3388 etc), advice needed > >> > >> Hi > >> > >> we have a need to group together two media streams, in the style of > >RFC > >> 3388 but we're unsure whether an > >> existing group type is suitable or not, and if it's not, we'd like to > >> agree on a new one, and document it (presumably in an RFC). > >> > >> What we have is a normal media stream, and a separate 'repair' or > >> 'entry' stream, that can be used when tuning in, or after loss, but is > >> otherwise un-needed. An example might be a video stream with a low > >> I-frame interval (say every 15 seconds), with a repair stream which > >has > >> only I-frames that are equivalent to the time-parallel non-I frame, at > >a > >> frequency of say 1 per second. > >> > >> It's not clear to us whether this is "one media flow" in the sense of > >> FID, or not. The example offers AMR and GSM audio, which are > >> alternatives, and DTMF tones along with audio, which are supplementary > >> to each other. Perhaps we fall afoul of this restriction: > >> > >> "An application that encodes the same media using different codecs > >> simultaneously MUST NOT use FID to group those media lines." > >> > >> or this one, for layered encoding: > >> > >> "FID MUST NOT be used to group "m" lines that do not represent the > >same > >> information." (Though how DTMF tones and their associated audio pass > >> this test is not clear). > >> > >> Nor is it clear that the FEC group of RFC 4756 is right, either. For > >a > >> start, we may wish to use this new ID in combination with FEC, and > >> secondly this tune-in stream has different characteristics. For > >> example, one can typically ignore all FEC and (as long as there are no > >> errors) decode the stream correctly. Ignoring the tune-in stream > > > entirely may mean that you will never find a tune-in point, making > the > >> normal stream useless. > >> > >> So, can we use FID for associating a repair stream with its base (we > >tag > >> the streams so we know which is which, of course)? > >> > >> p.s. RFC 4756 claims in the IANA section that the FEC group is > >> registered under SDP characteristics, but actually I can find no > >> registry anywhere in IANA of group types. > >> > >> > >> -- > >> David Singer > >> Apple/QuickTime > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 > -- > David Singer > Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jun 06 09:32:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvvcF-00043I-TX; Wed, 06 Jun 2007 09:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvvcF-00043D-38 for mmusic@ietf.org; Wed, 06 Jun 2007 09:31:59 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvvcC-0005jP-Nf for mmusic@ietf.org; Wed, 06 Jun 2007 09:31:59 -0400 Received: from [10.0.1.5] (adsl-68-94-0-43.dsl.rcsntx.swbell.net [68.94.0.43]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l56DVtDs005354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jun 2007 08:31:56 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <46657194.3060103@nsn.com> References: <46657194.3060103@nsn.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] File-transfer issue 37: mandating (or not) message/cpim Date: Wed, 6 Jun 2007 08:31:55 -0500 To: Miguel Garcia X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 68.94.0.43 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 On Jun 5, 2007, at 9:22 AM, Miguel Garcia wrote: > The current file-transfer draft does not explicitly indicates the > mandate for a message/cpim wrapper. There have been discussions > seeking for clarification on the level of requirement with respect > message/cpim. > > Here we rely on MSRP, which mandates the implementation of message/ > cpim but does not mandate its usage, except when one of the > endpoints is a CPIM gateway. Should the file-transfer draft mandate > it? > > I think mandating message/cpim at this stage will make our life > much easier in the future, for example, if we think of sending a > file on a multiparty connection, of via a CPIM gateway. However, > since it is not really mandated in MSRP, I am not sure what to say. > MSRP says: > > Furthermore, > when one endpoint of the session is a CPIM gateway, instant > messages > SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway > MUST > include "message/cpim" as the first entry in its SDP accept-types > attribute. MSRP endpoints sending instant messages to a peer that > has included "message/cpim" as the first entry in the accept-types > attribute SHOULD encapsulate all instant message bodies in > "message/ > cpim" wrappers. All MSRP endpoints MUST support the message/cpim > type, and SHOULD support the S/MIME[7] features of that format. > > Any views on this? Whatever is the decision, we should document it. > I'm not sure the potential for a CPIM gateway is as strong a motivator as it once was. However, message/cpim serves an additional purpose you do not mention, namely the association of "From" and other metadata with the content itself. This is useful for the multi- party conference case even without the presence of a CPIM gateway. But, for file transfer, I don't see a need to make this a stronger requirement than it is in MSRP base. My reasoning is that if either party needs message/cpim for one reason or another, it can signal that fact. If one of the parties is a conference focus or a gateway, it probably will--but that is not really a file-transfer issue per se. (Note that this is not a _strong_ opinion--I would not object to requiring it if we otherwise have a consensus to do so.) > /Miguel > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, 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 Wed Jun 06 09:41:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvvkw-0002kp-4w; Wed, 06 Jun 2007 09:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvvkv-0002kk-4F for mmusic@ietf.org; Wed, 06 Jun 2007 09:40:57 -0400 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 1Hvvku-000733-K1 for mmusic@ietf.org; Wed, 06 Jun 2007 09:40:57 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l56Des7J012620; Wed, 6 Jun 2007 16:40:54 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 16:40:45 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 16:40:45 +0300 Received: from [172.21.154.97] ([172.21.154.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 16:40:45 +0300 Message-ID: <4666B95D.2080907@nsn.com> Date: Wed, 06 Jun 2007 16:40:45 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ben Campbell Subject: Re: [MMUSIC] File-transfer issue 37: mandating (or not) message/cpim References: <46657194.3060103@nsn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2007 13:40:45.0376 (UTC) FILETIME=[48A90C00:01C7A840] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Ben: Thanks for the reply. I agree with you, there is a lot of recommendations and benefits, but not a compelling reason for mandating CPIM usage. I'll check the file-transfer draft and see if we need to add a reminder about the statements already written in the MSRP draft. /Miguel Ben Campbell wrote: > > On Jun 5, 2007, at 9:22 AM, Miguel Garcia wrote: > >> The current file-transfer draft does not explicitly indicates the >> mandate for a message/cpim wrapper. There have been discussions >> seeking for clarification on the level of requirement with respect >> message/cpim. >> >> Here we rely on MSRP, which mandates the implementation of >> message/cpim but does not mandate its usage, except when one of the >> endpoints is a CPIM gateway. Should the file-transfer draft mandate it? >> >> I think mandating message/cpim at this stage will make our life much >> easier in the future, for example, if we think of sending a file on a >> multiparty connection, of via a CPIM gateway. However, since it is not >> really mandated in MSRP, I am not sure what to say. MSRP says: >> >> Furthermore, >> when one endpoint of the session is a CPIM gateway, instant messages >> SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST >> include "message/cpim" as the first entry in its SDP accept-types >> attribute. MSRP endpoints sending instant messages to a peer that >> has included "message/cpim" as the first entry in the accept-types >> attribute SHOULD encapsulate all instant message bodies in "message/ >> cpim" wrappers. All MSRP endpoints MUST support the message/cpim >> type, and SHOULD support the S/MIME[7] features of that format. >> >> Any views on this? Whatever is the decision, we should document it. >> > > I'm not sure the potential for a CPIM gateway is as strong a motivator > as it once was. However, message/cpim serves an additional purpose you > do not mention, namely the association of "From" and other metadata with > the content itself. This is useful for the multi-party conference case > even without the presence of a CPIM gateway. > > But, for file transfer, I don't see a need to make this a stronger > requirement than it is in MSRP base. My reasoning is that if either > party needs message/cpim for one reason or another, it can signal that > fact. If one of the parties is a conference focus or a gateway, it > probably will--but that is not really a file-transfer issue per se. > > (Note that this is not a _strong_ opinion--I would not object to > requiring it if we otherwise have a consensus to do so.) > >> /Miguel >> >> --Miguel A. Garcia tel:+358-50-4804586 >> Nokia Siemens Networks Espoo, Finland >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 07 07:24:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwG69-0004qc-AT; Thu, 07 Jun 2007 07:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwG68-0004qB-18 for mmusic@ietf.org; Thu, 07 Jun 2007 07:24:12 -0400 Received: from lon-del-01.spheriq.net ([195.46.50.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwG65-0008By-GX for mmusic@ietf.org; Thu, 07 Jun 2007 07:24:12 -0400 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-01.spheriq.net with ESMTP id l57BO8vi030707 for ; Thu, 7 Jun 2007 11:24:08 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-02.spheriq.net with ESMTP id l57BO5xl031245 for ; Thu, 7 Jun 2007 11:24:07 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id l57BO3nK001954 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 7 Jun 2007 11:24:04 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C3564DA43; Thu, 7 Jun 2007 11:24:02 +0000 (GMT) Received: from mail4.agr.st.com (mail4.agr.st.com [164.130.4.70]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2F9754BE92; Thu, 7 Jun 2007 11:24:02 +0000 (GMT) Received: from [10.50.13.10] (agr2261.agr.st.com [10.50.13.10]) by mail4.agr.st.com (MOS 3.7.5a-GA) with ESMTP id BEW00847 (AUTH "andrea vitali"); Thu, 7 Jun 2007 13:24:00 +0200 (CEST) Message-ID: <4667EAD0.9020803@st.com> Date: Thu, 07 Jun 2007 13:24:00 +0200 From: Andrea Lorenzo VITALI User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dave Singer References: <465C0342.3010602@nsn.com> <7374777208BDC7449D5620EF9423256704991181@esealmw113.eemea.ericsson.se> <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------010307080304080600030909" X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.04 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: "Clinton Priddle \(KI/EAB\)" , mmusic , IETF AVT WG Subject: [MMUSIC] Re: [AVT] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed 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. --------------010307080304080600030909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit RFC3388 tagging/grouping cannot be used - simultaneous encoding is explicitly forbidden (no Multiple Description Coding) - grouping of layers explicitly forbidden (no Layered Coding) I talked about this in my presentation at IETF (page 6): http://www3.ietf.org/proceedings/05nov/slides/avt-3.pdf My presentation was about standard-compatible Multiple Description Coding (MDC). You can find the draft here: http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-vitali-ietf-avt-mdc-lc-00.txt Your scheme is in fact an unbalanced multiple description coding scheme, isn't it? You transmit the full video and a low-resolution video to be used for concealment (1+1/4). The question of dependency between streams has also been raised for the new Scalable Video Codec (SVC). Andrea Dave Singer wrote: > Hi > > we have a need to group together two media streams, in the style of RFC > 3388 but we're unsure whether an > existing group type is suitable or not, and if it's not, we'd like to > agree on a new one, and document it (presumably in an RFC). > > What we have is a normal media stream, and a separate 'repair' or > 'entry' stream, that can be used when tuning in, or after loss, but is > otherwise un-needed. An example might be a video stream with a low > I-frame interval (say every 15 seconds), with a repair stream which has > only I-frames that are equivalent to the time-parallel non-I frame, at a > frequency of say 1 per second. > > It's not clear to us whether this is "one media flow" in the sense of > FID, or not. The example offers AMR and GSM audio, which are > alternatives, and DTMF tones along with audio, which are supplementary > to each other. Perhaps we fall afoul of this restriction: > > "An application that encodes the same media using different codecs > simultaneously MUST NOT use FID to group those media lines." > > or this one, for layered encoding: > > "FID MUST NOT be used to group "m" lines that do not represent the same > information." (Though how DTMF tones and their associated audio pass > this test is not clear). > > Nor is it clear that the FEC group of RFC 4756 is right, either. For a > start, we may wish to use this new ID in combination with FEC, and > secondly this tune-in stream has different characteristics. For > example, one can typically ignore all FEC and (as long as there are no > errors) decode the stream correctly. Ignoring the tune-in stream > entirely may mean that you will never find a tune-in point, making the > normal stream useless. > > So, can we use FID for associating a repair stream with its base (we tag > the streams so we know which is which, of course)? > > p.s. RFC 4756 claims in the IANA section that the FEC group is > registered under SDP characteristics, but actually I can find no > registry anywhere in IANA of group types. > > -- ______________________________________________________________ Andrea VITALI andrea.vitali@st.com tel (+39) 039 603 7244 mobile (+39) 347 93 08 433 fax (+39) 039 603 6129 STMicroelectronics Centro Direzionale COLLEONI - Palazzo "DIALETTICA" 20041 Agrate Brianza (MI) ITALY ______________________________________________________________ --------------010307080304080600030909 Content-Type: text/x-vcard; charset=utf-8; name="andrea.vitali.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="andrea.vitali.vcf" begin:vcard fn:Andrea Vitali n:Vitali;Andrea email;internet:andrea.vitali@st.com tel;work:+39 039 603 7244 tel;fax:+39 039 603 6129 tel;home:+39 035 34 08 14 tel;cell:+39 347 93 08 433 x-mozilla-html:FALSE version:2.1 end:vcard --------------010307080304080600030909 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 --------------010307080304080600030909-- From mmusic-bounces@ietf.org Thu Jun 07 11:22:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJp1-0005uA-QY; Thu, 07 Jun 2007 11:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJp0-0005ty-LG for mmusic@ietf.org; Thu, 07 Jun 2007 11:22:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJoy-0005rK-Bl for mmusic@ietf.org; Thu, 07 Jun 2007 11:22:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Jun 2007 11:22:44 -0400 X-IronPort-AV: i="4.16,395,1175486400"; d="scan'208"; a="62203804:sNHT48495000" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l57FMi45009334; Thu, 7 Jun 2007 11:22:44 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l57FMb5j014063; Thu, 7 Jun 2007 15:22:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 11:22:34 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 11:22:34 -0400 Message-ID: <466822B8.6040609@cisco.com> Date: Thu, 07 Jun 2007 11:22:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [MMUSIC] File transfer version -03 References: <46657005.4040802@nsn.com> In-Reply-To: <46657005.4040802@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 15:22:34.0558 (UTC) FILETIME=[AC6DFDE0:01C7A917] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2651; t=1181229764; x=1182093764; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20File=20transfer=20version=20-03 |Sender:=20 |To:=20Miguel=20Garcia=20; bh=K2geMtkM5+k+MEcz2xi7Fd54qFiJu9XPsJ86kO9ew8Y=; b=ayDJrqezbgPYIkSe6hjGhy6BaBvKfqJuRR7llEc8u+jUCeEYYL17NM/sEJN+NmU4IxWpF3mK IZuAiOosFdsXtccxrp2uLR+Geoct6Jons4hq8S1FkkOiOaFjaanxlA3c; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Miguel, This has resolved the issues I had. I did come across a few minor points: - the syntax of filename-string does not address escaping, yet there is mention elsewhere of percent encoding filenames that contain quotes. I think you need something more like the following (adapted from 3261): percent-encoded = "%" HEXDIG HEXDIG filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF ;any byte except NUL, CR, LF, double quotes, or percent filename-string = 1*(filename-char/percent-encoded) - it might be good to clarify, somewhere, that the hash is computed over the *entire* file, even if the transfer is only for a file-range. This may be obvious, but maybe not. One place to do this might be as a NOTE near the description of the 'hash' selector in section 6. - section 8.1.1 doesn't say what the offerer should do after receiving the answer. Perhaps this is obvious, but its inconsistent with the other sections. That's all. Thanks, Paul Miguel Garcia wrote: > Hi: > > I have just submitted version -03 of the file transfer mechanism draft. > Until it becomes available in your favorite repository, you can fetch a > copy from: > > http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03.txt > > http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03.html > > > A diff version is also available: > http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03-from-2.html > > > These are the changes in this version: > - new attribute 'file-transfer'. It determines whether a "new" file > transfer is requested, or the SDP is there because of an "existing" file > transfer. > - ABNF in name selector considers double quotes now. > - ABNF of hash changes to be equal to RFC 4572 (Comedia). > - File disposition 'not-render' is now 'attachment'. No need to invent a > new disposition value. > - Hash of file is locally computed and checked for errors with that in > the SDP. > - All available hash algorithms are sent. > - Clarifications on the usage of the max-size attribute in MSRP > - Added considerations about the 'file-icon' attribute and their > requirements for multipart MIME bodies. > > Other minor changes: > - Addition of definitions of Push and Pull operations > - Clarification that the file selector need not contain all four selectors > > To my knowledge, this completes the round of discussions we had in the > past. There is only one open issue that I will be discussing in a > separate thread. > > BR, > > Miguel _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 07 12:25:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKny-0008Ja-5t; Thu, 07 Jun 2007 12:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKnw-0008Fu-T3; Thu, 07 Jun 2007 12:25:44 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKnv-0006Bt-V2; Thu, 07 Jun 2007 12:25:44 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (Postfix) with ESMTP id E5E4582199C; Thu, 7 Jun 2007 09:24:45 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 7AA8429C002; Thu, 7 Jun 2007 09:25:43 -0700 (PDT) X-AuditID: 11807123-9d81dbb000000a23-7c-466831860d72 Received: from [17.202.35.52] (unknown [17.219.197.38]) by relay5.apple.com (Apple SCV relay) with ESMTP id 130A030400B; Thu, 7 Jun 2007 09:25:41 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4667EAD0.9020803@st.com> References: <465C0342.3010602@nsn.com> <7374777208BDC7449D5620EF9423256704991181@esealmw113.eemea.ericsson.se> <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> <4667EAD0.9020803@st.com> Date: Thu, 7 Jun 2007 09:24:42 -0700 To: Andrea Lorenzo VITALI From: Dave Singer X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.3 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: "Clinton Priddle \(KI/EAB\)" , mmusic , IETF AVT WG Subject: [MMUSIC] Re: [AVT] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed 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="===============0185259682==" Errors-To: mmusic-bounces@ietf.org --===============0185259682== Content-Type: multipart/alternative; boundary="============_-1030888954==_ma============" --============_-1030888954==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 13:24 +0200 7/06/07, Andrea Lorenzo VITALI wrote: >RFC3388 tagging/grouping cannot be used > > - simultaneous encoding is explicitly forbidden (no Multiple >Description Coding) > > - grouping of layers explicitly forbidden (no Layered Coding) Yes, I think it does seem that FID can't be used, though frankly the reasons for these restrictions are really unclear to me. It's also not clear to me how DTMF tones pass their own tests (see below), but that's not terribly relevant. > >I talked about this in my presentation at IETF (page 6): >http://www3.ietf.org/proceedings/05nov/slides/avt-3.pdf > >My presentation was about standard-compatible Multiple Description >Coding (MDC). You can find the draft here: >http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-vitali-ietf-avt-mdc-lc-00.txt > >Your scheme is in fact an unbalanced multiple description coding scheme, >isn't it? You transmit the full video and a low-resolution video to be >used for concealment (1+1/4). It's similar; we're actually in a different coding system (not video), but the video is a good analog. > >The question of dependency between streams has also been raised for the >new Scalable Video Codec (SVC). Yes, I work on that too. Is it possible we can agree fairly soon on the group ID for grouping media lines of the same codec, where the client terminal chooses which of the media streams it needs, and when, by examining their other characteristics? Examples would be layered coding, or repair coding. Here's an example: v=0 o=adam 289083124 289083124 IN IP4 host.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:group_name 1 2 m=video 30000 RTP/AVP 97 a=rtpmap:97 coding-system/90000 a=fmtp:97 contains-redundant="normal" a=mid:1 m=video 30002 RTP/AVP 98 a=rtpmap:98 coding-system/90000 a=fmtp:98 contains-redundant="redundant" a=mid:2 The question is, what is the "group_name" here? And once we agree on the code, do we need an RFC? Is the space of covered applications just these two: repair and layered coding? > > Andrea > > >Dave Singer wrote: >> Hi >> >> we have a need to group together two media streams, in the style of RFC >> 3388 but we're unsure whether an >> existing group type is suitable or not, and if it's not, we'd like to >> agree on a new one, and document it (presumably in an RFC). >> >> What we have is a normal media stream, and a separate 'repair' or >> 'entry' stream, that can be used when tuning in, or after loss, but is >> otherwise un-needed. An example might be a video stream with a low >> I-frame interval (say every 15 seconds), with a repair stream which has >> only I-frames that are equivalent to the time-parallel non-I frame, at a >> frequency of say 1 per second. >> >> It's not clear to us whether this is "one media flow" in the sense of >> FID, or not. The example offers AMR and GSM audio, which are >> alternatives, and DTMF tones along with audio, which are supplementary >> to each other. Perhaps we fall afoul of this restriction: >> >> "An application that encodes the same media using different codecs >> simultaneously MUST NOT use FID to group those media lines." >> >> or this one, for layered encoding: >> >> "FID MUST NOT be used to group "m" lines that do not represent the same >> information." (Though how DTMF tones and their associated audio pass >> this test is not clear). >> >> Nor is it clear that the FEC group of RFC 4756 is right, either. For a >> start, we may wish to use this new ID in combination with FEC, and >> secondly this tune-in stream has different characteristics. For >> example, one can typically ignore all FEC and (as long as there are no >> errors) decode the stream correctly. Ignoring the tune-in stream >> entirely may mean that you will never find a tune-in point, making the > > normal stream useless. >> >> So, can we use FID for associating a repair stream with its base (we tag >> the streams so we know which is which, of course)? >> >> p.s. RFC 4756 claims in the IANA section that the FEC group is >> registered under SDP characteristics, but actually I can find no >> registry anywhere in IANA of group types. >> >> > >-- > ______________________________________________________________ > > Andrea VITALI andrea.vitali@st.com > > tel (+39) 039 603 7244 mobile (+39) 347 93 08 433 > fax (+39) 039 603 6129 > > STMicroelectronics > Centro Direzionale COLLEONI - Palazzo "DIALETTICA" > 20041 Agrate Brianza (MI) ITALY > ______________________________________________________________ > >Attachment converted: DaveG49:andrea.vitali.vcf (TEXT/ttxt) (000CDBBA) -- David Singer Apple/QuickTime --============_-1030888954==_ma============ Content-Type: text/html; charset="us-ascii" Re: [AVT] questions about grouping media streams in RTP an
At 13:24  +0200 7/06/07, Andrea Lorenzo VITALI wrote:
RFC3388 tagging/grouping cannot be used

  - simultaneous encoding is explicitly forbidden (no Multiple
Description Coding)

  - grouping of layers explicitly forbidden (no Layered Coding)

Yes, I think it does seem that FID can't be used, though frankly the reasons for these restrictions are really unclear to me.  It's also not clear to me how DTMF tones pass their own tests (see below), but that's not terribly relevant.


I talked about this in my presentation at IETF (page 6):
http://www3.ietf.org/proceedings/05nov/slides/avt-3.pdf

My presentation was about standard-compatible Multiple Description
Coding (MDC). You can find the draft here:
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-vitali-ietf-avt-mdc-lc-00.txt

Your scheme is in fact an unbalanced multiple description coding scheme,
isn't it? You transmit the full video and a low-resolution video to be
used for concealment (1+1/4).

It's similar;  we're actually in a different coding system (not video), but the video is a good analog.


The question of dependency between streams has also been raised for the
new Scalable Video Codec (SVC).

Yes, I work on that too.

Is it possible we can agree fairly soon on the group ID for grouping media lines of the same codec, where the client terminal chooses which of the media streams it needs, and when, by examining their other characteristics?  Examples would be layered coding, or repair coding.

Here's an example:

v=0
o=adam 289083124 289083124 IN IP4 host.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:group_name 1 2
m=video 30000 RTP/AVP 97
a=rtpmap:97 coding-system/90000
a=fmtp:97 contains-redundant="normal"
a=mid:1
m=video 30002 RTP/AVP 98
a=rtpmap:98 coding-system/90000
a=fmtp:98 contains-redundant="redundant"
a=mid:2
The question is, what is the "group_name" here?  And once we agree on the code, do we need an RFC?

Is the space of covered applications just these two:  repair and layered coding?



  Andrea


Dave Singer wrote:
> Hi
>
> we have a need to group together two media streams, in the style of RFC
> 3388 <http://www.ietf.org/rfc/rfc3388.txt> but we're unsure whether an
> existing group type is suitable or not, and if it's not, we'd like to
> agree on a new one, and document it (presumably in an RFC).
>
> What we have is a normal media stream, and a separate 'repair' or
> 'entry' stream, that can be used when tuning in, or after loss, but is
> otherwise un-needed.  An example might be a video stream with a low
> I-frame interval (say every 15 seconds), with a repair stream which has
> only I-frames that are equivalent to the time-parallel non-I frame, at a
> frequency of say 1 per second.
>
> It's not clear to us whether this is "one media flow" in the sense of
> FID, or not.  The example offers AMR and GSM audio, which are
> alternatives, and DTMF tones along with audio, which are supplementary
> to each other.  Perhaps we fall afoul of this restriction:
>
> "An application that encodes the same media using different codecs
> simultaneously MUST NOT use FID to group those media lines."
>
> or this one, for layered encoding:
>
> "FID MUST NOT be used to group "m" lines that do not represent the same
> information."  (Though how DTMF tones and their associated audio pass
> this test is not clear).
>
> Nor is it clear that the FEC group of RFC 4756 is right, either.  For a
> start, we may wish to use this new ID in combination with FEC, and
> secondly this tune-in stream has different characteristics.  For
> example, one can typically ignore all FEC and (as long as there are no
> errors) decode the stream correctly.  Ignoring the tune-in stream
> entirely may mean that you will never find a tune-in point, making the
> normal stream useless.
>
> So, can we use FID for associating a repair stream with its base (we tag
> the streams so we know which is which, of course)?
>
> p.s. RFC 4756 claims in the IANA section that the FEC group is
> registered under SDP characteristics, but actually I can find no
> registry anywhere in IANA of group types.
>
>

--
 ______________________________________________________________

  Andrea VITALI                            andrea.vitali@st.com

  tel (+39) 039 603 7244             mobile (+39) 347 93 08 433
  fax (+39) 039 603 6129

  STMicroelectronics
  Centro Direzionale COLLEONI - Palazzo "DIALETTICA"
  20041 Agrate Brianza (MI) ITALY
 ______________________________________________________________

Attachment converted: DaveG49:andrea.vitali.vcf (TEXT/ttxt) (000CDBBA)


--
David Singer
Apple/QuickTime
--============_-1030888954==_ma============-- --===============0185259682== 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 --===============0185259682==-- From mmusic-bounces@ietf.org Thu Jun 07 13:46:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwM45-0001Jx-W6; Thu, 07 Jun 2007 13:46:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwM43-0001Jk-Sw; Thu, 07 Jun 2007 13:46:27 -0400 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwM43-0002X7-A6; Thu, 07 Jun 2007 13:46:27 -0400 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id CBF521D88F70; Thu, 7 Jun 2007 19:46:26 +0200 (CEST) Received: from ipam040189 (ipam189.Stanford.EDU [171.64.92.89]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id 69A991D88F50; Thu, 7 Jun 2007 19:46:22 +0200 (CEST) From: "Thomas Schierl" To: "'Dave Singer'" , "'Even, Roni'" , "'mmusic'" , "'IETF AVT WG'" References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Date: Thu, 7 Jun 2007 10:46:11 -0700 Organization: HHI/FhG Message-ID: <000101c7a92b$c4752d50$595c40ab@ipam040189> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcenhyxcbwKgryeQTM2S+JPzrTemewBpEXzg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, hits=-104.9 required=5.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64 X-alterMIME: Yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: "'Clinton Priddle \(KI/EAB\)'" , Stephan.Wenger@nokia.com 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 Dave, I think there is a strong relation of your problem and the http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.txt In this draft, we described media dependency in general, not only for scalable video. Currently, two types of dependencies are defined: layered and mdc assuming the media is partially transported in different RTP sessions. There is not requirement, that the part of the media is independently decodable. It would be easy to integrate your needs, if they should not be already covered. Thomas > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Tuesday, June 05, 2007 8:34 AM > To: Even, Roni; mmusic; IETF AVT WG > Cc: Clinton Priddle (KI/EAB) > Subject: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP > andSDP (RFC3388 etc), advice needed > > At 10:03 +0300 5/06/07, Even, Roni wrote: > >Dave, > >For layered encoding there is a proposal for a new grouping attribute in > >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx > >t > > I don't think this is a layered coding issue, either, alas. > > >I looked at RFC3388 and I think that FID is not the answer to your > >requirement as you mentioned > > > >To me it looks like what you are looking for is a way to specify > >alternate offers. > > No, these streams are not alternatives to each other in the regular > sense. Nor is this really used in offer/answer; it's more an issue > for multicast. In multicast, you open the tune-in stream and the > base stream, grab the first I-frame that arrives (in either) and then > drop the tune-in stream. > > Yes, we're aware that the recipient needs to be able to tell which is > the base and which is the tune-in. > > >If this is the case I have similar requirements and > >would be happy to support such work. > > > >You also need a way to give semantics to the "repair" stream, this can > >be done based on the content attribute from RFC 4796 or using a > >dependency attribute see in Schierl's draft. The mid tag is not enough > >for the receiver to know what you meant by this offer and which stream > >is the repair. > > > >Here is an example for a solution using a new Alternatives grouping > >attribute and giving semantics to the repair stream > > > >By using the grouping attribute in the offer you can know if the > >answerer understood the grouping since if he does not than he will send > >an answer with no a=group > > > >v=0 > >o=bob 280744730 28977631 IN IP4 host.example.com > >s= > >t=0 0 > > > >a=group:ALTS 1 2 > >a=group:ALTS 1 3 > > > >m=audio 6886 RTP/AVP 0 > >c=IN IP6 2001:0600::1 > >a=mid:1 > > > >m=video 9000 RTP/AVP 100 > >c=IN IP4 192.0.2.2 > >a=rtpmap:100 H263-1998 > >a=mid:2 > > > >m=video 9002 RTP/AVP 101 > >c=IN IP4 192.0.2.2 > >a=rtpmap:101 H263-1998 > >a=mid:3 > >a=content:repair=2 or a=depend:repair=2 > > > > > >Roni Even > > > >> -----Original Message----- > >> From: Dave Singer [mailto:singer@apple.com] > >> Sent: Monday, June 04, 2007 7:19 PM > >> To: mmusic; IETF AVT WG > >> Cc: Clinton Priddle (KI/EAB) > >> Subject: [MMUSIC] questions about grouping media streams in RTP and > >SDP > >> (RFC3388 etc), advice needed > >> > >> Hi > >> > >> we have a need to group together two media streams, in the style of > >RFC > >> 3388 but we're unsure whether an > >> existing group type is suitable or not, and if it's not, we'd like to > >> agree on a new one, and document it (presumably in an RFC). > >> > >> What we have is a normal media stream, and a separate 'repair' or > >> 'entry' stream, that can be used when tuning in, or after loss, but is > >> otherwise un-needed. An example might be a video stream with a low > >> I-frame interval (say every 15 seconds), with a repair stream which > >has > >> only I-frames that are equivalent to the time-parallel non-I frame, at > >a > >> frequency of say 1 per second. > >> > >> It's not clear to us whether this is "one media flow" in the sense of > >> FID, or not. The example offers AMR and GSM audio, which are > >> alternatives, and DTMF tones along with audio, which are supplementary > >> to each other. Perhaps we fall afoul of this restriction: > >> > >> "An application that encodes the same media using different codecs > >> simultaneously MUST NOT use FID to group those media lines." > >> > >> or this one, for layered encoding: > >> > >> "FID MUST NOT be used to group "m" lines that do not represent the > >same > >> information." (Though how DTMF tones and their associated audio pass > >> this test is not clear). > >> > >> Nor is it clear that the FEC group of RFC 4756 is right, either. For > >a > >> start, we may wish to use this new ID in combination with FEC, and > >> secondly this tune-in stream has different characteristics. For > >> example, one can typically ignore all FEC and (as long as there are no > >> errors) decode the stream correctly. Ignoring the tune-in stream > > > entirely may mean that you will never find a tune-in point, making > the > >> normal stream useless. > >> > >> So, can we use FID for associating a repair stream with its base (we > >tag > >> the streams so we know which is which, of course)? > >> > >> p.s. RFC 4756 claims in the IANA section that the FEC group is > >> registered under SDP characteristics, but actually I can find no > >> registry anywhere in IANA of group types. > >> > >> > >> -- > >> David Singer > >> Apple/QuickTime > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > > > -- > David Singer > Apple/QuickTime > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 07 13:49:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwM7A-0001xI-0r; Thu, 07 Jun 2007 13:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwM78-0001wk-0o; Thu, 07 Jun 2007 13:49:38 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwM77-0003DB-E8; Thu, 07 Jun 2007 13:49:38 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id 5F3CB82384E; Thu, 7 Jun 2007 10:48:39 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 12EA8300AE; Thu, 7 Jun 2007 10:49:37 -0700 (PDT) X-AuditID: 11807125-9f763bb000000801-29-4668453059cf Received: from [17.202.35.52] (unknown [17.219.197.38]) by relay7.apple.com (Apple SCV relay) with ESMTP id 4F5B730044; Thu, 7 Jun 2007 10:49:36 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <000001c7a92a$f3aefac0$595c40ab@ipam040189> References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com> <000001c7a92a$f3aefac0$595c40ab@ipam040189> Date: Thu, 7 Jun 2007 10:49:08 -0700 To: Thomas Schierl From: Dave Singer Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: "'Even, Roni'" , Stephan.Wenger@nokia.com, 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 At 10:40 -0700 7/06/07, Thomas Schierl wrote: >Hi Dave, > >I think there is a strong relation of your problem and the >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.txt . >In this draft, we described media dependency in general, not only for >scalable video. Currently, two types of dependencies are defined: layered >and mdc assuming the media is partially transported in different RTP >sessions. It would be easy to integrate your needs, if they should not be >already covered. > > >Thomas Thank you. I agree the problems are identical, or close to it. Do you think we should use 'lay' or 'mdc', or a new dependency type? Or integrate a new group type into the draft (is 'DDP' right for our application)? > >> -----Original Message----- >> From: Dave Singer [mailto:singer@apple.com] >> Sent: Tuesday, June 05, 2007 8:34 AM >> To: Even, Roni; mmusic; IETF AVT WG >> Cc: Clinton Priddle (KI/EAB) >> Subject: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP >> andSDP (RFC3388 etc), advice needed >> >> At 10:03 +0300 5/06/07, Even, Roni wrote: >> >Dave, >> >For layered encoding there is a proposal for a new grouping attribute in >> >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx >> >t >> >> I don't think this is a layered coding issue, either, alas. >> >> >I looked at RFC3388 and I think that FID is not the answer to your >> >requirement as you mentioned >> > >> >To me it looks like what you are looking for is a way to specify >> >alternate offers. >> >> No, these streams are not alternatives to each other in the regular >> sense. Nor is this really used in offer/answer; it's more an issue >> for multicast. In multicast, you open the tune-in stream and the >> base stream, grab the first I-frame that arrives (in either) and then >> drop the tune-in stream. >> >> Yes, we're aware that the recipient needs to be able to tell which is >> the base and which is the tune-in. >> >> >If this is the case I have similar requirements and >> >would be happy to support such work. >> > >> >You also need a way to give semantics to the "repair" stream, this can >> >be done based on the content attribute from RFC 4796 or using a >> >dependency attribute see in Schierl's draft. The mid tag is not enough >> >for the receiver to know what you meant by this offer and which stream >> >is the repair. >> > >> >Here is an example for a solution using a new Alternatives grouping >> >attribute and giving semantics to the repair stream >> > >> >By using the grouping attribute in the offer you can know if the >> >answerer understood the grouping since if he does not than he will send >> >an answer with no a=group >> > >> >v=0 >> >o=bob 280744730 28977631 IN IP4 host.example.com >> >s= >> >t=0 0 >> > >> >a=group:ALTS 1 2 >> >a=group:ALTS 1 3 >> > >> >m=audio 6886 RTP/AVP 0 >> >c=IN IP6 2001:0600::1 >> >a=mid:1 >> > >> >m=video 9000 RTP/AVP 100 >> >c=IN IP4 192.0.2.2 >> >a=rtpmap:100 H263-1998 >> >a=mid:2 >> > >> >m=video 9002 RTP/AVP 101 >> >c=IN IP4 192.0.2.2 >> >a=rtpmap:101 H263-1998 >> >a=mid:3 >> >a=content:repair=2 or a=depend:repair=2 >> > >> > >> >Roni Even >> > >> >> -----Original Message----- >> >> From: Dave Singer [mailto:singer@apple.com] >> >> Sent: Monday, June 04, 2007 7:19 PM >> >> To: mmusic; IETF AVT WG >> >> Cc: Clinton Priddle (KI/EAB) >> >> Subject: [MMUSIC] questions about grouping media streams in RTP and >> >SDP >> >> (RFC3388 etc), advice needed >> >> >> >> Hi >> >> >> >> we have a need to group together two media streams, in the style of >> >RFC >> >> 3388 but we're unsure whether an >> >> existing group type is suitable or not, and if it's not, we'd like to >> >> agree on a new one, and document it (presumably in an RFC). >> >> >> >> What we have is a normal media stream, and a separate 'repair' or > > >> 'entry' stream, that can be used when tuning in, or after loss, but is >> >> otherwise un-needed. An example might be a video stream with a low >> >> I-frame interval (say every 15 seconds), with a repair stream which >> >has >> >> only I-frames that are equivalent to the time-parallel non-I frame, at >> >a >> >> frequency of say 1 per second. >> >> >> >> It's not clear to us whether this is "one media flow" in the sense of >> >> FID, or not. The example offers AMR and GSM audio, which are >> >> alternatives, and DTMF tones along with audio, which are supplementary >> >> to each other. Perhaps we fall afoul of this restriction: >> >> >> >> "An application that encodes the same media using different codecs >> >> simultaneously MUST NOT use FID to group those media lines." >> >> >> >> or this one, for layered encoding: >> >> >> >> "FID MUST NOT be used to group "m" lines that do not represent the >> >same >> >> information." (Though how DTMF tones and their associated audio pass >> >> this test is not clear). >> >> >> >> Nor is it clear that the FEC group of RFC 4756 is right, either. For >> >a >> >> start, we may wish to use this new ID in combination with FEC, and >> >> secondly this tune-in stream has different characteristics. For >> >> example, one can typically ignore all FEC and (as long as there are no >> >> errors) decode the stream correctly. Ignoring the tune-in stream >> > > entirely may mean that you will never find a tune-in point, making >> the >> >> normal stream useless. >> >> >> >> So, can we use FID for associating a repair stream with its base (we >> >tag >> >> the streams so we know which is which, of course)? >> >> >> >> p.s. RFC 4756 claims in the IANA section that the FEC group is >> >> registered under SDP characteristics, but actually I can find no >> >> registry anywhere in IANA of group types. >> >> >> >> >> >> -- >> >> David Singer >> >> Apple/QuickTime >> >> >> >> _______________________________________________ >> >> mmusic mailing list >> >> mmusic@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> -- >> David Singer >> Apple/QuickTime >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt -- David Singer Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 07 16:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwOF8-0005XW-KZ; Thu, 07 Jun 2007 16:06:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwOF6-0005XM-Rm; Thu, 07 Jun 2007 16:06:00 -0400 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 1HwOF5-0000lX-Oh; Thu, 07 Jun 2007 16:06:00 -0400 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: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Date: Thu, 7 Jun 2007 23:06:45 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C049E7C50@IsrExch01.israel.polycom.com> In-Reply-To: <000101c7a92b$c4752d50$595c40ab@ipam040189> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Thread-Index: AcenhyxcbwKgryeQTM2S+JPzrTemewBpEXzgAATpg+A= From: "Even, Roni" To: "Thomas Schierl" , "Dave Singer" , "mmusic" , "IETF AVT WG" X-Spam-Score: 0.1 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: "Clinton Priddle \(KI/EAB\)" , Stephan.Wenger@nokia.com 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, My view is that you have similarity in the need for dependencies between streams but the grouping logic is different. In the layered codec the grouping is for a group that you can use all or part of while in the repair case you may take one or the other. Roni Even > -----Original Message----- > From: Thomas Schierl [mailto:schierl@hhi.fhg.de] > Sent: Thursday, June 07, 2007 8:46 PM > To: 'Dave Singer'; Even, Roni; 'mmusic'; 'IETF AVT WG' > Cc: Stephan.Wenger@nokia.com; 'Clinton Priddle (KI/EAB)' > Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams in > RTP andSDP (RFC3388 etc), advice needed >=20 > Hi Dave, >=20 > I think there is a strong relation of your problem and the > http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx t > In this draft, we described media dependency in general, not only for > scalable video. Currently, two types of dependencies are defined: layered > and mdc assuming the media is partially transported in different RTP > sessions. There is not requirement, that the part of the media is > independently decodable. It would be easy to integrate your needs, if they > should not be already covered. >=20 >=20 > Thomas >=20 > > -----Original Message----- > > From: Dave Singer [mailto:singer@apple.com] > > Sent: Tuesday, June 05, 2007 8:34 AM > > To: Even, Roni; mmusic; IETF AVT WG > > Cc: Clinton Priddle (KI/EAB) > > Subject: [AVT] RE: [MMUSIC] questions about grouping media streams in > RTP > > andSDP (RFC3388 etc), advice needed > > > > At 10:03 +0300 5/06/07, Even, Roni wrote: > > >Dave, > > >For layered encoding there is a proposal for a new grouping attribute > in > > >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec- > 03.tx > > >t > > > > I don't think this is a layered coding issue, either, alas. > > > > >I looked at RFC3388 and I think that FID is not the answer to your > > >requirement as you mentioned > > > > > >To me it looks like what you are looking for is a way to specify > > >alternate offers. > > > > No, these streams are not alternatives to each other in the regular > > sense. Nor is this really used in offer/answer; it's more an issue > > for multicast. In multicast, you open the tune-in stream and the > > base stream, grab the first I-frame that arrives (in either) and then > > drop the tune-in stream. > > > > Yes, we're aware that the recipient needs to be able to tell which is > > the base and which is the tune-in. > > > > >If this is the case I have similar requirements and > > >would be happy to support such work. > > > > > >You also need a way to give semantics to the "repair" stream, this can > > >be done based on the content attribute from RFC 4796 or using a > > >dependency attribute see in Schierl's draft. The mid tag is not enough > > >for the receiver to know what you meant by this offer and which stream > > >is the repair. > > > > > >Here is an example for a solution using a new Alternatives grouping > > >attribute and giving semantics to the repair stream > > > > > >By using the grouping attribute in the offer you can know if the > > >answerer understood the grouping since if he does not than he will send > > >an answer with no a=3Dgroup > > > > > >v=3D0 > > >o=3Dbob 280744730 28977631 IN IP4 host.example.com > > >s=3D > > >t=3D0 0 > > > > > >a=3Dgroup:ALTS 1 2 > > >a=3Dgroup:ALTS 1 3 > > > > > >m=3Daudio 6886 RTP/AVP 0 > > >c=3DIN IP6 2001:0600::1 > > >a=3Dmid:1 > > > > > >m=3Dvideo 9000 RTP/AVP 100 > > >c=3DIN IP4 192.0.2.2 > > >a=3Drtpmap:100 H263-1998 > > >a=3Dmid:2 > > > > > >m=3Dvideo 9002 RTP/AVP 101 > > >c=3DIN IP4 192.0.2.2 > > >a=3Drtpmap:101 H263-1998 > > >a=3Dmid:3 > > >a=3Dcontent:repair=3D2 or a=3Ddepend:repair=3D2 > > > > > > > > >Roni Even > > > > > >> -----Original Message----- > > >> From: Dave Singer [mailto:singer@apple.com] > > >> Sent: Monday, June 04, 2007 7:19 PM > > >> To: mmusic; IETF AVT WG > > >> Cc: Clinton Priddle (KI/EAB) > > >> Subject: [MMUSIC] questions about grouping media streams in RTP and > > >SDP > > >> (RFC3388 etc), advice needed > > >> > > >> Hi > > >> > > >> we have a need to group together two media streams, in the style of > > >RFC > > >> 3388 but we're unsure whether > an > > >> existing group type is suitable or not, and if it's not, we'd like > to > > >> agree on a new one, and document it (presumably in an RFC). > > >> > > >> What we have is a normal media stream, and a separate 'repair' or > > >> 'entry' stream, that can be used when tuning in, or after loss, but > is > > >> otherwise un-needed. An example might be a video stream with a low > > >> I-frame interval (say every 15 seconds), with a repair stream which > > >has > > >> only I-frames that are equivalent to the time-parallel non-I frame, > at > > >a > > >> frequency of say 1 per second. > > >> > > >> It's not clear to us whether this is "one media flow" in the sense > of > > >> FID, or not. The example offers AMR and GSM audio, which are > > >> alternatives, and DTMF tones along with audio, which are > supplementary > > >> to each other. Perhaps we fall afoul of this restriction: > > >> > > >> "An application that encodes the same media using different codecs > > >> simultaneously MUST NOT use FID to group those media lines." > > >> > > >> or this one, for layered encoding: > > >> > > >> "FID MUST NOT be used to group "m" lines that do not represent the > > >same > > >> information." (Though how DTMF tones and their associated audio > pass > > >> this test is not clear). > > >> > > >> Nor is it clear that the FEC group of RFC 4756 is right, either. > For > > >a > > >> start, we may wish to use this new ID in combination with FEC, and > > >> secondly this tune-in stream has different characteristics. For > > >> example, one can typically ignore all FEC and (as long as there are > no > > >> errors) decode the stream correctly. Ignoring the tune-in stream > > > > entirely may mean that you will never find a tune-in point, making > > the > > >> normal stream useless. > > >> > > >> So, can we use FID for associating a repair stream with its base (we > > >tag > > >> the streams so we know which is which, of course)? > > >> > > >> p.s. RFC 4756 claims in the IANA section that the FEC group is > > >> registered under SDP characteristics, but actually I can find no > > >> registry anywhere in IANA of group types. > > >> > > >> > > >> -- > > >> David Singer > > >> Apple/QuickTime > > >> > > >> _______________________________________________ > > >> mmusic mailing list > > >> mmusic@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > -- > > David Singer > > Apple/QuickTime > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 07 16:32:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwOeK-0000rG-Kx; Thu, 07 Jun 2007 16:32:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwOeI-0000gk-V3 for mmusic@ietf.org; Thu, 07 Jun 2007 16:32:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwOeH-0001lJ-Ey for mmusic@ietf.org; Thu, 07 Jun 2007 16:32:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2007 13:32:01 -0700 X-IronPort-AV: i="4.16,396,1175497200"; d="scan'208"; a="161567857:sNHT41907150" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l57KW0cF020071 for ; Thu, 7 Jun 2007 13:32:00 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l57KVw21025577 for ; Thu, 7 Jun 2007 20:31:59 GMT Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <636AAD6D-F3F3-4965-8054-2AEB5EDC2872@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 7 Jun 2007 13:31:07 -0700 To: MMUSIC WG X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1537; t=1181248320; x=1182112320; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Fwd=3A=20Last=20Call=3A=20draft-ietf-dccp-rtp=20(RTP=20and=20 the=20Datagram=20Congestion=20=20Control=20Protocol=20(DCCP))=20to=20Propo sed=20Standard=20 |Sender:=20; bh=JLOcJW4SP0BB4klabXZDMVzN6dqrPL0c7CrGR4oadXc=; b=lFUkkDbK+X6lICUfYh0oAp2jGxCOV3ajjQMzyvDO5XOcii62xNBiop78/1CoDloL+DfIoBYS SDGQgMblb+IKDnOPkCPDhIoMQ+0vpnnIRxvKxQhFZhIpcLsviE+Utffc; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [MMUSIC] Fwd: Last Call: draft-ietf-dccp-rtp (RTP and the Datagram Congestion Control Protocol (DCCP)) to Proposed Standard 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 would like to point out this last call is happening - if you have opinions on the SDP usage in this draft - do not reply to this email. Reply on the IETF list. Begin forwarded message: > From: The IESG > Date: June 6, 2007 7:18:36 AM PDT > To: IETF-Announce > Cc: dccp@ietf.org > Subject: Last Call: draft-ietf-dccp-rtp (RTP and the Datagram > Congestion Control Protocol (DCCP)) to Proposed Standard > Reply-To: ietf@ietf.org > > The IESG has received a request from the Datagram Congestion Control > Protocol WG (dccp) to consider the following document: > > - 'RTP and the Datagram Congestion Control Protocol (DCCP) ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2007-06-20. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dccp-rtp-06.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_id&dTag=15015&rfc_flag=0 > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 07 17:33:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPby-0006rM-KD; Thu, 07 Jun 2007 17:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPbw-0006qn-RX; Thu, 07 Jun 2007 17:33:40 -0400 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPbu-0005kf-4t; Thu, 07 Jun 2007 17:33:40 -0400 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 7C4C91D88F65; Thu, 7 Jun 2007 23:33:37 +0200 (CEST) Received: from ipam040189 (DNab423247.Stanford.EDU [171.66.50.71]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id BA85C1D88F74; Thu, 7 Jun 2007 23:33:33 +0200 (CEST) From: "Thomas Schierl" To: "'Dave Singer'" References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com><000001c7a92a$f3aefac0$595c40ab@ipam040189> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams inRTP andSDP (RFC3388 etc), advice needed Date: Thu, 7 Jun 2007 14:33:30 -0700 Organization: HHI/FhG Message-ID: <009501c7a94b$807c7570$473242ab@ipam040189> 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: AcepLDjNiJ1Dz8PBQVaRnZeaFE0EbAAHmvmQ In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, hits=-104.9 required=5.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64 X-alterMIME: Yes X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: "'Even, Roni'" , Stephan.Wenger@nokia.com, 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 Hi Dave, I think the grouping type DDP fits, but we should talk about an extra type of dependency for that. Thomas > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Thursday, June 07, 2007 10:49 AM > To: Thomas Schierl > Cc: Stephan.Wenger@nokia.com; mmusic@ietf.org; 'Even, Roni'; avt@ietf.org > Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams > inRTP andSDP (RFC3388 etc), advice needed > > At 10:40 -0700 7/06/07, Thomas Schierl wrote: > >Hi Dave, > > > >I think there is a strong relation of your problem and the > >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.txt > . > >In this draft, we described media dependency in general, not only for > >scalable video. Currently, two types of dependencies are defined: layered > >and mdc assuming the media is partially transported in different RTP > >sessions. It would be easy to integrate your needs, if they should not be > >already covered. > > > > > >Thomas > > Thank you. I agree the problems are identical, or close to it. > > Do you think we should use 'lay' or 'mdc', or a new dependency type? > Or integrate a new group type into the draft (is 'DDP' right for our > application)? > > > > >> -----Original Message----- > >> From: Dave Singer [mailto:singer@apple.com] > >> Sent: Tuesday, June 05, 2007 8:34 AM > >> To: Even, Roni; mmusic; IETF AVT WG > >> Cc: Clinton Priddle (KI/EAB) > >> Subject: [AVT] RE: [MMUSIC] questions about grouping media streams in > RTP > >> andSDP (RFC3388 etc), advice needed > >> > >> At 10:03 +0300 5/06/07, Even, Roni wrote: > >> >Dave, > >> >For layered encoding there is a proposal for a new grouping attribute > in > >> >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec- > 03.tx > >> >t > >> > >> I don't think this is a layered coding issue, either, alas. > >> > >> >I looked at RFC3388 and I think that FID is not the answer to your > >> >requirement as you mentioned > >> > > >> >To me it looks like what you are looking for is a way to specify > >> >alternate offers. > >> > >> No, these streams are not alternatives to each other in the regular > >> sense. Nor is this really used in offer/answer; it's more an issue > >> for multicast. In multicast, you open the tune-in stream and the > >> base stream, grab the first I-frame that arrives (in either) and then > >> drop the tune-in stream. > >> > >> Yes, we're aware that the recipient needs to be able to tell which is > >> the base and which is the tune-in. > >> > >> >If this is the case I have similar requirements and > >> >would be happy to support such work. > >> > > >> >You also need a way to give semantics to the "repair" stream, this > can > >> >be done based on the content attribute from RFC 4796 or using a > >> >dependency attribute see in Schierl's draft. The mid tag is not > enough > >> >for the receiver to know what you meant by this offer and which > stream > >> >is the repair. > >> > > >> >Here is an example for a solution using a new Alternatives grouping > >> >attribute and giving semantics to the repair stream > >> > > >> >By using the grouping attribute in the offer you can know if the > >> >answerer understood the grouping since if he does not than he will > send > >> >an answer with no a=group > >> > > >> >v=0 > >> >o=bob 280744730 28977631 IN IP4 host.example.com > >> >s= > >> >t=0 0 > >> > > >> >a=group:ALTS 1 2 > >> >a=group:ALTS 1 3 > >> > > >> >m=audio 6886 RTP/AVP 0 > >> >c=IN IP6 2001:0600::1 > >> >a=mid:1 > >> > > >> >m=video 9000 RTP/AVP 100 > >> >c=IN IP4 192.0.2.2 > >> >a=rtpmap:100 H263-1998 > >> >a=mid:2 > >> > > >> >m=video 9002 RTP/AVP 101 > >> >c=IN IP4 192.0.2.2 > >> >a=rtpmap:101 H263-1998 > >> >a=mid:3 > >> >a=content:repair=2 or a=depend:repair=2 > >> > > >> > > >> >Roni Even > >> > > >> >> -----Original Message----- > >> >> From: Dave Singer [mailto:singer@apple.com] > >> >> Sent: Monday, June 04, 2007 7:19 PM > >> >> To: mmusic; IETF AVT WG > >> >> Cc: Clinton Priddle (KI/EAB) > >> >> Subject: [MMUSIC] questions about grouping media streams in RTP > and > >> >SDP > >> >> (RFC3388 etc), advice needed > >> >> > >> >> Hi > >> >> > >> >> we have a need to group together two media streams, in the style > of > >> >RFC > >> >> 3388 but we're unsure > whether an > >> >> existing group type is suitable or not, and if it's not, we'd like > to > >> >> agree on a new one, and document it (presumably in an RFC). > >> >> > >> >> What we have is a normal media stream, and a separate 'repair' or > > > >> 'entry' stream, that can be used when tuning in, or after loss, > but is > >> >> otherwise un-needed. An example might be a video stream with a > low > >> >> I-frame interval (say every 15 seconds), with a repair stream > which > >> >has > >> >> only I-frames that are equivalent to the time-parallel non-I > frame, at > >> >a > >> >> frequency of say 1 per second. > >> >> > >> >> It's not clear to us whether this is "one media flow" in the sense > of > >> >> FID, or not. The example offers AMR and GSM audio, which are > >> >> alternatives, and DTMF tones along with audio, which are > supplementary > >> >> to each other. Perhaps we fall afoul of this restriction: > >> >> > >> >> "An application that encodes the same media using different codecs > >> >> simultaneously MUST NOT use FID to group those media lines." > >> >> > >> >> or this one, for layered encoding: > >> >> > >> >> "FID MUST NOT be used to group "m" lines that do not represent the > >> >same > >> >> information." (Though how DTMF tones and their associated audio > pass > >> >> this test is not clear). > >> >> > >> >> Nor is it clear that the FEC group of RFC 4756 is right, either. > For > >> >a > >> >> start, we may wish to use this new ID in combination with FEC, and > >> >> secondly this tune-in stream has different characteristics. For > >> >> example, one can typically ignore all FEC and (as long as there > are no > >> >> errors) decode the stream correctly. Ignoring the tune-in stream > >> > > entirely may mean that you will never find a tune-in point, > making > >> the > >> >> normal stream useless. > >> >> > >> >> So, can we use FID for associating a repair stream with its base > (we > >> >tag > >> >> the streams so we know which is which, of course)? > >> >> > >> >> p.s. RFC 4756 claims in the IANA section that the FEC group is > >> >> registered under SDP characteristics, but actually I can find no > >> >> registry anywhere in IANA of group types. > >> >> > >> >> > >> >> -- > >> >> David Singer > >> >> Apple/QuickTime > >> >> > >> >> _______________________________________________ > >> >> mmusic mailing list > >> >> mmusic@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > >> > >> -- > >> David Singer > >> Apple/QuickTime > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www1.ietf.org/mailman/listinfo/avt > > > -- > David Singer > Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 07 17:47:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPpH-0003SC-1R; Thu, 07 Jun 2007 17:47:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPpF-0003Nx-S2; Thu, 07 Jun 2007 17:47:25 -0400 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPpE-0002p2-LW; Thu, 07 Jun 2007 17:47:25 -0400 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id BD4E71D88F82; Thu, 7 Jun 2007 23:47:23 +0200 (CEST) Received: from ipam040189 (DNab423247.Stanford.EDU [171.66.50.71]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id 8E49B1D88F5A; Thu, 7 Jun 2007 23:47:15 +0200 (CEST) From: "Thomas Schierl" To: "'Even, Roni'" , "'Dave Singer'" , "'mmusic'" , "'IETF AVT WG'" References: <000101c7a92b$c4752d50$595c40ab@ipam040189> <144ED8561CE90C41A3E5908EDECE315C049E7C50@IsrExch01.israel.polycom.com> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Date: Thu, 7 Jun 2007 14:47:12 -0700 Organization: HHI/FhG Message-ID: <009701c7a94d$6a4bb1b0$473242ab@ipam040189> 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: AcenhyxcbwKgryeQTM2S+JPzrTemewBpEXzgAATpg+AAAz/K0A== In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C049E7C50@IsrExch01.israel.polycom.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, hits=-104.9 required=5.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64 X-alterMIME: Yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: "'Clinton Priddle \(KI/EAB\)'" , Stephan.Wenger@nokia.com 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 Roni, Then it would be something like we call 'mdc'. But I would like to put that into an extra dependency type, since the characteristics of the streams are different, even if they could be used exchangeable. But there is one main stream, let us say. And that one should be identifiable. Thomas > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, June 07, 2007 1:07 PM > To: Thomas Schierl; Dave Singer; mmusic; IETF AVT WG > Cc: Stephan.Wenger@nokia.com; Clinton Priddle (KI/EAB) > Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams in > RTP andSDP (RFC3388 etc), advice needed > > Hi, > My view is that you have similarity in the need for dependencies between > streams but the grouping logic is different. > In the layered codec the grouping is for a group that you can use all or > part of while in the repair case you may take one or the other. > > Roni Even > > > -----Original Message----- > > From: Thomas Schierl [mailto:schierl@hhi.fhg.de] > > Sent: Thursday, June 07, 2007 8:46 PM > > To: 'Dave Singer'; Even, Roni; 'mmusic'; 'IETF AVT WG' > > Cc: Stephan.Wenger@nokia.com; 'Clinton Priddle (KI/EAB)' > > Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams > in > > RTP andSDP (RFC3388 etc), advice needed > > > > Hi Dave, > > > > I think there is a strong relation of your problem and the > > > http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx > t > > In this draft, we described media dependency in general, not only for > > scalable video. Currently, two types of dependencies are defined: > layered > > and mdc assuming the media is partially transported in different RTP > > sessions. There is not requirement, that the part of the media is > > independently decodable. It would be easy to integrate your needs, if > they > > should not be already covered. > > > > > > Thomas > > > > > -----Original Message----- > > > From: Dave Singer [mailto:singer@apple.com] > > > Sent: Tuesday, June 05, 2007 8:34 AM > > > To: Even, Roni; mmusic; IETF AVT WG > > > Cc: Clinton Priddle (KI/EAB) > > > Subject: [AVT] RE: [MMUSIC] questions about grouping media streams > in > > RTP > > > andSDP (RFC3388 etc), advice needed > > > > > > At 10:03 +0300 5/06/07, Even, Roni wrote: > > > >Dave, > > > >For layered encoding there is a proposal for a new grouping > attribute > > in > > > >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec- > > 03.tx > > > >t > > > > > > I don't think this is a layered coding issue, either, alas. > > > > > > >I looked at RFC3388 and I think that FID is not the answer to your > > > >requirement as you mentioned > > > > > > > >To me it looks like what you are looking for is a way to specify > > > >alternate offers. > > > > > > No, these streams are not alternatives to each other in the regular > > > sense. Nor is this really used in offer/answer; it's more an issue > > > for multicast. In multicast, you open the tune-in stream and the > > > base stream, grab the first I-frame that arrives (in either) and > then > > > drop the tune-in stream. > > > > > > Yes, we're aware that the recipient needs to be able to tell which > is > > > the base and which is the tune-in. > > > > > > >If this is the case I have similar requirements and > > > >would be happy to support such work. > > > > > > > >You also need a way to give semantics to the "repair" stream, this > can > > > >be done based on the content attribute from RFC 4796 or using a > > > >dependency attribute see in Schierl's draft. The mid tag is not > enough > > > >for the receiver to know what you meant by this offer and which > stream > > > >is the repair. > > > > > > > >Here is an example for a solution using a new Alternatives grouping > > > >attribute and giving semantics to the repair stream > > > > > > > >By using the grouping attribute in the offer you can know if the > > > >answerer understood the grouping since if he does not than he will > send > > > >an answer with no a=group > > > > > > > >v=0 > > > >o=bob 280744730 28977631 IN IP4 host.example.com > > > >s= > > > >t=0 0 > > > > > > > >a=group:ALTS 1 2 > > > >a=group:ALTS 1 3 > > > > > > > >m=audio 6886 RTP/AVP 0 > > > >c=IN IP6 2001:0600::1 > > > >a=mid:1 > > > > > > > >m=video 9000 RTP/AVP 100 > > > >c=IN IP4 192.0.2.2 > > > >a=rtpmap:100 H263-1998 > > > >a=mid:2 > > > > > > > >m=video 9002 RTP/AVP 101 > > > >c=IN IP4 192.0.2.2 > > > >a=rtpmap:101 H263-1998 > > > >a=mid:3 > > > >a=content:repair=2 or a=depend:repair=2 > > > > > > > > > > > >Roni Even > > > > > > > >> -----Original Message----- > > > >> From: Dave Singer [mailto:singer@apple.com] > > > >> Sent: Monday, June 04, 2007 7:19 PM > > > >> To: mmusic; IETF AVT WG > > > >> Cc: Clinton Priddle (KI/EAB) > > > >> Subject: [MMUSIC] questions about grouping media streams in RTP > and > > > >SDP > > > >> (RFC3388 etc), advice needed > > > >> > > > >> Hi > > > >> > > > >> we have a need to group together two media streams, in the style > of > > > >RFC > > > >> 3388 but we're unsure > whether > > an > > > >> existing group type is suitable or not, and if it's not, we'd > like > > to > > > >> agree on a new one, and document it (presumably in an RFC). > > > >> > > > >> What we have is a normal media stream, and a separate 'repair' > or > > > >> 'entry' stream, that can be used when tuning in, or after loss, > but > > is > > > >> otherwise un-needed. An example might be a video stream with a > low > > > >> I-frame interval (say every 15 seconds), with a repair stream > which > > > >has > > > >> only I-frames that are equivalent to the time-parallel non-I > frame, > > at > > > >a > > > >> frequency of say 1 per second. > > > >> > > > >> It's not clear to us whether this is "one media flow" in the > sense > > of > > > >> FID, or not. The example offers AMR and GSM audio, which are > > > >> alternatives, and DTMF tones along with audio, which are > > supplementary > > > >> to each other. Perhaps we fall afoul of this restriction: > > > >> > > > >> "An application that encodes the same media using different > codecs > > > >> simultaneously MUST NOT use FID to group those media lines." > > > >> > > > >> or this one, for layered encoding: > > > >> > > > >> "FID MUST NOT be used to group "m" lines that do not represent > the > > > >same > > > >> information." (Though how DTMF tones and their associated audio > > pass > > > >> this test is not clear). > > > >> > > > >> Nor is it clear that the FEC group of RFC 4756 is right, either. > > For > > > >a > > > >> start, we may wish to use this new ID in combination with FEC, > and > > > >> secondly this tune-in stream has different characteristics. For > > > >> example, one can typically ignore all FEC and (as long as there > are > > no > > > >> errors) decode the stream correctly. Ignoring the tune-in > stream > > > > > entirely may mean that you will never find a tune-in point, > making > > > the > > > >> normal stream useless. > > > >> > > > >> So, can we use FID for associating a repair stream with its base > (we > > > >tag > > > >> the streams so we know which is which, of course)? > > > >> > > > >> p.s. RFC 4756 claims in the IANA section that the FEC group is > > > >> registered under SDP characteristics, but actually I can find no > > > >> registry anywhere in IANA of group types. > > > >> > > > >> > > > >> -- > > > >> David Singer > > > >> Apple/QuickTime > > > >> > > > >> _______________________________________________ > > > >> mmusic mailing list > > > >> mmusic@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > -- > > > David Singer > > > Apple/QuickTime > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 07 18:01:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQ3H-0002Dt-54; Thu, 07 Jun 2007 18:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQ3F-0002Db-7s for mmusic@ietf.org; Thu, 07 Jun 2007 18:01:53 -0400 Received: from stewe.org ([85.214.23.117] helo=h665227.serverkompetenz.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQ3E-0007YS-8s for mmusic@ietf.org; Thu, 07 Jun 2007 18:01:53 -0400 Received: (qmail 24506 invoked by uid 60000); 7 Jun 2007 20:39:17 -0000 Received: from 75.60.27.134 by h665227 (envelope-from , uid 60004) with qmail-scanner-1.24st visas (spamassassin: 2.64. Clear:RC:0(75.60.27.134):SA:0(0.0/20.0):. Processed in 0.930007 secs); 07 Jun 2007 20:39:17 -0000 X-Spam-Status: No, hits=0.0 required=20.0 X-Envelope-From: stewe@stewe.org Received: from adsl-75-60-27-134.dsl.pltn13.sbcglobal.net (HELO ?192.168.1.100?) (stewe@stewe.org@75.60.27.134) by stewe.org with SMTP; 7 Jun 2007 20:39:16 -0000 In-Reply-To: <009701c7a94d$6a4bb1b0$473242ab@ipam040189> References: <000101c7a92b$c4752d50$595c40ab@ipam040189> <144ED8561CE90C41A3E5908EDECE315C049E7C50@IsrExch01.israel.polycom.com> <009701c7a94d$6a4bb1b0$473242ab@ipam040189> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66A2BDF7-0556-47C5-84A1-2CCE959A264A@stewe.org> Content-Transfer-Encoding: 7bit From: Stephan Wenger Subject: Re: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Date: Thu, 7 Jun 2007 15:01:42 -0700 To: Thomas Schierl X-Mailer: Apple Mail (2.752.3) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on h665227.serverkompetenz.net X-Spam-Level: X-Qmail-Scanner-MOVED-X-Spam-Status: No, hits=0.0 required=20.0 tests=none autolearn=no version=2.64 X-Spam-Score: 0.1 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: "'Clinton Priddle \(KI/EAB\)'" , "'Even, Roni'" , 'Dave Singer' , 'IETF AVT WG' , '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 Yes, and if this were a non-exotic use case, we would need such a type. As it IS an exotic use case, I guess we can survive with 3GPP specifying the "normal" stream having a lower port number than the "repair" stream, or something like this. (Now go out and blast me for unclean design choices. :-) Stephan On Jun 7, 2007, at 2:47 PM, Thomas Schierl wrote: > Hi Roni, > > Then it would be something like we call 'mdc'. But I would like to > put that > into an extra dependency type, since the characteristics of the > streams are > different, even if they could be used exchangeable. But there is > one main > stream, let us say. And that one should be identifiable. > > Thomas > >> -----Original Message----- >> From: Even, Roni [mailto:roni.even@polycom.co.il] >> Sent: Thursday, June 07, 2007 1:07 PM >> To: Thomas Schierl; Dave Singer; mmusic; IETF AVT WG >> Cc: Stephan.Wenger@nokia.com; Clinton Priddle (KI/EAB) >> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media >> streams in >> RTP andSDP (RFC3388 etc), advice needed >> >> Hi, >> My view is that you have similarity in the need for dependencies >> between >> streams but the grouping logic is different. >> In the layered codec the grouping is for a group that you can use >> all or >> part of while in the repair case you may take one or the other. >> >> Roni Even >> >>> -----Original Message----- >>> From: Thomas Schierl [mailto:schierl@hhi.fhg.de] >>> Sent: Thursday, June 07, 2007 8:46 PM >>> To: 'Dave Singer'; Even, Roni; 'mmusic'; 'IETF AVT WG' >>> Cc: Stephan.Wenger@nokia.com; 'Clinton Priddle (KI/EAB)' >>> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media >>> streams >> in >>> RTP andSDP (RFC3388 etc), advice needed >>> >>> Hi Dave, >>> >>> I think there is a strong relation of your problem and the >>> >> http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered- >> codec-03.tx >> t >>> In this draft, we described media dependency in general, not only >>> for >>> scalable video. Currently, two types of dependencies are defined: >> layered >>> and mdc assuming the media is partially transported in different RTP >>> sessions. There is not requirement, that the part of the media is >>> independently decodable. It would be easy to integrate your >>> needs, if >> they >>> should not be already covered. >>> >>> >>> Thomas >>> >>>> -----Original Message----- >>>> From: Dave Singer [mailto:singer@apple.com] >>>> Sent: Tuesday, June 05, 2007 8:34 AM >>>> To: Even, Roni; mmusic; IETF AVT WG >>>> Cc: Clinton Priddle (KI/EAB) >>>> Subject: [AVT] RE: [MMUSIC] questions about grouping media streams >> in >>> RTP >>>> andSDP (RFC3388 etc), advice needed >>>> >>>> At 10:03 +0300 5/06/07, Even, Roni wrote: >>>>> Dave, >>>>> For layered encoding there is a proposal for a new grouping >> attribute >>> in >>>>> http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered- >>>>> codec- >>> 03.tx >>>>> t >>>> >>>> I don't think this is a layered coding issue, either, alas. >>>> >>>>> I looked at RFC3388 and I think that FID is not the answer to your >>>>> requirement as you mentioned >>>>> >>>>> To me it looks like what you are looking for is a way to specify >>>>> alternate offers. >>>> >>>> No, these streams are not alternatives to each other in the regular >>>> sense. Nor is this really used in offer/answer; it's more an >>>> issue >>>> for multicast. In multicast, you open the tune-in stream and the >>>> base stream, grab the first I-frame that arrives (in either) and >> then >>>> drop the tune-in stream. >>>> >>>> Yes, we're aware that the recipient needs to be able to tell which >> is >>>> the base and which is the tune-in. >>>> >>>>> If this is the case I have similar requirements and >>>>> would be happy to support such work. >>>>> >>>>> You also need a way to give semantics to the "repair" stream, this >> can >>>>> be done based on the content attribute from RFC 4796 or using a >>>>> dependency attribute see in Schierl's draft. The mid tag is not >> enough >>>>> for the receiver to know what you meant by this offer and which >> stream >>>>> is the repair. >>>>> >>>>> Here is an example for a solution using a new Alternatives >>>>> grouping >>>>> attribute and giving semantics to the repair stream >>>>> >>>>> By using the grouping attribute in the offer you can know if the >>>>> answerer understood the grouping since if he does not than he will >> send >>>>> an answer with no a=group >>>>> >>>>> v=0 >>>>> o=bob 280744730 28977631 IN IP4 host.example.com >>>>> s= >>>>> t=0 0 >>>>> >>>>> a=group:ALTS 1 2 >>>>> a=group:ALTS 1 3 >>>>> >>>>> m=audio 6886 RTP/AVP 0 >>>>> c=IN IP6 2001:0600::1 >>>>> a=mid:1 >>>>> >>>>> m=video 9000 RTP/AVP 100 >>>>> c=IN IP4 192.0.2.2 >>>>> a=rtpmap:100 H263-1998 >>>>> a=mid:2 >>>>> >>>>> m=video 9002 RTP/AVP 101 >>>>> c=IN IP4 192.0.2.2 >>>>> a=rtpmap:101 H263-1998 >>>>> a=mid:3 >>>>> a=content:repair=2 or a=depend:repair=2 >>>>> >>>>> >>>>> Roni Even >>>>> >>>>>> -----Original Message----- >>>>>> From: Dave Singer [mailto:singer@apple.com] >>>>>> Sent: Monday, June 04, 2007 7:19 PM >>>>>> To: mmusic; IETF AVT WG >>>>>> Cc: Clinton Priddle (KI/EAB) >>>>>> Subject: [MMUSIC] questions about grouping media streams in RTP >> and >>>>> SDP >>>>>> (RFC3388 etc), advice needed >>>>>> >>>>>> Hi >>>>>> >>>>>> we have a need to group together two media streams, in the style >> of >>>>> RFC >>>>>> 3388 but we're unsure >> whether >>> an >>>>>> existing group type is suitable or not, and if it's not, we'd >> like >>> to >>>>>> agree on a new one, and document it (presumably in an RFC). >>>>>> >>>>>> What we have is a normal media stream, and a separate 'repair' >> or >>>>>> 'entry' stream, that can be used when tuning in, or after loss, >> but >>> is >>>>>> otherwise un-needed. An example might be a video stream with a >> low >>>>>> I-frame interval (say every 15 seconds), with a repair stream >> which >>>>> has >>>>>> only I-frames that are equivalent to the time-parallel non-I >> frame, >>> at >>>>> a >>>>>> frequency of say 1 per second. >>>>>> >>>>>> It's not clear to us whether this is "one media flow" in the >> sense >>> of >>>>>> FID, or not. The example offers AMR and GSM audio, which are >>>>>> alternatives, and DTMF tones along with audio, which are >>> supplementary >>>>>> to each other. Perhaps we fall afoul of this restriction: >>>>>> >>>>>> "An application that encodes the same media using different >> codecs >>>>>> simultaneously MUST NOT use FID to group those media lines." >>>>>> >>>>>> or this one, for layered encoding: >>>>>> >>>>>> "FID MUST NOT be used to group "m" lines that do not represent >> the >>>>> same >>>>>> information." (Though how DTMF tones and their associated audio >>> pass >>>>>> this test is not clear). >>>>>> >>>>>> Nor is it clear that the FEC group of RFC 4756 is right, either. >>> For >>>>> a >>>>>> start, we may wish to use this new ID in combination with FEC, >> and >>>>>> secondly this tune-in stream has different characteristics. For >>>>>> example, one can typically ignore all FEC and (as long as there >> are >>> no >>>>>> errors) decode the stream correctly. Ignoring the tune-in >> stream >>>>>> entirely may mean that you will never find a tune-in point, >> making >>>> the >>>>>> normal stream useless. >>>>>> >>>>>> So, can we use FID for associating a repair stream with its base >> (we >>>>> tag >>>>>> the streams so we know which is which, of course)? >>>>>> >>>>>> p.s. RFC 4756 claims in the IANA section that the FEC group is >>>>>> registered under SDP characteristics, but actually I can find no >>>>>> registry anywhere in IANA of group types. >>>>>> >>>>>> >>>>>> -- >>>>>> David Singer >>>>>> Apple/QuickTime >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> -- >>>> David Singer >>>> Apple/QuickTime >>>> >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 07 18:34:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQZB-0006qI-4B; Thu, 07 Jun 2007 18:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQZ9-0006hK-3V for mmusic@ietf.org; Thu, 07 Jun 2007 18:34:51 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQZ7-0007wX-MJ for mmusic@ietf.org; Thu, 07 Jun 2007 18:34:51 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l57MYm6V003899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Jun 2007 15:34:48 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l57MYl7a004613 for ; Thu, 7 Jun 2007 15:34:47 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 15:34:47 -0700 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, 7 Jun 2007 15:34:47 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B02DB6E44@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on unrecognized "a=" attributes in SDP offer/answer Thread-Index: AcepVA1nQ6zKOJuzQsGwgESQLmD3sA== From: "Desineni, Harikishan" To: X-OriginalArrivalTime: 07 Jun 2007 22:34:47.0834 (UTC) FILETIME=[0DDDDFA0:01C7A954] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [MMUSIC] Question on unrecognized "a=" attributes in SDP offer/answer 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 reading RFC3264, it is not clear how an answerer should prepare SDP answer when "a=3D" attribute lines in SDP offer are unrecognized. For example, how should SDP answer look when attrib1 and attrib2 are "sendonly" attributes and the answerer does not recognize them. SDP offer with "sendonly" attribute and both media streams are "sendrecv" =3D=3D=3D=3D=3D=3D=3D=3D m=3Daudio a=3Dattrib1:value1 m=3Dvideo a=3D attrib2:value2 I think the best current practice is SDP answer (1). Is there any RFC which clearly describes this behavior? Answerer simply removes the unrecognized attributes while preparing the SDP answer. SDP answer (1) =3D=3D=3D=3D=3D=3D=3D=3D=3D m=3Daudio m=3Dvideo Another possible answer if answerer simply ignores the unrecognized lines and does not remove them from SDP answer SDP answer (2) =3D=3D=3D=3D=3D=3D=3D=3D=3D m=3Daudio a=3Dattrib1:value1 m=3Dvideo a=3D attrib2:value2 I think that SDP answer (2) would result in issues. It might indicate that answerer is signaling attrib1/2 in answerer->offerer direction. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 08 03:38:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZ36-0008Mx-3a; Fri, 08 Jun 2007 03:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZ34-0008J6-Ro; Fri, 08 Jun 2007 03:38:18 -0400 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 1HwZ30-00047R-AF; Fri, 08 Jun 2007 03:38:18 -0400 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: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Date: Fri, 8 Jun 2007 10:39:02 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C049E7C74@IsrExch01.israel.polycom.com> In-Reply-To: <009701c7a94d$6a4bb1b0$473242ab@ipam040189> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Thread-Index: AcenhyxcbwKgryeQTM2S+JPzrTemewBpEXzgAATpg+AAAz/K0AAUeDVw From: "Even, Roni" To: "Thomas Schierl" , "Dave Singer" , "mmusic" , "IETF AVT WG" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: "Clinton Priddle \(KI/EAB\)" , Stephan.Wenger@nokia.com 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 Thomas, I already wrote that we need to look at the general case before going to a specific solution. Currently for a media stream we have a way to mark a stream using the label attribute. We have a way to apply semantics to a single stream using the content attribute. What we are doing here is defining semantics to a group of streams by using dependency attribute. The parameter for the dependency does not have to be the same for all cases and depends on what you want. As for tagging the dependencies it may be the mid number or use a label. Now the second part that is needed is to specify the grouping, we have a grouping attribute but it lacks some parameters for the layered codecs and the repair stream.=20 I would like to add to this the case of simple alternate attributes. For example I can do G.711 with two H.263 video streams or G.711 with one H.264 video stream. I see two cases for the group, one for alternate streams and the other for a set of streams. The advantage of using the group attribute is that if the other side does not support it, he will remove it from the answer. Here are examples for both Alternate: here you may use 1 and 2 or 1 and 3 a=3Dgroup:ALTS:1 1 2 a=3Dgroup:ALTS:1 1 3=20 m=3Daudio 6886 RTP/AVP 0 c=3DIN IP6 2001:0600::1 a=3Dmid:1=20 m=3Dvideo 9000 RTP/AVP 100 c=3DIN IP4 192.0.2.2 a=3Drtpmap:100 H263-1998 a=3Dmid:2=20 m=3Dvideo 9002 RTP/AVP 101 c=3DIN IP4 192.0.2.2 a=3Drtpmap:101 H263-1998 a=3Dmid:3 For a SET here you say that 2 and 3 are a set for layering a=3Dgroup:SET 2 3 m=3Daudio 6886 RTP/AVP 0 c=3DIN IP6 2001:0600::1 a=3Dmid:1=20 m=3Dvideo 9000 RTP/AVP 100 c=3DIN IP4 192.0.2.2 a=3Drtpmap:100 H263-1998 a=3Dmid:2=20 m=3Dvideo 9002 RTP/AVP 101 c=3DIN IP4 192.0.2.2 a=3Drtpmap:101 H263-1998 a=3Dmid:3 a=3Dcontent:repair=3D2 or a=3Ddepend:repair=3D2 Roni > -----Original Message----- > From: Thomas Schierl [mailto:schierl@hhi.fhg.de] > Sent: Friday, June 08, 2007 12:47 AM > To: Even, Roni; 'Dave Singer'; 'mmusic'; 'IETF AVT WG' > Cc: Stephan.Wenger@nokia.com; 'Clinton Priddle (KI/EAB)' > Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams in > RTP andSDP (RFC3388 etc), advice needed >=20 > Hi Roni, >=20 > Then it would be something like we call 'mdc'. But I would like to put > that > into an extra dependency type, since the characteristics of the streams > are > different, even if they could be used exchangeable. But there is one main > stream, let us say. And that one should be identifiable. >=20 > Thomas >=20 > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Thursday, June 07, 2007 1:07 PM > > To: Thomas Schierl; Dave Singer; mmusic; IETF AVT WG > > Cc: Stephan.Wenger@nokia.com; Clinton Priddle (KI/EAB) > > Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams > in > > RTP andSDP (RFC3388 etc), advice needed > > > > Hi, > > My view is that you have similarity in the need for dependencies between > > streams but the grouping logic is different. > > In the layered codec the grouping is for a group that you can use all or > > part of while in the repair case you may take one or the other. > > > > Roni Even > > > > > -----Original Message----- > > > From: Thomas Schierl [mailto:schierl@hhi.fhg.de] > > > Sent: Thursday, June 07, 2007 8:46 PM > > > To: 'Dave Singer'; Even, Roni; 'mmusic'; 'IETF AVT WG' > > > Cc: Stephan.Wenger@nokia.com; 'Clinton Priddle (KI/EAB)' > > > Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams > > in > > > RTP andSDP (RFC3388 etc), advice needed > > > > > > Hi Dave, > > > > > > I think there is a strong relation of your problem and the > > > > > http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx > > t > > > In this draft, we described media dependency in general, not only for > > > scalable video. Currently, two types of dependencies are defined: > > layered > > > and mdc assuming the media is partially transported in different RTP > > > sessions. There is not requirement, that the part of the media is > > > independently decodable. It would be easy to integrate your needs, if > > they > > > should not be already covered. > > > > > > > > > Thomas > > > > > > > -----Original Message----- > > > > From: Dave Singer [mailto:singer@apple.com] > > > > Sent: Tuesday, June 05, 2007 8:34 AM > > > > To: Even, Roni; mmusic; IETF AVT WG > > > > Cc: Clinton Priddle (KI/EAB) > > > > Subject: [AVT] RE: [MMUSIC] questions about grouping media streams > > in > > > RTP > > > > andSDP (RFC3388 etc), advice needed > > > > > > > > At 10:03 +0300 5/06/07, Even, Roni wrote: > > > > >Dave, > > > > >For layered encoding there is a proposal for a new grouping > > attribute > > > in > > > > >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec- > > > 03.tx > > > > >t > > > > > > > > I don't think this is a layered coding issue, either, alas. > > > > > > > > >I looked at RFC3388 and I think that FID is not the answer to your > > > > >requirement as you mentioned > > > > > > > > > >To me it looks like what you are looking for is a way to specify > > > > >alternate offers. > > > > > > > > No, these streams are not alternatives to each other in the regular > > > > sense. Nor is this really used in offer/answer; it's more an issue > > > > for multicast. In multicast, you open the tune-in stream and the > > > > base stream, grab the first I-frame that arrives (in either) and > > then > > > > drop the tune-in stream. > > > > > > > > Yes, we're aware that the recipient needs to be able to tell which > > is > > > > the base and which is the tune-in. > > > > > > > > >If this is the case I have similar requirements and > > > > >would be happy to support such work. > > > > > > > > > >You also need a way to give semantics to the "repair" stream, this > > can > > > > >be done based on the content attribute from RFC 4796 or using a > > > > >dependency attribute see in Schierl's draft. The mid tag is not > > enough > > > > >for the receiver to know what you meant by this offer and which > > stream > > > > >is the repair. > > > > > > > > > >Here is an example for a solution using a new Alternatives grouping > > > > >attribute and giving semantics to the repair stream > > > > > > > > > >By using the grouping attribute in the offer you can know if the > > > > >answerer understood the grouping since if he does not than he will > > send > > > > >an answer with no a=3Dgroup > > > > > > > > > >v=3D0 > > > > >o=3Dbob 280744730 28977631 IN IP4 host.example.com > > > > >s=3D > > > > >t=3D0 0 > > > > > > > > > >a=3Dgroup:ALTS 1 2 > > > > >a=3Dgroup:ALTS 1 3 > > > > > > > > > >m=3Daudio 6886 RTP/AVP 0 > > > > >c=3DIN IP6 2001:0600::1 > > > > >a=3Dmid:1 > > > > > > > > > >m=3Dvideo 9000 RTP/AVP 100 > > > > >c=3DIN IP4 192.0.2.2 > > > > >a=3Drtpmap:100 H263-1998 > > > > >a=3Dmid:2 > > > > > > > > > >m=3Dvideo 9002 RTP/AVP 101 > > > > >c=3DIN IP4 192.0.2.2 > > > > >a=3Drtpmap:101 H263-1998 > > > > >a=3Dmid:3 > > > > >a=3Dcontent:repair=3D2 or a=3Ddepend:repair=3D2 > > > > > > > > > > > > > > >Roni Even > > > > > > > > > >> -----Original Message----- > > > > >> From: Dave Singer [mailto:singer@apple.com] > > > > >> Sent: Monday, June 04, 2007 7:19 PM > > > > >> To: mmusic; IETF AVT WG > > > > >> Cc: Clinton Priddle (KI/EAB) > > > > >> Subject: [MMUSIC] questions about grouping media streams in RTP > > and > > > > >SDP > > > > >> (RFC3388 etc), advice needed > > > > >> > > > > >> Hi > > > > >> > > > > >> we have a need to group together two media streams, in the style > > of > > > > >RFC > > > > >> 3388 but we're unsure > > whether > > > an > > > > >> existing group type is suitable or not, and if it's not, we'd > > like > > > to > > > > >> agree on a new one, and document it (presumably in an RFC). > > > > >> > > > > >> What we have is a normal media stream, and a separate 'repair' > > or > > > > >> 'entry' stream, that can be used when tuning in, or after loss, > > but > > > is > > > > >> otherwise un-needed. An example might be a video stream with a > > low > > > > >> I-frame interval (say every 15 seconds), with a repair stream > > which > > > > >has > > > > >> only I-frames that are equivalent to the time-parallel non-I > > frame, > > > at > > > > >a > > > > >> frequency of say 1 per second. > > > > >> > > > > >> It's not clear to us whether this is "one media flow" in the > > sense > > > of > > > > >> FID, or not. The example offers AMR and GSM audio, which are > > > > >> alternatives, and DTMF tones along with audio, which are > > > supplementary > > > > >> to each other. Perhaps we fall afoul of this restriction: > > > > >> > > > > >> "An application that encodes the same media using different > > codecs > > > > >> simultaneously MUST NOT use FID to group those media lines." > > > > >> > > > > >> or this one, for layered encoding: > > > > >> > > > > >> "FID MUST NOT be used to group "m" lines that do not represent > > the > > > > >same > > > > >> information." (Though how DTMF tones and their associated audio > > > pass > > > > >> this test is not clear). > > > > >> > > > > >> Nor is it clear that the FEC group of RFC 4756 is right, either. > > > For > > > > >a > > > > >> start, we may wish to use this new ID in combination with FEC, > > and > > > > >> secondly this tune-in stream has different characteristics. For > > > > >> example, one can typically ignore all FEC and (as long as there > > are > > > no > > > > >> errors) decode the stream correctly. Ignoring the tune-in > > stream > > > > > > entirely may mean that you will never find a tune-in point, > > making > > > > the > > > > >> normal stream useless. > > > > >> > > > > >> So, can we use FID for associating a repair stream with its base > > (we > > > > >tag > > > > >> the streams so we know which is which, of course)? > > > > >> > > > > >> p.s. RFC 4756 claims in the IANA section that the FEC group is > > > > >> registered under SDP characteristics, but actually I can find no > > > > >> registry anywhere in IANA of group types. > > > > >> > > > > >> > > > > >> -- > > > > >> David Singer > > > > >> Apple/QuickTime > > > > >> > > > > >> _______________________________________________ > > > > >> mmusic mailing list > > > > >> mmusic@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > -- > > > > David Singer > > > > Apple/QuickTime > > > > > > > > _______________________________________________ > > > > Audio/Video Transport Working Group > > > > avt@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 08 03:43:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZ8B-00056E-AH; Fri, 08 Jun 2007 03:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZ7k-0004nx-1s for mmusic@ietf.org; Fri, 08 Jun 2007 03:43:08 -0400 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 1HwZ7i-0006I2-IY for mmusic@ietf.org; Fri, 08 Jun 2007 03:43:08 -0400 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 l587h2Kx003029; Fri, 8 Jun 2007 10:43:02 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:42:35 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:42:35 +0300 Received: from [172.21.154.97] ([172.21.154.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:42:34 +0300 Message-ID: <4669086A.6030606@nsn.com> Date: Fri, 08 Jun 2007 10:42:34 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] File transfer version -03 References: <46657005.4040802@nsn.com> <466822B8.6040609@cisco.com> In-Reply-To: <466822B8.6040609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 07:42:34.0833 (UTC) FILETIME=[941FEC10:01C7A9A0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Paul: Thanks for the review. I agree with your three issues, so I will fix them in the next version. On the other hand: did you have a chance to verify if the discussion about the hash is correctly implemented? I still want to do a full review focusing on the hash, so I would appreciate more eye globes that review this particular issue. BR, Miguel Paul Kyzivat wrote: > Miguel, > > This has resolved the issues I had. I did come across a few minor points: > > - the syntax of filename-string does not address escaping, yet > there is mention elsewhere of percent encoding filenames that > contain quotes. > > I think you need something more like the following (adapted from 3261): > > percent-encoded = "%" HEXDIG HEXDIG > filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF > ;any byte except NUL, CR, LF, double quotes, or percent > filename-string = 1*(filename-char/percent-encoded) > > - it might be good to clarify, somewhere, that the hash is computed over > the *entire* file, even if the transfer is only for a file-range. This > may be obvious, but maybe not. One place to do this might be as a NOTE > near the description of the 'hash' selector in section 6. > > - section 8.1.1 doesn't say what the offerer should do after receiving > the answer. Perhaps this is obvious, but its inconsistent with the other > sections. > > That's all. > > Thanks, > Paul > > Miguel Garcia wrote: >> Hi: >> >> I have just submitted version -03 of the file transfer mechanism >> draft. Until it becomes available in your favorite repository, you can >> fetch a copy from: >> >> http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03.txt >> >> http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03.html >> >> >> A diff version is also available: >> http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03-from-2.html >> >> >> These are the changes in this version: >> - new attribute 'file-transfer'. It determines whether a "new" file >> transfer is requested, or the SDP is there because of an "existing" >> file transfer. >> - ABNF in name selector considers double quotes now. >> - ABNF of hash changes to be equal to RFC 4572 (Comedia). >> - File disposition 'not-render' is now 'attachment'. No need to invent >> a new disposition value. >> - Hash of file is locally computed and checked for errors with that >> in the SDP. >> - All available hash algorithms are sent. >> - Clarifications on the usage of the max-size attribute in MSRP >> - Added considerations about the 'file-icon' attribute and their >> requirements for multipart MIME bodies. >> >> Other minor changes: >> - Addition of definitions of Push and Pull operations >> - Clarification that the file selector need not contain all four >> selectors >> >> To my knowledge, this completes the round of discussions we had in the >> past. There is only one open issue that I will be discussing in a >> separate thread. >> >> BR, >> >> Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 08 04:01:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZPf-0006a9-MQ; Fri, 08 Jun 2007 04:01:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZPe-0006a4-O6 for mmusic@ietf.org; Fri, 08 Jun 2007 04:01:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwZPd-0003jS-11 for mmusic@ietf.org; Fri, 08 Jun 2007 04:01:38 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 743522169E; Fri, 8 Jun 2007 10:01:36 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-3a-46690ce04811 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 59A3E213AB; Fri, 8 Jun 2007 10:01:36 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:01:35 +0200 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] Question on unrecognized "a=" attributes in SDPoffer/answer Date: Fri, 8 Jun 2007 10:01:34 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704F5EA88@esealmw113.eemea.ericsson.se> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B02DB6E44@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Question on unrecognized "a=" attributes in SDPoffer/answer thread-index: AcepVA1nQ6zKOJuzQsGwgESQLmD3sAATumKw References: <2CA3E1B6CEC064449CAA7D0FAB46079B02DB6E44@NAEX01.na.qualcomm.com> From: "Christer Holmberg (JO/LMF)" To: "Desineni, Harikishan" , X-OriginalArrivalTime: 08 Jun 2007 08:01:35.0801 (UTC) FILETIME=[3C31D290:01C7A9A3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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, Since the receiver will discard attributes it doesn't understand I don't = think it should put anything in the answer. Because, then the one who = sent the offer may actually think that the other party DOES understand = the attribute. Regards, Christer=20 > -----Original Message----- > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com]=20 > Sent: 8. kes=E4kuuta 2007 1:35 > To: mmusic@ietf.org > Subject: [MMUSIC] Question on unrecognized "a=3D" attributes in=20 > SDPoffer/answer >=20 > >From reading RFC3264, it is not clear how an answerer should prepare=20 > >SDP > answer when "a=3D" attribute lines in SDP offer are unrecognized. >=20 > For example, how should SDP answer look when attrib1 and=20 > attrib2 are "sendonly" attributes and the answerer does not=20 > recognize them. >=20 > SDP offer with "sendonly" attribute and both media streams=20 > are "sendrecv" > =3D=3D=3D=3D=3D=3D=3D=3D > m=3Daudio > a=3Dattrib1:value1 >=20 > m=3Dvideo > a=3D attrib2:value2 >=20 >=20 > I think the best current practice is SDP answer (1). Is there=20 > any RFC which clearly describes this behavior? > Answerer simply removes the unrecognized attributes while=20 > preparing the SDP answer. >=20 > SDP answer (1) > =3D=3D=3D=3D=3D=3D=3D=3D=3D > m=3Daudio > m=3Dvideo >=20 > Another possible answer if answerer simply ignores the=20 > unrecognized lines and does not remove them from SDP answer=20 > SDP answer (2) =3D=3D=3D=3D=3D=3D=3D=3D=3D m=3Daudio > a=3Dattrib1:value1 >=20 > m=3Dvideo > a=3D attrib2:value2 >=20 >=20 > I think that SDP answer (2) would result in issues. It might=20 > indicate that answerer is signaling attrib1/2 in=20 > answerer->offerer direction. >=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 Fri Jun 08 08:12:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdJx-0000nG-90; Fri, 08 Jun 2007 08:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdJw-0000n8-NV for mmusic@ietf.org; Fri, 08 Jun 2007 08:12:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwdJv-0005TP-DL for mmusic@ietf.org; Fri, 08 Jun 2007 08:12:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Jun 2007 08:11:58 -0400 X-IronPort-AV: i="4.16,399,1175486400"; d="scan'208"; a="123127608:sNHT1329002584" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l58CBwGo030178; Fri, 8 Jun 2007 08:11:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l58C8PBk006516; Fri, 8 Jun 2007 12:11:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 08:08:35 -0400 Received: from [10.86.242.249] ([10.86.242.249]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 08:08:34 -0400 Message-ID: <466946C5.8050900@cisco.com> Date: Fri, 08 Jun 2007 08:08:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [MMUSIC] File transfer version -03 References: <46657005.4040802@nsn.com> <466822B8.6040609@cisco.com> <4669086A.6030606@nsn.com> In-Reply-To: <4669086A.6030606@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 12:08:34.0869 (UTC) FILETIME=[BD0C2650:01C7A9C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3389; t=1181304718; x=1182168718; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20File=20transfer=20version=20-03 |Sender:=20 |To:=20Miguel=20Garcia=20; bh=E7P1oL7FX5KivzeAvdfIZpkLbsxk8Nt8189pTYHeVxI=; b=hWL26P2jOHiluEE/PDwT/wICwbX8hgefq++Gj6EfCVAcGr+fiEnfGp4/ZFlszZbEj+m7CYD/ rVNQ+Z1WsNhBZqqbUTVcJ7BRJ4ihKKai6OtHS7BmJtAO3QjMwgfY4Unf; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Miguel Garcia wrote: > Hi Paul: > > Thanks for the review. I agree with your three issues, so I will fix > them in the next version. > > On the other hand: did you have a chance to verify if the discussion > about the hash is correctly implemented? I still want to do a full > review focusing on the hash, so I would appreciate more eye globes that > review this particular issue. Yes, I think the coverage of hash is fine now with the exception of the small clarification I mentioned. Paul > BR, > > Miguel > > > Paul Kyzivat wrote: >> Miguel, >> >> This has resolved the issues I had. I did come across a few minor points: >> >> - the syntax of filename-string does not address escaping, yet >> there is mention elsewhere of percent encoding filenames that >> contain quotes. >> >> I think you need something more like the following (adapted from 3261): >> >> percent-encoded = "%" HEXDIG HEXDIG >> filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF >> ;any byte except NUL, CR, LF, double quotes, or percent >> filename-string = 1*(filename-char/percent-encoded) >> >> - it might be good to clarify, somewhere, that the hash is computed >> over the *entire* file, even if the transfer is only for a file-range. >> This may be obvious, but maybe not. One place to do this might be as a >> NOTE near the description of the 'hash' selector in section 6. >> >> - section 8.1.1 doesn't say what the offerer should do after receiving >> the answer. Perhaps this is obvious, but its inconsistent with the >> other sections. >> >> That's all. >> >> Thanks, >> Paul >> >> Miguel Garcia wrote: >>> Hi: >>> >>> I have just submitted version -03 of the file transfer mechanism >>> draft. Until it becomes available in your favorite repository, you >>> can fetch a copy from: >>> >>> http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03.txt >>> >>> http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03.html >>> >>> >>> A diff version is also available: >>> http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-03-from-2.html >>> >>> >>> These are the changes in this version: >>> - new attribute 'file-transfer'. It determines whether a "new" file >>> transfer is requested, or the SDP is there because of an "existing" >>> file transfer. >>> - ABNF in name selector considers double quotes now. >>> - ABNF of hash changes to be equal to RFC 4572 (Comedia). >>> - File disposition 'not-render' is now 'attachment'. No need to >>> invent a new disposition value. >>> - Hash of file is locally computed and checked for errors with that >>> in the SDP. >>> - All available hash algorithms are sent. >>> - Clarifications on the usage of the max-size attribute in MSRP >>> - Added considerations about the 'file-icon' attribute and their >>> requirements for multipart MIME bodies. >>> >>> Other minor changes: >>> - Addition of definitions of Push and Pull operations >>> - Clarification that the file selector need not contain all four >>> selectors >>> >>> To my knowledge, this completes the round of discussions we had in >>> the past. There is only one open issue that I will be discussing in a >>> separate thread. >>> >>> BR, >>> >>> Miguel > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 08 08:27:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdYk-00020e-6L; Fri, 08 Jun 2007 08:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLyP-0004qn-UX; Thu, 07 Jun 2007 13:40:37 -0400 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwLyP-0001iz-D1; Thu, 07 Jun 2007 13:40:37 -0400 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 7CF901D88F5D; Thu, 7 Jun 2007 19:40:36 +0200 (CEST) Received: from ipam040189 (ipam189.Stanford.EDU [171.64.92.89]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id DD3E81D88F62; Thu, 7 Jun 2007 19:40:32 +0200 (CEST) From: "Thomas Schierl" To: "'Dave Singer'" References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Date: Thu, 7 Jun 2007 10:40:15 -0700 Organization: HHI/FhG Message-ID: <000001c7a92a$f3aefac0$595c40ab@ipam040189> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcenhyxcbwKgryeQTM2S+JPzrTemewBon4FQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, hits=-104.4 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64 X-alterMIME: Yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 X-Mailman-Approved-At: Fri, 08 Jun 2007 08:27:17 -0400 Cc: "'Even, Roni'" , Stephan.Wenger@nokia.com, 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 Hi Dave, I think there is a strong relation of your problem and the http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.txt . In this draft, we described media dependency in general, not only for scalable video. Currently, two types of dependencies are defined: layered and mdc assuming the media is partially transported in different RTP sessions. It would be easy to integrate your needs, if they should not be already covered. Thomas > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Tuesday, June 05, 2007 8:34 AM > To: Even, Roni; mmusic; IETF AVT WG > Cc: Clinton Priddle (KI/EAB) > Subject: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP > andSDP (RFC3388 etc), advice needed > > At 10:03 +0300 5/06/07, Even, Roni wrote: > >Dave, > >For layered encoding there is a proposal for a new grouping attribute in > >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.tx > >t > > I don't think this is a layered coding issue, either, alas. > > >I looked at RFC3388 and I think that FID is not the answer to your > >requirement as you mentioned > > > >To me it looks like what you are looking for is a way to specify > >alternate offers. > > No, these streams are not alternatives to each other in the regular > sense. Nor is this really used in offer/answer; it's more an issue > for multicast. In multicast, you open the tune-in stream and the > base stream, grab the first I-frame that arrives (in either) and then > drop the tune-in stream. > > Yes, we're aware that the recipient needs to be able to tell which is > the base and which is the tune-in. > > >If this is the case I have similar requirements and > >would be happy to support such work. > > > >You also need a way to give semantics to the "repair" stream, this can > >be done based on the content attribute from RFC 4796 or using a > >dependency attribute see in Schierl's draft. The mid tag is not enough > >for the receiver to know what you meant by this offer and which stream > >is the repair. > > > >Here is an example for a solution using a new Alternatives grouping > >attribute and giving semantics to the repair stream > > > >By using the grouping attribute in the offer you can know if the > >answerer understood the grouping since if he does not than he will send > >an answer with no a=group > > > >v=0 > >o=bob 280744730 28977631 IN IP4 host.example.com > >s= > >t=0 0 > > > >a=group:ALTS 1 2 > >a=group:ALTS 1 3 > > > >m=audio 6886 RTP/AVP 0 > >c=IN IP6 2001:0600::1 > >a=mid:1 > > > >m=video 9000 RTP/AVP 100 > >c=IN IP4 192.0.2.2 > >a=rtpmap:100 H263-1998 > >a=mid:2 > > > >m=video 9002 RTP/AVP 101 > >c=IN IP4 192.0.2.2 > >a=rtpmap:101 H263-1998 > >a=mid:3 > >a=content:repair=2 or a=depend:repair=2 > > > > > >Roni Even > > > >> -----Original Message----- > >> From: Dave Singer [mailto:singer@apple.com] > >> Sent: Monday, June 04, 2007 7:19 PM > >> To: mmusic; IETF AVT WG > >> Cc: Clinton Priddle (KI/EAB) > >> Subject: [MMUSIC] questions about grouping media streams in RTP and > >SDP > >> (RFC3388 etc), advice needed > >> > >> Hi > >> > >> we have a need to group together two media streams, in the style of > >RFC > >> 3388 but we're unsure whether an > >> existing group type is suitable or not, and if it's not, we'd like to > >> agree on a new one, and document it (presumably in an RFC). > >> > >> What we have is a normal media stream, and a separate 'repair' or > >> 'entry' stream, that can be used when tuning in, or after loss, but is > >> otherwise un-needed. An example might be a video stream with a low > >> I-frame interval (say every 15 seconds), with a repair stream which > >has > >> only I-frames that are equivalent to the time-parallel non-I frame, at > >a > >> frequency of say 1 per second. > >> > >> It's not clear to us whether this is "one media flow" in the sense of > >> FID, or not. The example offers AMR and GSM audio, which are > >> alternatives, and DTMF tones along with audio, which are supplementary > >> to each other. Perhaps we fall afoul of this restriction: > >> > >> "An application that encodes the same media using different codecs > >> simultaneously MUST NOT use FID to group those media lines." > >> > >> or this one, for layered encoding: > >> > >> "FID MUST NOT be used to group "m" lines that do not represent the > >same > >> information." (Though how DTMF tones and their associated audio pass > >> this test is not clear). > >> > >> Nor is it clear that the FEC group of RFC 4756 is right, either. For > >a > >> start, we may wish to use this new ID in combination with FEC, and > >> secondly this tune-in stream has different characteristics. For > >> example, one can typically ignore all FEC and (as long as there are no > >> errors) decode the stream correctly. Ignoring the tune-in stream > > > entirely may mean that you will never find a tune-in point, making > the > >> normal stream useless. > >> > >> So, can we use FID for associating a repair stream with its base (we > >tag > >> the streams so we know which is which, of course)? > >> > >> p.s. RFC 4756 claims in the IANA section that the FEC group is > >> registered under SDP characteristics, but actually I can find no > >> registry anywhere in IANA of group types. > >> > >> > >> -- > >> David Singer > >> Apple/QuickTime > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > > > -- > David Singer > Apple/QuickTime > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 08 08:27:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdYk-00020u-FG; Fri, 08 Jun 2007 08:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPkQ-0000U2-KQ for mmusic@ietf.org; Thu, 07 Jun 2007 17:42:26 -0400 Received: from stewe.org ([85.214.23.117] helo=h665227.serverkompetenz.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPkP-0000M7-LX for mmusic@ietf.org; Thu, 07 Jun 2007 17:42:26 -0400 Received: (qmail 24032 invoked by uid 60000); 7 Jun 2007 20:19:51 -0000 Received: from 75.60.27.134 by h665227 (envelope-from , uid 60004) with qmail-scanner-1.24st visas (spamassassin: 2.64. Clear:RC:0(75.60.27.134):SA:0(0.0/20.0):. Processed in 0.894077 secs); 07 Jun 2007 20:19:51 -0000 X-Spam-Status: No, hits=0.0 required=20.0 X-Envelope-From: stephan.wenger@nokia.com Received: from adsl-75-60-27-134.dsl.pltn13.sbcglobal.net (HELO ?192.168.1.100?) (stewe@stewe.org@75.60.27.134) by stewe.org with SMTP; 7 Jun 2007 20:19:50 -0000 In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C049E7C50@IsrExch01.israel.polycom.com> References: <144ED8561CE90C41A3E5908EDECE315C049E7C50@IsrExch01.israel.polycom.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: Stephan Wenger Subject: Re: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed Date: Thu, 7 Jun 2007 14:42:15 -0700 To: "Even, Roni" X-Mailer: Apple Mail (2.752.3) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on h665227.serverkompetenz.net X-Spam-Level: X-Qmail-Scanner-MOVED-X-Spam-Status: No, hits=0.0 required=20.0 tests=none autolearn=no version=2.64 X-Spam-Score: 0.1 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d X-Mailman-Approved-At: Fri, 08 Jun 2007 08:27:17 -0400 Cc: "Clinton Priddle \(KI/EAB\)" , mmusic , Thomas Schierl , IETF AVT WG , Dave Singer 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, Yes, i agree with Roni: This is not a layered codec case in any sense, as there is no directed use hierarchy between those two flows. Under certain conditions (i.e. in the absence of packet loss), both are valid, usable streams. But, IMHO, this may be not a bad example for multiple description coding. The two streams represent essentially the same media, and (under certain conditions such as packet loss) it is advantageous to use both of them, not only one. It may not be a direct hit on the Schierl draft MDC use case, but it's close enough to be documentable in a 3GPP spec. I'm not sure that the use case in question warrants a new I-D. If the analogy to video transmission would be a bit more solid, I would have a different view. But, a it stands, you could not use the mechanism envisioned with any predictive video codec (possible exception: H.264 extended profile, utilizing SI/SP technology), as it is at present close to impossible to generate identical reference pictures from two different streams, using different encoding methods. Finally, I'm unsure whether 3GPP's intended timing would allow for yet another draft. Even the Schierl draft comes kind of late for this work. Regards, Stephan On Jun 7, 2007, at 1:06 PM, Even, Roni wrote: > Hi, > My view is that you have similarity in the need for dependencies > between > streams but the grouping logic is different. > In the layered codec the grouping is for a group that you can use > all or > part of while in the repair case you may take one or the other. > > Roni Even > >> -----Original Message----- >> From: Thomas Schierl [mailto:schierl@hhi.fhg.de] >> Sent: Thursday, June 07, 2007 8:46 PM >> To: 'Dave Singer'; Even, Roni; 'mmusic'; 'IETF AVT WG' >> Cc: Stephan.Wenger@nokia.com; 'Clinton Priddle (KI/EAB)' >> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media >> streams > in >> RTP andSDP (RFC3388 etc), advice needed >> >> Hi Dave, >> >> I think there is a strong relation of your problem and the >> > http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered- > codec-03.tx > t >> In this draft, we described media dependency in general, not only for >> scalable video. Currently, two types of dependencies are defined: > layered >> and mdc assuming the media is partially transported in different RTP >> sessions. There is not requirement, that the part of the media is >> independently decodable. It would be easy to integrate your needs, if > they >> should not be already covered. >> >> >> Thomas >> >>> -----Original Message----- >>> From: Dave Singer [mailto:singer@apple.com] >>> Sent: Tuesday, June 05, 2007 8:34 AM >>> To: Even, Roni; mmusic; IETF AVT WG >>> Cc: Clinton Priddle (KI/EAB) >>> Subject: [AVT] RE: [MMUSIC] questions about grouping media streams > in >> RTP >>> andSDP (RFC3388 etc), advice needed >>> >>> At 10:03 +0300 5/06/07, Even, Roni wrote: >>>> Dave, >>>> For layered encoding there is a proposal for a new grouping > attribute >> in >>>> http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec- >> 03.tx >>>> t >>> >>> I don't think this is a layered coding issue, either, alas. >>> >>>> I looked at RFC3388 and I think that FID is not the answer to your >>>> requirement as you mentioned >>>> >>>> To me it looks like what you are looking for is a way to specify >>>> alternate offers. >>> >>> No, these streams are not alternatives to each other in the regular >>> sense. Nor is this really used in offer/answer; it's more an issue >>> for multicast. In multicast, you open the tune-in stream and the >>> base stream, grab the first I-frame that arrives (in either) and > then >>> drop the tune-in stream. >>> >>> Yes, we're aware that the recipient needs to be able to tell which > is >>> the base and which is the tune-in. >>> >>>> If this is the case I have similar requirements and >>>> would be happy to support such work. >>>> >>>> You also need a way to give semantics to the "repair" stream, this > can >>>> be done based on the content attribute from RFC 4796 or using a >>>> dependency attribute see in Schierl's draft. The mid tag is not > enough >>>> for the receiver to know what you meant by this offer and which > stream >>>> is the repair. >>>> >>>> Here is an example for a solution using a new Alternatives grouping >>>> attribute and giving semantics to the repair stream >>>> >>>> By using the grouping attribute in the offer you can know if the >>>> answerer understood the grouping since if he does not than he will > send >>>> an answer with no a=group >>>> >>>> v=0 >>>> o=bob 280744730 28977631 IN IP4 host.example.com >>>> s= >>>> t=0 0 >>>> >>>> a=group:ALTS 1 2 >>>> a=group:ALTS 1 3 >>>> >>>> m=audio 6886 RTP/AVP 0 >>>> c=IN IP6 2001:0600::1 >>>> a=mid:1 >>>> >>>> m=video 9000 RTP/AVP 100 >>>> c=IN IP4 192.0.2.2 >>>> a=rtpmap:100 H263-1998 >>>> a=mid:2 >>>> >>>> m=video 9002 RTP/AVP 101 >>>> c=IN IP4 192.0.2.2 >>>> a=rtpmap:101 H263-1998 >>>> a=mid:3 >>>> a=content:repair=2 or a=depend:repair=2 >>>> >>>> >>>> Roni Even >>>> >>>>> -----Original Message----- >>>>> From: Dave Singer [mailto:singer@apple.com] >>>>> Sent: Monday, June 04, 2007 7:19 PM >>>>> To: mmusic; IETF AVT WG >>>>> Cc: Clinton Priddle (KI/EAB) >>>>> Subject: [MMUSIC] questions about grouping media streams in RTP > and >>>> SDP >>>>> (RFC3388 etc), advice needed >>>>> >>>>> Hi >>>>> >>>>> we have a need to group together two media streams, in the style > of >>>> RFC >>>>> 3388 but we're unsure > whether >> an >>>>> existing group type is suitable or not, and if it's not, we'd > like >> to >>>>> agree on a new one, and document it (presumably in an RFC). >>>>> >>>>> What we have is a normal media stream, and a separate 'repair' > or >>>>> 'entry' stream, that can be used when tuning in, or after loss, > but >> is >>>>> otherwise un-needed. An example might be a video stream with a > low >>>>> I-frame interval (say every 15 seconds), with a repair stream > which >>>> has >>>>> only I-frames that are equivalent to the time-parallel non-I > frame, >> at >>>> a >>>>> frequency of say 1 per second. >>>>> >>>>> It's not clear to us whether this is "one media flow" in the > sense >> of >>>>> FID, or not. The example offers AMR and GSM audio, which are >>>>> alternatives, and DTMF tones along with audio, which are >> supplementary >>>>> to each other. Perhaps we fall afoul of this restriction: >>>>> >>>>> "An application that encodes the same media using different > codecs >>>>> simultaneously MUST NOT use FID to group those media lines." >>>>> >>>>> or this one, for layered encoding: >>>>> >>>>> "FID MUST NOT be used to group "m" lines that do not represent > the >>>> same >>>>> information." (Though how DTMF tones and their associated audio >> pass >>>>> this test is not clear). >>>>> >>>>> Nor is it clear that the FEC group of RFC 4756 is right, either. >> For >>>> a >>>>> start, we may wish to use this new ID in combination with FEC, > and >>>>> secondly this tune-in stream has different characteristics. For >>>>> example, one can typically ignore all FEC and (as long as there > are >> no >>>>> errors) decode the stream correctly. Ignoring the tune-in > stream >>>>> entirely may mean that you will never find a tune-in point, > making >>> the >>>>> normal stream useless. >>>>> >>>>> So, can we use FID for associating a repair stream with its base > (we >>>> tag >>>>> the streams so we know which is which, of course)? >>>>> >>>>> p.s. RFC 4756 claims in the IANA section that the FEC group is >>>>> registered under SDP characteristics, but actually I can find no >>>>> registry anywhere in IANA of group types. >>>>> >>>>> >>>>> -- >>>>> David Singer >>>>> Apple/QuickTime >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> >>> -- >>> David Singer >>> Apple/QuickTime >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ > 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 Jun 08 10:30:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfTi-0004di-4Q; Fri, 08 Jun 2007 10:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfTg-0004dJ-Qm; Fri, 08 Jun 2007 10:30:12 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwfTf-0004vH-HW; Fri, 08 Jun 2007 10:30:12 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:60721) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HwfTZ-0000o3-Pg; Fri, 08 Jun 2007 15:30:05 +0100 In-Reply-To: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> References: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58FFB38C-B79B-4C13-A8D9-2CC7A5FC2EC0@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 8 Jun 2007 15:30:13 +0100 To: mmusic , Behave WG , IETF AVT WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Cullen Jennings , Magnus Westerlund , Xavier Marjou , Roni Even , Tom Taylor , Joerg Ott , Jean-Francois Mule , "Dan Wing \(\(\(\(dwing\)\)\)\)" Subject: [MMUSIC] Re: [AVT] Moving draft-marjou-behave-app-rtp-keepalive to AVT 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 1 Jun 2007, at 18:15, Colin Perkins wrote: > There has been some private discussion on adopting the draft on > Application Mechanisms for maintaining alive NAT mappings > associated with RTP flows (draft-marjou-behave-app-rtp- > keepalive-01.txt) as an AVT working group draft. This has > previously been discussed in AVT, BEHAVE and MMUSIC. Opinions on > whether this draft should become a working group draft, and on the > appropriate home for it, are solicited by 8 June 2007. There were several comments in favour of this proposal, and no objections. Accordingly, we will take this draft as an AVT work item. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 08 13:36:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwiNn-0002Ng-Sq; Fri, 08 Jun 2007 13:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwiNl-0002NZ-Qk for mmusic@ietf.org; Fri, 08 Jun 2007 13:36:19 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwiNl-0004ap-Dm for mmusic@ietf.org; Fri, 08 Jun 2007 13:36:17 -0400 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 l58HaD5Q030826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Jun 2007 10:36:13 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l58Ha9ii006597; Fri, 8 Jun 2007 10:36:13 -0700 Received: from NAEX01.qualcomm.com ([129.46.51.60]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:35:38 -0700 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] Question on unrecognized "a=" attributes in SDPoffer/answer Date: Fri, 8 Jun 2007 10:35:35 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B02DB6EBD@NAEX01.na.qualcomm.com> In-Reply-To: <7374777208BDC7449D5620EF9423256704F5EA88@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Question on unrecognized "a=" attributes in SDPoffer/answer Thread-Index: AcepVA1nQ6zKOJuzQsGwgESQLmD3sAATumKwABQHAOA= From: "Desineni, Harikishan" To: "Christer Holmberg (JO/LMF)" X-OriginalArrivalTime: 08 Jun 2007 17:35:38.0133 (UTC) FILETIME=[6D6C9C50:01C7A9F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Yes, such behavior makes sense and I believe most implementations match = this. Is it explicitly recommended in any RFC? (RFC3264 does not have = any text which recommends such a behavior) > -----Original Message----- > From: Christer Holmberg (JO/LMF) = [mailto:christer.holmberg@ericsson.com] > Sent: Friday, June 08, 2007 1:02 AM > To: Desineni, Harikishan; mmusic@ietf.org > Subject: RE: [MMUSIC] Question on unrecognized "a=3D" attributes in > SDPoffer/answer >=20 >=20 > Hi, >=20 > Since the receiver will discard attributes it doesn't understand I = don't > think it should put anything in the answer. Because, then the one who = sent > the offer may actually think that the other party DOES understand the > attribute. >=20 > Regards, >=20 > Christer >=20 > > -----Original Message----- > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > Sent: 8. kes=E4kuuta 2007 1:35 > > To: mmusic@ietf.org > > Subject: [MMUSIC] Question on unrecognized "a=3D" attributes in > > SDPoffer/answer > > > > >From reading RFC3264, it is not clear how an answerer should = prepare > > >SDP > > answer when "a=3D" attribute lines in SDP offer are unrecognized. > > > > For example, how should SDP answer look when attrib1 and > > attrib2 are "sendonly" attributes and the answerer does not > > recognize them. > > > > SDP offer with "sendonly" attribute and both media streams > > are "sendrecv" > > =3D=3D=3D=3D=3D=3D=3D=3D > > m=3Daudio > > a=3Dattrib1:value1 > > > > m=3Dvideo > > a=3D attrib2:value2 > > > > > > I think the best current practice is SDP answer (1). Is there > > any RFC which clearly describes this behavior? > > Answerer simply removes the unrecognized attributes while > > preparing the SDP answer. > > > > SDP answer (1) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > m=3Daudio > > m=3Dvideo > > > > Another possible answer if answerer simply ignores the > > unrecognized lines and does not remove them from SDP answer > > SDP answer (2) =3D=3D=3D=3D=3D=3D=3D=3D=3D m=3Daudio > > a=3Dattrib1:value1 > > > > m=3Dvideo > > a=3D attrib2:value2 > > > > > > I think that SDP answer (2) would result in issues. It might > > indicate that answerer is signaling attrib1/2 in > > answerer->offerer direction. > > > > _______________________________________________ > > 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 Jun 08 13:38:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwiPi-0003ov-8K; Fri, 08 Jun 2007 13:38:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwiPg-0003og-0I; Fri, 08 Jun 2007 13:38:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwiPf-0005sh-L1; Fri, 08 Jun 2007 13:38:15 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 Jun 2007 10:38:15 -0700 X-IronPort-AV: i="4.16,400,1175497200"; d="scan'208"; a="161287601:sNHT68893920" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l58HcE68025208; Fri, 8 Jun 2007 10:38:14 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l58HcCtV005245; Fri, 8 Jun 2007 17:38:12 GMT From: "Dan Wing" To: "'MMUSIC WG'" , Date: Fri, 8 Jun 2007 10:38:12 -0700 Message-ID: <010b01c7a9f3$cad91580$1ea36b80@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: <636AAD6D-F3F3-4965-8054-2AEB5EDC2872@cisco.com> Thread-Index: AcepQvBtpHWp0OALR7KTLZ8d+d/KyQApoZWQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3642; t=1181324294; x=1182188294; c=relaxed/simple; s=sjdkim2002; 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:=20Last=20Call=3A=20draft-ietf-dccp-rtp=20(RTP=20and=20the=20Dat agramCongestion=20Control=20Protocol=20(DCCP))=20to=20Proposed=20Standard= 20 |Sender:=20; bh=0UJEdW+ZbPFqplXDBX1+/yUZz+mEryp3gGi6pRHKdqU=; b=y1tHZ8W2C9q/crjeAToHcCWb5+klPHnR5bVeFp2PDTxoc3bEEUI4ySr0beTSoWOvgUQL4Emq P3NfZFjCKTV4Dgb24gIhdAHsPaLQ9s9OGFxKEnszO7cEuMvK7xEgQstO; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: 'Cullen Jennings' , 'Colin Perkins' Subject: [MMUSIC] Last Call: draft-ietf-dccp-rtp (RTP and the DatagramCongestion Control Protocol (DCCP)) to Proposed Standard 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 The draft is easy to read and understand. 1. Section 5.2, "Service Codes", refers to DCCP service codes. Several are defined in this specification (SC:RTPA, SC:RTPV, SC:RTPT, and SC:RTPO). The draft needs to say something about the relationship between the SDP media type field (the "audio" and "video" of m=audio and m=video) and the DCCP service code -- I expect they SHOULD match. 2. I wonder if an optimization would be useful, where "a=dccp-service-code:SC:RTPV" is assumed if the associated media type is "video" (m=video); a similar optimization seems reasonable for audio (RTPA is assumed when the media type is audio (m=audio)). 3. I believe the draft needs to define a value for its IANA-registered DCCP service codes, as service codes appear to be sent in the DCCP packets themselves according to RFC4340. 4. I'm surprised a=rtcp (RFC3605) lacked normative language in section 5.1. I know for UDP this is widely considered best practice. I'm not confident that we should expect DCCP will be able to avoid that quagmire. I suggest adding something like: If RTCP is to be sent on a separate DCCP connection to RTP, the RTCP connection SHOULD use the next higher destination port number, unless an alternative DCCP port is signalled using the "a=rtcp:" attribute [13]. For improved interoperability, "a=rtcp" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SHOULD be used whenever an alternative DCCP port is used. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -d > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, June 07, 2007 1:31 PM > To: MMUSIC WG > Subject: [MMUSIC] Fwd: Last Call: draft-ietf-dccp-rtp (RTP > and the DatagramCongestion Control Protocol (DCCP)) to > Proposed Standard > > > I would like to point out this last call is happening - if you have > opinions on the SDP usage in this draft - do not reply to > this email. > Reply on the IETF list. > > > Begin forwarded message: > > > From: The IESG > > Date: June 6, 2007 7:18:36 AM PDT > > To: IETF-Announce > > Cc: dccp@ietf.org > > Subject: Last Call: draft-ietf-dccp-rtp (RTP and the Datagram > > Congestion Control Protocol (DCCP)) to Proposed Standard > > Reply-To: ietf@ietf.org > > > > The IESG has received a request from the Datagram Congestion Control > > Protocol WG (dccp) to consider the following document: > > > > - 'RTP and the Datagram Congestion Control Protocol (DCCP) ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send substantive > comments to > > the > > ietf@ietf.org mailing lists by 2007-06-20. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either > case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-dccp-rtp-06.txt > > > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/public/pidtracker.cgi? > > command=view_id&dTag=15015&rfc_flag=0 > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > 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 Jun 08 17:24:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlws-0005JV-KR; Fri, 08 Jun 2007 17:24:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlwr-0005JQ-3V for mmusic@ietf.org; Fri, 08 Jun 2007 17:24:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwlwq-0004hq-D3 for mmusic@ietf.org; Fri, 08 Jun 2007 17:24:45 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BFAD7203BD; Fri, 8 Jun 2007 23:24:43 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-88-4669c91bed0c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9350A2007E; Fri, 8 Jun 2007 23:24:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 23:24:42 +0200 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] Question on unrecognized "a=" attributes in SDPoffer/answer Date: Fri, 8 Jun 2007 23:24:42 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704FC0D78@esealmw113.eemea.ericsson.se> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B02DB6EBD@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Question on unrecognized "a=" attributes in SDPoffer/answer thread-index: AcepVA1nQ6zKOJuzQsGwgESQLmD3sAATumKwABQHAOAACAxRMA== References: <7374777208BDC7449D5620EF9423256704F5EA88@esealmw113.eemea.ericsson.se> <2CA3E1B6CEC064449CAA7D0FAB46079B02DB6EBD@NAEX01.na.qualcomm.com> From: "Christer Holmberg (JO/LMF)" To: "Desineni, Harikishan" X-OriginalArrivalTime: 08 Jun 2007 21:24:42.0893 (UTC) FILETIME=[6DF08BD0:01C7AA13] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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,=20 >Yes, such behavior makes sense and I believe most=20 >implementations match this. Is it explicitly recommended in=20 >any RFC? (RFC3264 does not have any text which recommends=20 >such a behavior) I think it is said - somewhere - that unsupported attributes shall be = discarded, so personally I would say it's quite clear that they will = then not be part of the answer. Regards, Christer >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF)=20 > > [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, June 08, 2007 1:02 AM > > To: Desineni, Harikishan; mmusic@ietf.org > > Subject: RE: [MMUSIC] Question on unrecognized "a=3D" attributes in=20 > > SDPoffer/answer > >=20 > >=20 > > Hi, > >=20 > > Since the receiver will discard attributes it doesn't understand I=20 > > don't think it should put anything in the answer. Because, then the=20 > > one who sent the offer may actually think that the other party DOES=20 > > understand the attribute. > >=20 > > Regards, > >=20 > > Christer > >=20 > > > -----Original Message----- > > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > > Sent: 8. kes=E4kuuta 2007 1:35 > > > To: mmusic@ietf.org > > > Subject: [MMUSIC] Question on unrecognized "a=3D" attributes in=20 > > > SDPoffer/answer > > > > > > >From reading RFC3264, it is not clear how an answerer should=20 > > > >prepare SDP > > > answer when "a=3D" attribute lines in SDP offer are unrecognized. > > > > > > For example, how should SDP answer look when attrib1 and > > > attrib2 are "sendonly" attributes and the answerer does not=20 > > > recognize them. > > > > > > SDP offer with "sendonly" attribute and both media streams are=20 > > > "sendrecv" > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > m=3Daudio > > > a=3Dattrib1:value1 > > > > > > m=3Dvideo > > > a=3D attrib2:value2 > > > > > > > > > I think the best current practice is SDP answer (1). Is there any=20 > > > RFC which clearly describes this behavior? > > > Answerer simply removes the unrecognized attributes while=20 > preparing=20 > > > the SDP answer. > > > > > > SDP answer (1) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > m=3Daudio > > > m=3Dvideo > > > > > > Another possible answer if answerer simply ignores the=20 > unrecognized=20 > > > lines and does not remove them from SDP answer SDP answer (2)=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D m=3Daudio > > > a=3Dattrib1:value1 > > > > > > m=3Dvideo > > > a=3D attrib2:value2 > > > > > > > > > I think that SDP answer (2) would result in issues. It might=20 > > > indicate that answerer is signaling attrib1/2 in > > > answerer->offerer direction. > > > > > > _______________________________________________ > > > 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 Fri Jun 08 18:56:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwnNz-0006v8-82; Fri, 08 Jun 2007 18:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwnNx-0006t5-UR; Fri, 08 Jun 2007 18:56:49 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwnNx-0001H1-Hz; Fri, 08 Jun 2007 18:56:49 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (Postfix) with ESMTP id 1E22086FF98; Fri, 8 Jun 2007 15:56:49 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id EAF75100C6; Fri, 8 Jun 2007 15:56:48 -0700 (PDT) X-AuditID: 11807124-9fec6bb000000801-ca-4669deaf6740 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by relay6.apple.com (Apple SCV relay) with ESMTP id 463E310192; Fri, 8 Jun 2007 15:56:47 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com> Date: Fri, 8 Jun 2007 15:56:13 -0700 To: "Kalleitner, Franz" , "Even, Roni" , mmusic , IETF AVT WG From: Dave Singer Subject: Re: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Clinton Priddle \(KI/EAB\)" 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 At 11:54 +0200 5/06/07, Kalleitner, Franz wrote: >hi, dave, > >you can find some work and ideas on how to handle a "repair" stream >in parallel to an orignal RTP stream in RFC4588 too. > >cheers, franz Thank you. This has the rather useful paragraph: A special case of the SDP description is a description that contains only one original session "m" line and one retransmission session "m" line, the grouping is then obvious and FID semantics MAY be omitted in this special case only. Since this exactly describes our current situation -- the normal and repair streams are indeed easily identified, and we currently only allow one normal stream per session -- perhaps we will take this route, and let the standards catch up to where we need to be, if anyone has a need for multiple base streams in the future. And indeed, not doing grouping means avoiding having to insist that any audio or video streams in the same SDP also have a media ID (as the grouping RFC requires)., even though those IDs are not grouped. At 14:42 -0700 7/06/07, Stephan Wenger wrote: >Hi all, >Yes, i agree with Roni: This is not a layered codec case in any >sense, as there is no directed use hierarchy between those two >flows. Under certain conditions (i.e. in the absence of packet >loss), both are valid, usable streams. Is an SI AVC stream really a usable stream in its own right? >But, IMHO, this may be not a bad example for multiple description >coding. The two streams represent essentially the same media, and >(under certain conditions such as packet loss) it is advantageous to >use both of them, not only one. It may not be a direct hit on the >Schierl draft MDC use case, but it's close enough to be documentable >in a 3GPP spec. >I'm not sure that the use case in question warrants a new I-D. If >the analogy to video transmission would be a bit more solid, I would >have a different view. But, a it stands, you could not use the >mechanism envisioned with any predictive video codec (possible >exception: H.264 extended profile, utilizing SI/SP technology), as >it is at present close to impossible to generate identical reference >pictures from two different streams, using different encoding >methods. Actually I would have agreed with you until I found someone doing it in AVC successfully using I frames, not SI frames. At 14:47 -0700 7/06/07, Thomas Schierl wrote: >Then it would be something like we call 'mdc'. But I would like to put that >into an extra dependency type, since the characteristics of the streams are >different, even if they could be used exchangeable. But there is one main >stream, let us say. And that one should be identifiable. As I say, the rtpmap declarations and parameters identify the two streams, we have that in hand. We just wondered how we should group them -- and all that is needed is a group. Happily the quote above provides the short-term answer -- don't! -- David Singer Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jun 10 03:10:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxHYf-0001Xa-Dv; Sun, 10 Jun 2007 03:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxHYd-0001XS-Ds; Sun, 10 Jun 2007 03:09:51 -0400 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 1HxHYc-0006rB-Py; Sun, 10 Jun 2007 03:09:51 -0400 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: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed Date: Sun, 10 Jun 2007 10:10:50 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C049E7CE9@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed Thread-Index: AceqIGRW96FPkNzNR6+W8yMpOMfO8ABDcURQ From: "Even, Roni" To: "Dave Singer" , "Kalleitner, Franz" , "mmusic" , "IETF AVT WG" X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: "Clinton Priddle \(KI/EAB\)" 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 Dave, I understand that you intend to send two media streams using two m lines without grouping and any specific semantics to identify the stream. Our experience is that if you have two video m lines you can not know which one the other will pick if he does not understand the relation between the streams. Roni > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Saturday, June 09, 2007 1:56 AM > To: Kalleitner, Franz; Even, Roni; mmusic; IETF AVT WG > Cc: Clinton Priddle (KI/EAB) > Subject: Re: AW: [AVT] RE: [MMUSIC] questions about grouping media streams > in RTPand SDP (RFC3388 etc), advice needed >=20 > At 11:54 +0200 5/06/07, Kalleitner, Franz wrote: > >hi, dave, > > > >you can find some work and ideas on how to handle a "repair" stream > >in parallel to an orignal RTP stream in RFC4588 too. > > > >cheers, franz >=20 > Thank you. This has the rather useful paragraph: >=20 > A special case of the SDP description is a description that contains > only one original session "m" line and one retransmission session "m" > line, the grouping is then obvious and FID semantics MAY be omitted > in this special case only. >=20 > Since this exactly describes our current situation -- the normal and > repair streams are indeed easily identified, and we currently only > allow one normal stream per session -- perhaps we will take this > route, and let the standards catch up to where we need to be, if > anyone has a need for multiple base streams in the future. >=20 > And indeed, not doing grouping means avoiding having to insist that > any audio or video streams in the same SDP also have a media ID (as > the grouping RFC requires)., even though those IDs are not grouped. >=20 > At 14:42 -0700 7/06/07, Stephan Wenger wrote: > >Hi all, > >Yes, i agree with Roni: This is not a layered codec case in any > >sense, as there is no directed use hierarchy between those two > >flows. Under certain conditions (i.e. in the absence of packet > >loss), both are valid, usable streams. >=20 > Is an SI AVC stream really a usable stream in its own right? >=20 > >But, IMHO, this may be not a bad example for multiple description > >coding. The two streams represent essentially the same media, and > >(under certain conditions such as packet loss) it is advantageous to > >use both of them, not only one. It may not be a direct hit on the > >Schierl draft MDC use case, but it's close enough to be documentable > >in a 3GPP spec. > >I'm not sure that the use case in question warrants a new I-D. If > >the analogy to video transmission would be a bit more solid, I would > >have a different view. But, a it stands, you could not use the > >mechanism envisioned with any predictive video codec (possible > >exception: H.264 extended profile, utilizing SI/SP technology), as > >it is at present close to impossible to generate identical reference > >pictures from two different streams, using different encoding > >methods. >=20 > Actually I would have agreed with you until I found someone doing it > in AVC successfully using I frames, not SI frames. >=20 > At 14:47 -0700 7/06/07, Thomas Schierl wrote: > >Then it would be something like we call 'mdc'. But I would like to put > that > >into an extra dependency type, since the characteristics of the streams > are > >different, even if they could be used exchangeable. But there is one main > >stream, let us say. And that one should be identifiable. >=20 > As I say, the rtpmap declarations and parameters identify the two > streams, we have that in hand. We just wondered how we should group > them -- and all that is needed is a group. Happily the quote above > provides the short-term answer -- don't! > -- > David Singer > Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jun 10 23:03: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 1HxaBr-0006gY-Aw; Sun, 10 Jun 2007 23:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxaBq-0006gR-87 for mmusic@ietf.org; Sun, 10 Jun 2007 23:03:34 -0400 Received: from airmail.airvananet.com ([12.6.244.34] helo=airmail.wirelessworld.airvananet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxaBo-00089I-Sd for mmusic@ietf.org; Sun, 10 Jun 2007 23:03:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Jun 2007 23:02:37 -0400 Message-ID: <8F798BFDA851B943B3A1B2510E92878504BE40D5@airmail.wirelessworld.airvananet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of draft-whitehead-mmusic-sip-for-streaming-media-02 Thread-Index: Acer1QN2Cx1E9xxMRFuVAua5PoHRRQ== From: "Parameshwar Hegde" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [MMUSIC] Status of draft-whitehead-mmusic-sip-for-streaming-media-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: , Content-Type: multipart/mixed; boundary="===============0950041107==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0950041107== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ABD4.F78FE216" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ABD4.F78FE216 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Could someone please let me know the status of following proposal/draft. It expired in April 07. =20 draft-whitehead-mmusic-sip-for-streaming-media-02 =20 =20 =20 Regards --Param ---------------------------------------------- Parameshwar Hegde Architect Airvana Inc *: phegde@airvana.com www.airvana.com ---------------------------------------------- =20 ------_=_NextPart_001_01C7ABD4.F78FE216 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi,
 
Could someone please let me know the status =
of following proposal/draft. It expired in April =
07.
 
draft-whitehead-mmusic-sip-for-streaming-media-02

 

 

Regards

--Param

----------------------------------------------<= /font>

Parameshwar Hegde

Architect

Airvana Inc

*: phegde@airvana.com

       www.airvana.com

----------------------------------------------<= /font>

 

------_=_NextPart_001_01C7ABD4.F78FE216-- --===============0950041107== 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 --===============0950041107==-- From mmusic-bounces@ietf.org Mon Jun 11 11:24:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxllJ-0002Fr-GF; Mon, 11 Jun 2007 11:24:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxllH-0002Em-Mj; Mon, 11 Jun 2007 11:24:55 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HxllG-00050w-6U; Mon, 11 Jun 2007 11:24:55 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:52435) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HxllF-0006dy-Jh; Mon, 11 Jun 2007 16:24:53 +0100 In-Reply-To: <010b01c7a9f3$cad91580$1ea36b80@amer.cisco.com> References: <010b01c7a9f3$cad91580$1ea36b80@amer.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 Date: Mon, 11 Jun 2007 16:25:04 +0100 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Cullen Jennings , DCCP mailing list , MMUSIC WG , ietf@ietf.org Subject: [MMUSIC] Re: Last Call: draft-ietf-dccp-rtp (RTP and the DatagramCongestion Control Protocol (DCCP)) to Proposed Standard 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 Dan, On 8 Jun 2007, at 18:38, Dan Wing wrote: > The draft is easy to read and understand. > > 1. Section 5.2, "Service Codes", refers to DCCP service codes. > Several are > defined in this specification (SC:RTPA, SC:RTPV, SC:RTPT, and > SC:RTPO). The > draft needs to say something about the relationship between the SDP > media > type field (the "audio" and "video" of m=audio and m=video) and the > DCCP > service code -- I expect they SHOULD match. Yes - I'll clarify. > 2. I wonder if an optimization would be useful, where > "a=dccp-service-code:SC:RTPV" is assumed if the associated media > type is > "video" (m=video); a similar optimization seems reasonable for > audio (RTPA > is assumed when the media type is audio (m=audio)). I tend to prefer explicit to implicit, so while this would reduce the size of the SDP slightly, I'm not sure it's worthwhile. > 3. I believe the draft needs to define a value for its IANA- > registered DCCP > service codes, as service codes appear to be sent in the DCCP packets > themselves according to RFC4340. The service codes sent in the DCCP packets are the 4-character ASCII strings listed (e.g. RTPV). > 4. I'm surprised a=rtcp (RFC3605) lacked normative language in > section 5.1. > I know for UDP this is widely considered best practice. I'm not > confident > that we should expect DCCP will be able to avoid that quagmire. I > suggest > adding something like: > > If RTCP is to be sent on a separate DCCP connection > to RTP, the RTCP connection SHOULD use the next higher destination > port number, unless an alternative DCCP port is signalled using the > "a=rtcp:" attribute [13]. For improved interoperability, "a=rtcp" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > SHOULD be used whenever an alternative DCCP port is used. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Makes sense - I'll add this. Cheers, -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 11 14:51:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxozL-0006Cw-OQ; Mon, 11 Jun 2007 14:51:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxozJ-00068U-CR; Mon, 11 Jun 2007 14:51:37 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxozI-0004iG-1m; Mon, 11 Jun 2007 14:51:37 -0400 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out4.apple.com (Postfix) with ESMTP id C1B558B4466; Mon, 11 Jun 2007 11:51:35 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 8062C40101; Mon, 11 Jun 2007 11:51:35 -0700 (PDT) X-AuditID: 11807126-a0085bb00000081c-eb-466d99b70f0d Received: from [17.202.35.52] (unknown [17.219.198.136]) by relay8.apple.com (Apple SCV relay) with ESMTP id 1550840103; Mon, 11 Jun 2007 11:51:35 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C049E7CE9@IsrExch01.israel.polycom.com> References: <144ED8561CE90C41A3E5908EDECE315C049E7CE9@IsrExch01.israel.polycom.com> Date: Mon, 11 Jun 2007 11:51:24 -0700 To: "Even, Roni" , "Kalleitner, Franz" , mmusic , IETF AVT WG From: Dave Singer Subject: RE: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Clinton Priddle \(KI/EAB\)" 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 At 10:10 +0300 10/06/07, Even, Roni wrote: >Dave, >I understand that you intend to send two media streams using two m lines >without grouping and any specific semantics to identify the stream. >Our experience is that if you have two video m lines you can not know >which one the other will pick if he does not understand the relation >between the streams. >Roni Roni you keep missing that the streams have attributes that tell me which is which. m=video a=fmtp: yes this is a foobar primary stream m=video a=fmtp:yes this is a foobar repair stream if I see such an SDP with only one foobar primary and only one foobar repair, it's fairly clear that the foobar repair stream is associated with the foobar primary stream, without needing grouping. I only need grouping if I have two primary streams, and that use case is not yet in our requirements. It would be nice to document, but we're not in a hurry. -- David Singer Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 11 22:39:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxwIM-0002ep-Hv; Mon, 11 Jun 2007 22:39:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxwIL-0002ZS-Oj for mmusic@ietf.org; Mon, 11 Jun 2007 22:39:45 -0400 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 1HxwIK-0000uS-CA for mmusic@ietf.org; Mon, 11 Jun 2007 22:39:45 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 11 Jun 2007 19:39:43 -0700 X-IronPort-AV: i="4.16,409,1175497200"; d="scan'208"; a="2612197:sNHT1013284524" 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 l5C2dd6i021093; Mon, 11 Jun 2007 19:39:40 -0700 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 l5C2VDtj027252; Tue, 12 Jun 2007 02:39:39 GMT 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, 11 Jun 2007 19:39:25 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 19:39:25 -0700 Message-ID: <466E075C.4030307@cisco.com> Date: Mon, 11 Jun 2007 22:39:24 -0400 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: Xavier Marjou Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt References: <458913680704182329i56c1277vc6027fd4d83952a3@mail.gmail.com> In-Reply-To: <458913680704182329i56c1277vc6027fd4d83952a3@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2007 02:39:25.0369 (UTC) FILETIME=[E402FA90:01C7AC9A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1878; t=1181615981; x=1182479981; c=relaxed/simple; s=sjdkim3002; 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=20[MMUSIC]=20WGLC=3A=20draft-ietf-mmusic-ice-15.txt |Sender:=20; bh=OxLQUKjKxpuzGF5JiHIMhRXxeINZ8nagcbBpnxnLz8g=; b=JKRtsY+i+uZZwiI3hH3jLabFB+opZYJuXrDehGHTtB5hwQf5TquKZcf6cjyYA0pEAB6m7lAJ bOg/SHSaIkqJPS0m/zlWzjfLYtOXuMsd3b+Ie1Zr4XgwMuX9th6UCWIY; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Putting the finishing touches on -16 right now. Responses inline: Xavier Marjou wrote: > Here are some comments: > > Title: > - Replace "Methodology" by "Protocol", since "protocol" is used in > introduction. done. > > Section 5.7.3 "Pruning the Pairs" > - Why is a local relayed candidate not also replaced by its base, as > well as for a local reflexive candidate? Because checks in that case are not the same as a host candidate. WIth a relayed candidate, you'll do a TURN send, rather than sending directly from the local socket. The results can differ as a consequence. > > Section 7.2 "Server Procedures" > - What happens if the credential is unknown? Is the request silently > discarded? This should never happen based on this protocol. As a general rule I do not specify treatment for cases that are not possible unless there is protocol implementation errors somewhere. > > Section 12.1.1 "Offer in INVITE": > - My opinion is to keep a single one with RFC3262 and not to add a 2nd > mechanism for doing it. I assume you mean reliability of provisional responses. This feature of ICE was contentious but we did achieve consensus on it. I don't see any reason to reopen this concluded topic at this time. > - Typo: replace "3264" by "3262", "th exponential" by "the > exponential", and "transmission of a 2XX response" by "transmission of > the answer in a 2XX response". done. > > Other: > - Replace 3 instances of "offeror" by "offerer" done. Thanks, 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 From mmusic-bounces@ietf.org Tue Jun 12 00:01:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxxYy-00012o-Bd; Tue, 12 Jun 2007 00:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxxYw-000114-R5; Tue, 12 Jun 2007 00:00:58 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxxYu-0001LE-Jl; Tue, 12 Jun 2007 00:00:58 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 00:00:56 -0400 To: Dave Singer Subject: Re: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed References: <144ED8561CE90C41A3E5908EDECE315C049E7CE9@IsrExch01.israel.polycom.com> From: Randell Jesup Date: Tue, 12 Jun 2007 00:00:54 -0400 In-Reply-To: (Dave Singer's message of "Mon, 11 Jun 2007 11:51:24 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 12 Jun 2007 04:00:56.0287 (UTC) FILETIME=[4739D6F0:01C7ACA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Clinton Priddle \(KI/EAB\)" , "Even, Roni" , mmusic , IETF AVT WG , "Kalleitner, Franz" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dave Singer writes: >At 10:10 +0300 10/06/07, Even, Roni wrote: >>I understand that you intend to send two media streams using two m lines >>without grouping and any specific semantics to identify the stream. >>Our experience is that if you have two video m lines you can not know >>which one the other will pick if he does not understand the relation >>between the streams. >you keep missing that the streams have attributes that tell me which is which. > >m=video >a=fmtp: yes this is a foobar primary stream >m=video >a=fmtp:yes this is a foobar repair stream > >if I see such an SDP with only one foobar primary and only one foobar >repair, it's fairly clear that the foobar repair stream is associated with >the foobar primary stream, without needing grouping. Roni's point was really not that *you* wouldn't be able to tell, but that some other UA (which "does not understand the relation beween the streams") could/would mis-interpret the SDP. This of course assumes they think at least one payload for each stream is something they know how to send/receive. That's also a problem with the current grouping RFC (along with the chicken-and-egg syndrome). -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 12 00:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxyTA-0003Ih-JW; Tue, 12 Jun 2007 00:59:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxyT9-0003IU-M4; Tue, 12 Jun 2007 00:59:03 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxyT9-0003nK-9T; Tue, 12 Jun 2007 00:59:03 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (Postfix) with ESMTP id E18998C0EFC; Mon, 11 Jun 2007 21:59:02 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id C965D29C003; Mon, 11 Jun 2007 21:59:02 -0700 (PDT) X-AuditID: 11807123-9e01ebb000000a23-1a-466e2816fffe Received: from [17.202.35.52] (unknown [17.151.73.94]) by relay5.apple.com (Apple SCV relay) with ESMTP id 4A2DE30400B; Mon, 11 Jun 2007 21:59:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <144ED8561CE90C41A3E5908EDECE315C049E7CE9@IsrExch01.israel.polycom.com> Date: Mon, 11 Jun 2007 21:57:38 -0700 To: Randell Jesup From: Dave Singer Subject: Re: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Clinton Priddle \(KI/EAB\)" , "Kalleitner, Franz" , "Even, Roni" , mmusic , IETF AVT 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 At 0:00 -0400 12/06/07, Randell Jesup wrote: >Dave Singer writes: >>At 10:10 +0300 10/06/07, Even, Roni wrote: >>>I understand that you intend to send two media streams using two m lines >>>without grouping and any specific semantics to identify the stream. >>>Our experience is that if you have two video m lines you can not know >>>which one the other will pick if he does not understand the relation >>>between the streams. > >>you keep missing that the streams have attributes that tell me >>which is which. >> >>m=video >>a=fmtp: yes this is a foobar primary stream >>m=video >>a=fmtp:yes this is a foobar repair stream >> >>if I see such an SDP with only one foobar primary and only one foobar >>repair, it's fairly clear that the foobar repair stream is associated with >>the foobar primary stream, without needing grouping. > >Roni's point was really not that *you* wouldn't be able to tell, but that >some other UA (which "does not understand the relation beween the streams") >could/would mis-interpret the SDP. This of course assumes they think at >least one payload for each stream is something they know how to >send/receive. Ah, OK. Sure, if I was introducing this for an existing media type, and the payload type of the repair stream was recognizable (maybe the same), that would be a problem. My immediate need is for a new codec, and anyone who can decode either stream will have read the document that contains the media tagging, so I think I dodge that bullet also. > >That's also a problem with the current grouping RFC (along with the >chicken-and-egg syndrome). > >-- >Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team >rjesup@wgate.com >"The fetters imposed on liberty at home have ever been forged out of >the weapons >provided for defence against real, pretended, or imaginary dangers >from abroad." > - James Madison, 4th US president (1751-1836) > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic -- David Singer Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 12 03:00:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0N3-00006O-Va; Tue, 12 Jun 2007 03:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0N2-0008VP-0r; Tue, 12 Jun 2007 03:00:52 -0400 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 1Hy0N0-0005Bb-F2; Tue, 12 Jun 2007 03:00:52 -0400 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: AW: [AVT] RE: [MMUSIC] questions about grouping media streamsin RTPand SDP (RFC3388 etc), advice needed Date: Tue, 12 Jun 2007 10:01:26 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04A6FB61@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [AVT] RE: [MMUSIC] questions about grouping media streamsin RTPand SDP (RFC3388 etc), advice needed Thread-Index: Acesroucu/Kdm0wfTYSUcgd633mKcAAEJ9Og From: "Even, Roni" To: "Dave Singer" , "Randell Jesup" X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Clinton Priddle \(KI/EAB\)" , mmusic , IETF AVT WG , "Kalleitner, Franz" 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 Dave, Now we are going to a different topic. Is this a specific codec topic or a general media repair stream.=20 I thought that we are addressing a general dependency problem and not a one specific codec problem. Roni > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Tuesday, June 12, 2007 7:58 AM > To: Randell Jesup > Cc: Clinton Priddle (KI/EAB); Kalleitner,Franz; Even, Roni; mmusic; IETF > AVT WG > Subject: Re: AW: [AVT] RE: [MMUSIC] questions about grouping media > streamsin RTPand SDP (RFC3388 etc), advice needed >=20 > At 0:00 -0400 12/06/07, Randell Jesup wrote: > >Dave Singer writes: > >>At 10:10 +0300 10/06/07, Even, Roni wrote: > >>>I understand that you intend to send two media streams using two m > lines > >>>without grouping and any specific semantics to identify the stream. > >>>Our experience is that if you have two video m lines you can not know > >>>which one the other will pick if he does not understand the relation > >>>between the streams. > > > >>you keep missing that the streams have attributes that tell me > >>which is which. > >> > >>m=3Dvideo > >>a=3Dfmtp: yes this is a foobar primary stream > >>m=3Dvideo > >>a=3Dfmtp:yes this is a foobar repair stream > >> > >>if I see such an SDP with only one foobar primary and only one foobar > >>repair, it's fairly clear that the foobar repair stream is associated > with > >>the foobar primary stream, without needing grouping. > > > >Roni's point was really not that *you* wouldn't be able to tell, but that > >some other UA (which "does not understand the relation beween the > streams") > >could/would mis-interpret the SDP. This of course assumes they think at > >least one payload for each stream is something they know how to > >send/receive. >=20 > Ah, OK. Sure, if I was introducing this for an existing media type, > and the payload type of the repair stream was recognizable (maybe the > same), that would be a problem. >=20 > My immediate need is for a new codec, and anyone who can decode > either stream will have read the document that contains the media > tagging, so I think I dodge that bullet also. >=20 > > > >That's also a problem with the current grouping RFC (along with the > >chicken-and-egg syndrome). > > > >-- > >Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS > team > >rjesup@wgate.com > >"The fetters imposed on liberty at home have ever been forged out of > >the weapons > >provided for defence against real, pretended, or imaginary dangers > >from abroad." > > - James Madison, 4th US president (1751-1836) > > > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 > -- > David Singer > Apple/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 Tue Jun 12 03:06: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 1Hy0SZ-0002lX-OO; Tue, 12 Jun 2007 03:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0SY-0002lE-6M; Tue, 12 Jun 2007 03:06:34 -0400 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 1Hy0SX-0007hf-GZ; Tue, 12 Jun 2007 03:06:34 -0400 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: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed Date: Tue, 12 Jun 2007 10:07:09 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04A6FB67@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed Thread-Index: AcespnQuxIz3v3tWQVGzi83gVe89awAGS9CQ From: "Even, Roni" To: "Randell Jesup" , "Dave Singer" X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Clinton Priddle \(KI/EAB\)" , mmusic , IETF AVT WG , "Kalleitner, Franz" 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 Randell, I think that using grouping gives a better hint to the offerer if the answer do not support this group semantics by excluding the group attribute in the answer=20 If you just give two m-lines the answer does not tell if the answerer support two streams and decided for the moment to do one or if it does not support/understand the meaning of the offer. BTW: I think that this may have some relation also to the service tag work but this may open a can of worms Roni =20 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Tuesday, June 12, 2007 7:01 AM > To: Dave Singer > Cc: Even, Roni; Kalleitner, Franz; mmusic; IETF AVT WG; Clinton Priddle > (KI/EAB) > Subject: Re: AW: [AVT] RE: [MMUSIC] questions about grouping media streams > in RTPand SDP (RFC3388 etc), advice needed >=20 > Dave Singer writes: > >At 10:10 +0300 10/06/07, Even, Roni wrote: > >>I understand that you intend to send two media streams using two m lines > >>without grouping and any specific semantics to identify the stream. > >>Our experience is that if you have two video m lines you can not know > >>which one the other will pick if he does not understand the relation > >>between the streams. >=20 > >you keep missing that the streams have attributes that tell me which is > which. > > > >m=3Dvideo > >a=3Dfmtp: yes this is a foobar primary stream > >m=3Dvideo > >a=3Dfmtp:yes this is a foobar repair stream > > > >if I see such an SDP with only one foobar primary and only one foobar > >repair, it's fairly clear that the foobar repair stream is associated > with > >the foobar primary stream, without needing grouping. >=20 > Roni's point was really not that *you* wouldn't be able to tell, but that > some other UA (which "does not understand the relation beween the > streams") > could/would mis-interpret the SDP. This of course assumes they think at > least one payload for each stream is something they know how to > send/receive. >=20 > That's also a problem with the current grouping RFC (along with the > chicken-and-egg syndrome). >=20 > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS > team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out of the > weapons > provided for defence against real, pretended, or imaginary dangers from > abroad." > - James Madison, 4th US president (1751-1836) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 12 04:01:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1JW-0001PE-N6; Tue, 12 Jun 2007 04:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1JS-0001OL-8z; Tue, 12 Jun 2007 04:01:14 -0400 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 1Hy1JQ-0007HB-It; Tue, 12 Jun 2007 04:01:14 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C80i90007537; Tue, 12 Jun 2007 11:01:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:01:08 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:01:08 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:01:08 +0300 Received: from [172.21.35.94] (esdhcp03594.research.nokia.com [172.21.35.94]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C816jm023828; Tue, 12 Jun 2007 11:01:07 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Date: Tue, 12 Jun 2007 11:01:04 +0300 To: tsvwg WG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jun 2007 08:01:08.0418 (UTC) FILETIME=[D5868220:01C7ACC7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Behave WG , IETF AVT WG , mmusic Subject: [MMUSIC] draft-ietf-tsvwg-udp-guidelines-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg WG List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0194425633==" Errors-To: mmusic-bounces@ietf.org --===============0194425633== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--682882164; protocol="application/pkcs7-signature" --Apple-Mail-9--682882164 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Gorry and me just submitted a new -01 version of the "UDP Usage Guidelines for Application Designers" draft that TSVWG is putting together as a BCP. Compared to the -00 version, this draft adds a new Section 3.5 that gives middlebox traversal guidelines. (I'm cross-posting to AVT, MMUSIC and BEHAVE, because this addition was triggered by the recent discussion around draft-marjou-behave-app- rtp-keepalive. Please discuss draft-ietf-tsvwg-udp-guidelines on the TSVWG list; I'm setting the reply-to accordingly.) We'd be interested in comments, both from TSV folks but especially from RAI people, who might not have had this on their radar. Lars --Apple-Mail-9--682882164 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MTIwODAxMDRaMCMGCSqGSIb3DQEJBDEWBBTioSuoUwcZjUaQ E3XWTcgn3290IzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAyElFq8OXQqqtH/+fJytFT+6ri6pRz9Ze1P+nXrBA2Qhk6TZ8QvLN TJC21TB4NrgZ696G002aUbwLNB0/6J/pGmOtGdWANUyNU5hn/kbs3a5JfDUMLDAZsDm/EZ5QiaE5 eQs+u0qI1GeHWzJuEmgdnx8RVP8Pup/sqMkyX+2QIS4ZCpZRFlAIEpGwZhswpcA5CO9Ag0hENMg7 kZp2sGkZD5zLzNBCd2MnmklRuSsn2D7c1wOcUdffSJ1p8Gy7jVk7ZxtYcGm5m8wLJpQSDBpxC1zI kJyhXvgedxXFpZU+yfYjtxCsQLmG0bpF+uPVLYGtnHWIUSzD8zQu2QiHYW4geAAAAAAAAA== --Apple-Mail-9--682882164-- --===============0194425633== 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 --===============0194425633==-- From mmusic-bounces@ietf.org Tue Jun 12 11:35:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8Og-0002p0-Kq; Tue, 12 Jun 2007 11:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8Oe-0002ib-Tq; Tue, 12 Jun 2007 11:35:04 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8Od-0001hM-7k; Tue, 12 Jun 2007 11:35:04 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (Postfix) with ESMTP id CF9E58CBED9; Tue, 12 Jun 2007 08:35:02 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id BDF58101A6; Tue, 12 Jun 2007 08:35:02 -0700 (PDT) X-AuditID: 11807124-a16c9bb000000801-cc-466ebd268213 Received: from [17.202.35.52] (unknown [17.151.68.83]) by relay6.apple.com (Apple SCV relay) with ESMTP id 4CDAB100AB; Tue, 12 Jun 2007 08:35:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04A6FB61@IsrExch01.israel.polycom.com> References: <144ED8561CE90C41A3E5908EDECE315C04A6FB61@IsrExch01.israel.polycom.com> Date: Tue, 12 Jun 2007 08:34:39 -0700 To: "Even, Roni" , Randell Jesup From: Dave Singer Subject: RE: AW: [AVT] RE: [MMUSIC] questions about grouping media streamsin RTPand SDP (RFC3388 etc), advice needed Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "Clinton Priddle \(KI/EAB\)" , mmusic , IETF AVT WG , "Kalleitner, Franz" 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 At 10:01 +0300 12/06/07, Even, Roni wrote: >Dave, >Now we are going to a different topic. >Is this a specific codec topic or a general media repair stream. >I thought that we are addressing a general dependency problem and not a >one specific codec problem. >Roni If there was a solution to the general problem available, then I would have used it. But the immediate need is for a specific, new, codec and payload format; the example I gave of a video codec was just an example (and simpler to explain). -- David Singer Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 12 14:18:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyAwG-0000C9-Bf; Tue, 12 Jun 2007 14:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyAwD-0000C3-JF for mmusic@ietf.org; Tue, 12 Jun 2007 14:17:53 -0400 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 1HyAwB-00017j-6g for mmusic@ietf.org; Tue, 12 Jun 2007 14:17:53 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2007 11:17:51 -0700 X-IronPort-AV: i="4.16,412,1175497200"; d="scan'208"; a="378754993:sNHT94609942" 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 l5CIHo43024905; Tue, 12 Jun 2007 11:17:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5CIHoaI005097; Tue, 12 Jun 2007 18:17:50 GMT 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); Tue, 12 Jun 2007 11:17:50 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:17:49 -0700 Message-ID: <466EE34C.3070604@cisco.com> Date: Tue, 12 Jun 2007 14:17:48 -0400 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: Philip Matthews References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2007 18:17:49.0130 (UTC) FILETIME=[FBAB1AA0:01C7AD1D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=29618; t=1181672270; x=1182536270; c=relaxed/simple; s=sjdkim4002; 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=20Minor=20comments=20on=20ICE-15 |Sender:=20; bh=3HeZfra//S24iJA8ALzFT/aca9Tlx78edqtOElFIP3I=; b=kwvsEXPXODYj8mCUDqHfzK5Ik4RD9MpSwsYHKM8+90j0nAXFAu6q1qs0Pk0IasYIko4Fq32a Ne1mOq1CD5CVgaHZCYYkqu9OjbzylTkE0hPupN6DaRP5dw1tJEZ000QO; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 3.2 (+++) X-Scan-Signature: 0807e85f6792b2e267100df15b13cd9b Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Minor comments on ICE-15 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. Responses inline. Philip Matthews wrote: > Jonathan: > > Below are some more comments on ICE-15. Most of them are minor > editorial comments. > I have extracted text from ICE-15, and then put in comments marked with > "PM:". > > - Philip > > > ---------------- > > The basic idea behind ICE is as follows: each agent has a variety of > candidate TRANSPORT ADDRESSES (combination of IP address and port) it > could use to communicate with the other agent. These might include: > > o A transport address on a directly attached network interface or > interfaces > PM: s/or interfaces// (since a given transport address can only be on > one interface) > done > ---- > > Next, the agent uses STUN to obtain additional candidates. These > come in two flavors: translated addresses on the public side of a NAT > (SERVER REFLEXIVE CANDIDATES) and addresses of media relays (RELAYED > CANDIDATES). The relationship of these candidates to the host > candidate is shown in Figure 2. Both types of candidates are > PM: s/in Figure 2/in Figure 2 (here the notation "X:x" means IP address > X and port x)./ > discovered using STUN. > fixed. > ---- > > To find a server reflexive candidate, the agent sends a STUN Binding > Request, using the Binding Discovery Usage [12] from each host > candidate, to its STUN server. It is assumed that the address of the > STUN server is manually configured or learned in some unspecified > way. It is RECOMMENDED that when an agent has a choice of STUN > servers (when, for example, they are learned through DNS records and > multiple results are returned), an agent uses a single STUN server > (based on its IP address) for all candidates for a particular > session. This improves the performance of ICE. > PM: First of all, I suggest NOT placing normative text in the Overview > section. > More fundamentally, there are topologies where one absolutely wants to use > multiple STUN servers. After all, this is the main point of the draft > that you > co-authored with Dan Wing on discovering STUN servers. THis text got stuck in the wrong place and belongs in the section on server reflexive canddiates. I moved it there. ANyway what this is saying is that for each stun server you want to use, pick one amongst the values returned from DNS and don't load balance within a session. I clarified. > > ---- > > Each candidate is associated with a property called its FOUNDATION. > Two candidates have the same foundation when they are "similar" - of > the same type and obtained from the same interfaces and STUN servers. > PM: s/interfaces/interface/ and s/servers/server/. fixed > Otherwise, their foundation is different. A candidate pair has a > foundation too, which is just the concatenation of the foundations of > its two candidates. Initially, only the candidate pairs with unique > foundations are tested. The other candidate pairs are marked > "frozen". When the connectivity checks for a candidate pair succeed, > the candidate pairs with the same foundation are unfrozen. This > PM: s/the candidate pairs/other candidate pairs/ ? fixed > avoids repeated checking of components which are superficially more > attractive but in fact are likely to fail. > > ---- > > With regular nomination, the controlling agent lets the checks > continue until at least one valid candidate pair for each media > stream is found. Then, it picks amongst those that are valid, and > sends a second STUN request on its NOMINATED candidate pair, but this > time with a flag set to tell the peer that this pair has been > nominated for use. A This is shown in Figure 4. > PM: s/A This/This/ fixed > > ---- > > 2.7. Lite Implementations > > In order for ICE to be used in a call, both agents need to support > it. However, certain agents will always be connected to the public > Internet and have a public IP address at which it can receive packets > from any correspondent. To make it easier for these devices to > support ICE, ICE defines a special type of implementation called LITE > (in contrast to the normal FULL implementation). A lite > implementation doesn't gather candidates; it includes only host > candidates for any media stream. When a lite implementation connects > with a full implementation, the full agent takes the role of the > controlling agent, and the lite agent takes on the controlled role. > In addition, lite agents do not need to generate connectivity checks, > run the state machines, or compute candidate pairs. Additional > PM: s/Additional/For/ > guidance on when a lite implementation is appropriate, see the > discussion in Appendix A. fixed > > ---- > > Default Destination/Candidate: The default destination for a > component of a media stream is the transport address that would be > used by an agent that is not ICE aware. For the RTP component, > the default IP address is in the c line of the SDP, and the port > in the m line. For the RTCP component it is in the rtcp attribute > when present, and when not present, the IP address in the c line > and 1 plus the port in the m line. A default candidate for a > component is one whose transport address matches the default > destination for that component. > PM: The term "default" doesn't work very well when you talk about a > re-offer that specifies a new "default" value. I'm not going to change this term at this point. Its changed like three times already. Its the default because its where media is sent if ICE were not in use, and that is true in re-invites too. > > ---- > > The agent will receive a STUN Binding or Allocate response. A > successful Allocate Response will provide the agent with a server > reflexive candidate (obtained from the mapped address) and a relayed > candidate in the RELAY-ADDRESS attribute. If the Allocate request is > rejected because the server lacks resources to fulfill it, the agent > SHOULD instead send a Binding Request to obtain a server reflexive > candidate. A Binding Response will provide the agent with only a > server reflexive candidate (also obtained from the mapped address). > The base of the server reflexive candidate is the host candidate from > which the Allocate or Binding request was sent. The base of a > relayed candidate is that candidate itself. If a relayed candidate > is identical to a host candidate (which can happen in rare cases), > the relayed candidate MUST be discarded. Proper operation of ICE > depends on candidate having a unique base when their transport > addresses are identical. > PM: You are mixing singular and plural in this sentence. > PM: The operation implied by the last two sentences seems to be the same > as that described in the next section. Actually the second sentence is stale and needs to be discarded. The first sentence states the rule - eliminate a relayed candidate that equals a host candidate. > > ---- > > 4.1.1.3. Eliminating Redundant Candidates > > Next, the agent eliminates redundant candidates. A candidate is > redundant if its transport address equals another candidate, and its > base equals the base of that other candidate. Note that two > candidates can have the same transport address yet have different > bases, and these would not be considered redundant. > > PM: Which candidate should be kept? The highest priority candidate? At this point in the spec, there hasn't been prioritization. It doesnt really matter which is eliminated, so I don't want to introduce priorities here. > > 4.1.1.4. Computing Foundations > > Finally, the agent assigns each candidate a foundation. The > foundation is an identifier, scoped within a session. Two candidates > MUST have the same foundation ID when all of the following are true: > > o they are of the same type (host, relayed, server reflexive, peer > reflexive or relayed) > PM: "relayed" appears twice fixed > > ---- > > Each candidate is assigned a foundation. The foundation MUST be > different for two candidates from different interfaces, and MUST be > the same otherwise. A simple integer that increments for each > interface will suffice. In addition, each candidate MUST be assigned > a unique priority amongst all candidates for the same media stream. > PM: s/all candidates/all local candidates/ Everywhere else in this section, it is implicitly talking about local candidates since we havent exchanged candidates. So I dont see a need to add that qualifier here. > This priority SHOULD be equal to 2^24*(126) + 2^8*(65535) + 256 minus > the component ID, which is 2130706432 minus the component ID. > > If an agent has included two candidates for a component, the v4 > candidate SHOULD be selected as the default. Since a lite > PM: How can a lite agent include two candidates for a component. ??? > implementation has a single candidate for a component, each of these > candidates is considered to be default. lol. This is actually leftover text for when I tried (the first time) to work in the ability for lite implementations to support multiple host candidates. This is all changed now. > > ---- > > STUN connectivity checks between agents make use of a short term > credential that is exchanged in the offer/answer process. The > username part of this credential is formed by concatenating a > username fragment from each agent, separated by a colon. Each agent > also provides a password, used to compute the message integrity for > requests it receives. The username fragment and password are > PM: s/receives/sends/ NO. Remember when a server receives a request it recomputes the message integrity and compares it. So the password I select is used to construct M-I in requests sent to me, not ones I send. > exchanged in the ice-ufrag and ice-pwd attributes, respectively. In > addition to providing security, the username provides disambiguation > and correlation of checks to media streams. See Appendix B.4 for > motivation. > > ---- > > v=0 > o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 > s= > c=IN IP4 192.0.2.3 > t=0 0 > a=ice-pwd:asd88fgpdd777uzjYhagZg > a=ice-ufrag:8hhY > m=audio 45664 RTP/AVP 0 > b=RS:0 > b=RR:0 > a=rtpmap:0 PCMU/8000 > a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ host > a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr > 10.0.1.1 rport 8998 > PM: How are these priority value computed? I would have expected a > value of 2,130,706,431 and 1,694,498,815 respectively. Yes, I get the same results. Must be based on a formula in a previous draft. Fixed. > > ---- > > o For each media stream, the default destination for at least one > component of the media stream appears in a candidate attribute. > For example, in the case of RTP, the IP address and port in the c > and m line, respectively, appears in a candidate attribute, or the > value in the rtcp attribute appears in a candidate attribute. > PM: Why just "at least one component"? Why not all components? THis is now fixed. > > ---- > > Once roles are determined for a session, they persist unless ICE is > restarted. A ICE restart (Section 9.1 causes a new selection of > roles and tie-breakers. > PM: s/9.1/9.1)/ fixed > > ---- > > 5.7.2. Computing Pair Priority and Ordering Pairs > > Once the pairs are formed, a candidate pair priority is computed. > Let O be the priority for the candidate provided by the offerer. Let > A be the priority for the candidate provided by the answerer. The > priority for a pair is computed as: > > pair priority = 2^32*MIN(O,A) + 2*MAX(O,A) + (O>A?1:0) > > Where O-P>A-P?1:0 is an expression whose value is 1 if O-P is greater > than A-P, and 0 otherwise. This formula ensures a unique priority > PM: Do you mean "O" rather than "O-P" and "A" rather than "A-P"? > > for each pair in most cases. Once the priority is assigned, the > agent sorts the candidate pairs in decreasing order of priority. If > two pairs have identical priority, the ordering amongst them is > arbitrary. yes this is fixed. > > ---- > > 5.7.3. Pruning the Pairs > > This sorted list of candidate pairs is used to determine a sequence > of connectivity checks that will be performed. Each check involves > sending a request from a local candidate to a remote candidate. > Since an agent cannot send requests directly from a reflexive > candidate, but only from its base, the agent next goes through the > sorted list of candidate pairs. For each pair where the local > candidate is server reflexive, the server reflexive candidate MUST be > replaced by its base. Once this has been done, the agent MUST prune > PM: A candidate is replaced by its corresponding base candidate. In > other words, all the associated information about the candidate (e.g., > its foundation) is replaced by the associated information for its base. No, thats not true. Just the base. We are computing the check to be sent to verify that actual candidate pair. > > the list. This is done by removing a pair if its local and remote > candidates are identical to the local and remote candidates of a pair > higher up on the priority list. The result is a sequence of ordered > candidate pairs, called the check list for that media stream. > PM: Do we need to talk about what happens when the default candidate pair > gets pruned? No, its fine. These are check lists, not signaled in the SDP. > > In addition, in order to limit the attacks described in > Section 17.4.2, an agent SHOULD limit the total number of > connectivity checks they perform across all check lists to 100, by > discarding the lower priority candidate pairs until there are less > than 100. > > ---- > > The initial states for each pair in the check list are computed by > PM: s/the check list/a check list/ > performing the following sequence of steps: > fixed > ---- > > One of the check lists will have some number of pairs in the Waiting > state, and the other check lists will have all of their pairs in the > Frozen state. A check list with at least one pair that is Waiting is > called an active check list, and a check list with all pairs frozen > is called a frozen check list. > PM: "active" and "frozen" look like check list states to me. Could we > make them explicit states? They are orthogonal to the actual states; these are more like properties. > > The check list itself is associated with a state, which captures the > state of ICE checks for that media stream. There are two states: > PM: s/two states/three states/ > > Running: In this state, ICE checks are still in progress for this > media stream. > > Completed: In this state, ICE checks have completed successfully for > this media stream. > > Failed: In this state, the ICE checks have not completed > successfully for this media stream. fixed > > ---- > > Once the agent has computed the check lists as described in > Section 5.7, it sets a timer for each active check list. The timer > fires every Ta*N seconds, where N is the number of active check lists > (initially, there is only one active check list). Implementations > MAY set the timer to fire less frequently than this. Ta is the same > value used to pace the gathering of candidates, as described in > Section 4.1.1. Multiplying by N allows this aggregate check > throughput to be split between all active check lists. The first > timer for each active check list fires immediately, so that the agent > performs a connectivity check the moment the offer/answer exchange > has been done, followed by the next periodic check Ta seconds later. > PM: There is nothing here that requires all these timers to be spaced out. > As it stands, once every Ta*N seconds, all the timers could fire at once. > I am wondering if it is better to have just one timer and round-robin > between > the check lists? THe text now recommends spreading them out > > When the timer fires, the agent MUST: > > o Find the highest priority pair in that check list that is in the > Waiting state. > > o If there is such a pair: > > * Send a STUN check from the local candidate of that pair to the > remote candidate of that pair. The procedures for forming the > STUN request for this purpose are described in Section 7.1.1. > PM: Move state of pair to "In-Progress"? > wow, good catch. fixed. > ---- > > 2. If there is a pair in the valid list for every component of this > media stream (where this is the actual number of components being > used, in cases where the number of components signaled in the SDP > differs from offerer to answerer), the success of this check may > unfreeze checks for other media streams. Note that this step is > PM: Following the procedures as laid out here, the pair which has just > transitioned to Succeeded is NOT YET on the valid list, because that step > doesn't happen until the next section. good catch. I swapped the order of these sections. > followed not just the first time the valid list under > consideration has a pair for every component, but every > subsequent time a check succeeds and adds yet another pair to > that valid list. The agent examines the check list for each > other media stream in turn: > > ---- > > If the agent is the controlled agent, the response may result in the > valid pair having its nominated flag set. See Section 7.2.1.5 for > the procedure. > PM: I don't see how this could be the case, since this is a binding > response. THis part is complicated. For the controlled agent, when it receives a binding request with the USE-CANDIDATE flag, the nominated flag for the pair learned from the triggered check is set to true. So this section here is dealing with the case when that triggered check generates a success response. > > ---- > > Section 7.2.1.4, and Section 7.2.1.5 for full implementations. In > cases where multiple STUN requests are received before the answer, > this may cause several triggered notifications to all be sent at the > same time, > PM: s/,/./ ? > PM: Can the response include a NONCE, as the STUN spec says it can? Good question. I think its very counter-productive here. I'll indicate that. > > ---- > > 7.2.1.1. Detecting and Repairing Role Conflicts > > Normally, the rules for selection of a role in Section 5.2 will > result in each agent selecting a different role - one controlling, > and one controlled. However, in unusual call flows, typically > utilizing third party call control, it is possible for both agents to > select the same role. This section describes procedures for checking > for this case and repairing it. > PM: Can we see examples of 3PCC cases where this problem comes up? > I am worried that no one but Jonathan understands these cases. I added an informational appendix on it. > > An agent MUST examine the Binding Request for either the ICE- > CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these > procedures: > > o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the > request, there is no conflict. > > PM: Isn't this a malformed binding request, since 7.1.1.2. requires > one of these to be included? Yes - this is to deal with previous versions of the draft which didn't use it. > > ---- > > 7.2.1.4. Triggered Checks > > Next, the agent constructs a pair whose local candidate is equal to > > PM: This is a transport address pair, not a candidate pair. Then we are > trying to match this transport address pair to a candidate pair on a > check list. We use the local and remote UFRAGs to do this. In fact, I > claim all this processing happens just before section 7.2.1.3. THe term transport address pair is not used anymore; this is a candidate pair. > > ---- > > If a triggered check is to be generated, it is constructed and > processed as described in Section 7.1.1. These procedures require > the agent to know the transport address, username fragment and > password for the peer. The username fragment for the remote > candidate is equal to the part after the colon of the USERNAME in the > Binding Request that was just received. Using that username > PM: Why do I have to extract the username fragment in this manner? > I know the local and remote candidate pair -- why can't I just used the > username fragment and password associated with it? You don't know the remote candidate from the SDP at this point; you are trying to determine it based on the received triggered check. You can't look at source IP/port alone and match to SDP, due to peer reflexive candidates and forking. > fragment, the agent can check the SDP messages received from its peer > > > > Rosenberg Expires September 27, 2007 [Page 46] > Internet-Draft ICE March 2007 > > > (there may be more than one in cases of forking), and find this > username fragment. The corresponding password is then selected. If > agent has not yet received the username in an SDP (a likely case for > the offerer in the initial offer/answer exchange), it MUST wait for > the SDP to be received (since it won't have its peer's ICE password > without it), and then proceed with the triggered check. > PM: You already said this above. RIght - deleted here. > > ---- > o If there is at least one nominated pair in the valid list for a > media stream and the state of the check list is Running: > > * The agent MUST remove all Waiting and Frozen pairs in the check > list for the same component as the nominated pairs for that > media stream > PM: Do we remove ALL, or only those of lower priority? > > ---- > > o Once there is at least one nominated pair in the valid list for > every component of at least one media stream and the state of the > check list is Running: > > * The agent MUST change the state of processing for its check > list for that media stream to Completed. > > PM: What about checks that are "In-Progress"? Do these continue to run? > If they do, then the stuff below about changing the state of ICE > processing overall to Completed seems wrong. (Or is this why it is > possible in Aggressive Nomination, for the default candidate to change > multiple times?) exactly. > > * The agent MUST continue to respond to any checks it may still > receive for that media stream, and MUST perform triggered > checks if required by the processing of Section 7.2. > > ---- > > : is taken from RFC 4566 [10]. It is the IP > address of the candidate, allowing for IPv4 addresses, IPv6 > addresses and FQDNs. An IP address SHOULD be used, but an FQDN > MAY be used in place of an IP address. In that case, when > receiving an offer or answer containing an FQDN in an a=candidate > attribute, the FQDN is looked up in the DNS using an A or AAAA > record, and the resulting IP address is used for the remainder of > ICE processing. > PM: What is the motivation for allowing an FQDN in this position? I > think this just makes the implementation more complex, for no good reason. We discussed on the list; largely this is because SDP generally allows FQDN and I'm not changing that. > > ---- > > 15.5. "ice-options> Attribute > PM: s/>/"/ fixed > > ---- > > 17.5. Interactions with Application Layer Gateways and SIP > > Application Layer Gateways (ALGs) are functions present in a NAT > device which inspect the contents of packets and modify them, in > order to facilitate NAT traversal for application protocols. Session > Border Controllers (SBC) are close cousins of ALGs, but are less > transparent since they actually exist as application layer SIP > intermediaries. ICE has interactions with SBCs and ALGs. > > If an ALG is SIP aware but not ICE aware, ICE will work through it as > long as the ALG correctly modifies the SDP. In this case, correctly > means that the ALG does not modify the m and c lines or the rtcp > attribute if they contain external addresses. If they contain > internal addresses, the modification depends on the state of the ALG. > If the ALG already has a binding established that maps an external > port to an internal IP address and port in m and c lines or rtcp > attribute , the ALG uses that binding instead of creating a new one. > PM: I think these last two sentences are meant to be descriptions of > a correctly operating ALG, but this is not obvious from the wording. clarified. > > ---- > > B.1. Pacing of STUN Transactions > > STUN transactions used to gather candidates and to verify > connectivity are paced out at an approximate rate of one new > transaction every Ta milliseconds, where Ta has a default of 20ms. > Why are these transactions paced, and why was 20ms chosen as default? > PM: Below you describe why transactions are paced, but do not explain > why 20ms was chosen as the default. Perhaps add a sentence that says > that 20ms was chosen after an experiments with a number of NATs showed > that they could all handle 20ms but could not handle significantly > higher rates? done > > ---- > > B.2. Candidates with Multiple Bases > > Section 4.1.1 talks about merging together candidates that are > identical but have different bases. When can an agent have two > candidates that have the same IP address and port, but different > bases? Consider the topology of Figure 23: > > PM: There is no discussion in section 4.1.1 about "merging" candidates. > Are you referring here to section 4.1.1.3 on eliminating duplicate > candidates, and in particular to the last sentence? If so, perhaps > reword this as follows: > "Section 4.1.1.3 talks about eliminating duplicate candidates, and > states that a candidate can be eliminated only if there is another > candidate with the same transport address and base. This leads to the > question: How two candidates can have the same transport addresses, but > different bases? Consider the topology of Figure 23:". fixed > > PM: Also, I think it would be useful to add a paragraph motivating why > one wants to eliminate duplicate candidates. I suggest mentioning the > common case of obtaining a server reflexive candidate for a host > candidate, and discovering that the two candidates are the same. > Perhaps you can think of other common cases? Thats the main one. I mention it now in the section on eliminating redundant candidates. > > > --- > B.5. The Candidate Pair Sequence Number Formula > > The sequence number for a candidate pair has an odd form. It is: > > pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P? 1:0) > > Why is this? When the candidate pairs are sorted based on this > value, the resulting sorting has the MAX/MIN property. This means > that the pairs are first sorted based on decreasing value of the > maximum of the two sequence numbers. For pairs that have the same > value of the maximum sequence number, the minimum sequence number is > used to sort amongst them. If the max and the min sequence numbers > are the same, the offerers priority is used as the tie breaker in the > last part of the expression. The factor of 2*32 is used since the > priority of a single candidate is always less than 2*32, resulting in > the pair priority being a "concatenation" of the two component > priorities. This creates the desired sorting property. > > PM: Perhaps add a paragraph on why this particular sorting algorithm > was chosen? > Added a sentence. Thanks, 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 From mmusic-bounces@ietf.org Tue Jun 12 14:23:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyB1J-0000Bt-3R; Tue, 12 Jun 2007 14:23:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyB1H-0000Bo-Lj for mmusic@ietf.org; Tue, 12 Jun 2007 14:23:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyB1F-0002TC-2m for mmusic@ietf.org; Tue, 12 Jun 2007 14:23:07 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2007 11:23:04 -0700 X-IronPort-AV: i="4.16,412,1175497200"; d="scan'208"; a="163348438:sNHT47653128" 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 l5CIN4ah006715; Tue, 12 Jun 2007 11:23:04 -0700 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 l5CIN4tX026334; Tue, 12 Jun 2007 18:23:04 GMT 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); Tue, 12 Jun 2007 11:23:04 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:23:03 -0700 Message-ID: <466EE486.8040403@cisco.com> Date: Tue, 12 Jun 2007 14:23:02 -0400 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: Rafael Kiel References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Jun 2007 18:23:03.0524 (UTC) FILETIME=[B70FD240:01C7AD1E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2423; t=1181672584; x=1182536584; c=relaxed/simple; s=sjdkim1004; 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=20questions=20odraft-ietf-mmusic-ice-15.txt |Sender:=20; bh=RaqpmA0aX0xupQyDDI1YA93vukPWKYjbS8YK8q6ZgtI=; b=h4nXu0qh9tVO3lydzUKYsaSzvnH0AKdh99VSC6JIUEAUjz+j8e4uFUIggTR/BD4RioWw3jCN AJomg+1G8K6WIGNIGSnKH4VfJmDzZShk+pT29vPJY3vjUrtBvQmEOSvEHNy0zBfN8PjCfT2PvF pGupvku0voJPHJ8uB2EgwoZ1c=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org Subject: [MMUSIC] Re: questions odraft-ietf-mmusic-ice-15.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 responses inline. Rafael Kiel wrote: > Hi > > I have two question regarding draft-ietf-mmusic-ice-15.txt > > > > 1. Chapter 15.1. ( "candidate" Attribute) says the following: > > /… //In that case, when receiving an offer or answer containing an FQDN > in an a=candidate attribute, the FQDN is looked up in the DNS using an A > or AAAA record, and the resulting IP address is used for the remainder > of ICE processing …/ > > > > What should be done if the DNS look up results in more than address? Pick one. > Does agent has to perform AAAA DNS request if the A request succeeds? No. > > The implementation could create the remote candidate for each IPv4 and > IPv6 address learned as the result of DNS lookup or it can take one > arbitrary address. I believe it needs to be clarified. No. It should pick one arbitrarily. Normally there would be only one anyway. > > > > 2. Chapter 8.2. (Updating States) says: > > > > If an In-Progress pair in the check list is for the same > > > > /o If there is at least one nominated pair in the valid list for a/ > > / media stream and the state of the check list is Running:/ > > / / > > / …/ > > / / > > / * If an In-Progress pair in the check list is for the same/ > > / component as a nominated pair, the agent SHOULD cease/ > > / retransmissions for its check if its pair priority is lower/ > > / than the lowest priority nominated pair for that component/ > > / / > > / …/ > > / / > > Why an agent does not discard this check completely? If it succeeds the > pair will not be used since there exists another pair with higher > priority but letting this check to complete will require some > (superfluous) work to be done. Well, there is no CANCEL method, so the best the agent can do is to cease retransmitting. If it gets a response, its probably easier to just process it than it is to define special case handling to discard it. Thanks, 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 From mmusic-bounces@ietf.org Tue Jun 12 15:36:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCAd-0007pD-B7; Tue, 12 Jun 2007 15:36:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCAc-0007p7-Ev for mmusic@ietf.org; Tue, 12 Jun 2007 15:36:50 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCAZ-0002nL-Df for mmusic@ietf.org; Tue, 12 Jun 2007 15:36:50 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 12 Jun 2007 12:36:46 -0700 X-IronPort-AV: i="4.16,412,1175497200"; d="scan'208"; a="162262416:sNHT54926019" 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 l5CJakbu023103; Tue, 12 Jun 2007 12:36:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5CJaktV009094; Tue, 12 Jun 2007 19:36:46 GMT 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, 12 Jun 2007 12:36:46 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 12:36:45 -0700 Message-ID: <466EF5CD.80104@cisco.com> Date: Tue, 12 Jun 2007 15:36:45 -0400 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: Kevin Johns Subject: Re: [MMUSIC] ICE-15 WGLC Comments References: <9AAEDF491EF7CA48AB587781B8F5D7C6045F90@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6045F90@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Jun 2007 19:36:45.0991 (UTC) FILETIME=[030EBB70:01C7AD29] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5791; t=1181677006; x=1182541006; c=relaxed/simple; s=sjdkim1004; 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=20[MMUSIC]=20ICE-15=20WGLC=20Comments |Sender:=20; bh=0nC+97dVTlPaKaEvByWVNKOpdgNY/0qBGEOY1/f4uWo=; b=HH4sqVvqc5jqbFAMoKbw0L3kFB+j3ZYXcBoEeBVKVItf0MuRuyZij1quFHULlTBcPX5SGQjV bjzhc1ef8fEHJAvRc6dvOXx4hraqKQQR1Dfwplxi8iMjIt6CEOoVHjrPe8N4UVGjA3RfZW4CDs BZowpKsTa8Jh6qsQomt06JY74=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 3.2 (+++) 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 Thanks for the comments. Responses inline. Kevin Johns wrote: > Jonathan, > > Please find my comments on ICE-15 below for your consideration. I tried > to avoid nit picking, hopefully I was successful. I did not include any > editorial issues I found (spaces in the middle of words, missing closing > parenthesis, etc.) as I figure those will be caught by the editor before > publication. If you want them I will gladly forward. > > Let me know if you have any questions. > > Kevin > > > > Section 2.4 (Frozen Candidate) > > 1^st paragraph, 1^st sentence at the end of the parenthetical statement > – 'each of which has to work for the media stream as a whole to be work' > I think 'be' should be deleted fixed > > > > Section 4.2 (Lite Implementation) > > Per my previous email this section is unclear as to whether a lite > implementation can include multiple candidates. Given my understanding > that it cannot, I think removing the first sentence of the last > paragraph would help clarify the section. This is now allowed per list discussion. > > > > Section 5.7.2 Computing Pair Priority and Ordering Pairs > > The formula ends with (O>A?1:0) but the text after the formula defines > it as (O-P>A-P?1:0). The formula should probably be updated to align > with the textual description. Bug, fixed. > > > > Also, given the procedures in section 5.8 (performing periodic checks) > rely on the pair priority to determine the next pair to unfreeze are we > sure that the pair priority will results in pairs with the lower > component ID being checked first? Meaning if we have two component IDs > we want to check all the pairs for component ID 1 first before starting > any checks for component ID 2 pairs in order to get the optimizations > ICE provides by using the info learned from component ID 1 to quickly > find the best valid pair for component ID 2. If you follow this formula: priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID) then definitely yes. The frozen algorithm also has a 'fallback' in cases where somehow we didn't unfreeze something. If there are pairs in the check list that are Frozen but none are Waiting, we take the highest priority Frozen candidate and use it. > > > > Section 5.7.4 (computing states) > > 2^nd paragraph after step 2 indicates there are two states but three are > actually defined (running, completed, and failed). fixed > > > > Sections 7.1.1.1 (PRIORITY and USE-CANDIDATE) and 7.1.1.2 > (ICE-CONTROLLED AND ICE-CONTROLLING) > > Both sections discuss the ICE defined STUN attributes. It would be > helpful to provide a reference back to their respective sections where > they are defined (18.5) done > > > > Section 8.1.1 (Regular Nomination) > > The 2^nd paragraph discusses repeating the check with the USE-CANDIDATE > flag set. There is no discussion as to how the agent behaves if this > check is lost for some reason. While unlikely, it is possible that this > check could be lost in the network and would need to be retransmitted. > It might be worth while to provide some guidance on this scenario. I think this can be left to implementation approach. If this happens something bad has happened that is uncrecoverable. > > > > I read section 9.2.1.1 (detecting ICE restarts) and 9.2.2 (procedures > for full implementations) to be contradictory. 9.2.1.1 states that if > ICE is restarting for a media stream the agent MUST change the > a=ice-ufrag and a=ice-pwd attributes in the answer. However, 9.2.2 > states the username fragments, password, and implementation level MUST > remain the same as previously. If an agent needs to change one of these > it MUST restart ICE for that media stream by generating an offer; ICE > cannot be restarted in an answer. I am I miss-reading these two > sub-sections? Good catch. 9.2.2 is meaning to say that unless there is an ICE restart, you need to keep these the same. In other words, you can't cause a restart in an answer. > > > > Section 12.1.1 (offer in INVITE) > > The 2^nd paragraph discusses a mechanism for ensuring reliable delivery > of a response. However, if the target of the response is an ICE-lite > implementation it will never send a stun request and the agent is forced > to keep retransmitting its response needlessly. Would it make sense to > call this out, or let it be as it will resolve once the agent sends the > 200 OK? Actually this is a really good point. I spent a lot of time thinking about this. There are a few alternatives here: 1. let the retransmissions happen, possibly adjusting the retransmit count down in this case 2. allow ICE to proceed without actually even sending an answer in a 1xx - it is actually possible and would sometimes work (see below) 3. require PRACK everywhere At first I was leaning towards #2. But there is another related issue which is that there are going to be middleboxes and firewalls that are expecting to see a 18x with SDP in order to open pinholes and even let the ICE checks complete themselves. We really want the 18x for their benefit. SO I think the answer is #1, but adjusting the retransmit count down (to say, 4). Thanks, 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 From mmusic-bounces@ietf.org Tue Jun 12 16:28:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCya-0005g8-EV; Tue, 12 Jun 2007 16:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCyX-0005VL-Nf for mmusic@ietf.org; Tue, 12 Jun 2007 16:28:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCyW-0006kh-0S for mmusic@ietf.org; Tue, 12 Jun 2007 16:28:25 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2007 13:28:23 -0700 X-IronPort-AV: i="4.16,413,1175497200"; d="scan'208"; a="163425664:sNHT138505536" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5CKSNCp005744; Tue, 12 Jun 2007 13:28:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5CKSM26016456; Tue, 12 Jun 2007 20:28:23 GMT 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); Tue, 12 Jun 2007 13:28:19 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 13:28:18 -0700 Message-ID: <466F01E1.9090209@cisco.com> Date: Tue, 12 Jun 2007 16:28:17 -0400 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: "Elwell, John" References: <50B1CBA96870A34799A506B2313F26670B86257D@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B86257D@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2007 20:28:18.0914 (UTC) FILETIME=[36955420:01C7AD30] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8730; t=1181680103; x=1182544103; c=relaxed/simple; s=sjdkim3002; 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=20Further=20comments=20on=20ICE-15 |Sender:=20; bh=uWZUAfMaT0Eb2GDvScl931r0bvU8n3w8oKqPnMj3KRA=; b=V5APaTPegIgPFK4p00ou22IoIoeVtaBsNg9KBJSQveknLwmx4kt53x232XpzU0GGOqW2t7OG STzr5R3cGq1RHsjRg9g0N0pcagkLSwMEYwPLT+E3rLtnqKPgT4B8MEQF; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Further comments on ICE-15 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 Elwell, John wrote: > Jonathan, > > Yet more comments from myself and a colleague. Apologies if any have already > been discussed. > > > "Candidate: A transport address that is to be tested by ICE > procedures in order to determine its suitability for usage for > receipt of media." > > A candidate will not necessarily be tested, because it may not be compatible > (e.g., an IPv6 candidate will not be acceptable to an IPv4-only endpoint) or > because aggressive mode has already found a suitable candidate-pair. Perhaps > it should say "A transport address that requires testing by ICE > procedures in order...." good point. changed to: A transport address that is a potential point of contact for receipt of media. Candidates also have properties - their type (server reflexive, relayed or host), priority, foundation, and base. > > "The process for selecting default candidates at the answerer is > identical to the process followed by the offerer, as described in > Section 4.1.3 for full implementations and Section 4.2 for lite > implementations." > I would suggest that each default candidate of the answerer MUST be > compatible with the corresponding default candidate of the offerer. > Otherwise it may happen, that the default candidates of the offerer are v4 > addresses and the default candidates of the answerer v6 ones. That makes > little sense. > It works fine though; they'll be a re-invite to fix-up once a pair is selected. Its really no different than one agent including a net10 default and the other a public default. There won't be connectivity. I don't want to add normative requirements if it doesn't actually make a difference in behavior of the protocol (and it doesnt) > "If this happens, the number of > components for that media stream is effectively reduced, and > considered to be equal to the minimum across both agents of the > maximum component ID provided by each agent across all components for > the media stream." > Maybe this works for RTP/RTCP, but is it sufficiently general? What if for > some reason in future there are 3 components for a media stream and that R > has included candidates for all components (1,2,3) but L includes candidates > only for 1 and 3? That wouldn't work as defined. The mechanism was designed for RTP/RTCP and also looking out for things like layered codecs where you can use a subset. It works there too. If in the future it doesn't work for some new thing, we'll extend as needed. > > "The check list itself is associated with a state, which captures the > state of ICE checks for that media stream. There are two states:" > In fact three states are listed. yeah, many folks pointed this one out. fixed. > > "This state is equal to Running while checks are in > progress. The state is Completed when all checks have been > completed." > There should be a corresponding statement for Failed. ok. though this state is not really needed per se, I added. > > "Once the agent has computed the check lists as described in > Section 5.7, it sets a timer for each active check list." > In fact, there will only be one active check list at this stage. > > "The first > timer for each active check list fires immediately" > There will only be one active check list initially. fixed > > "5.8. Performing Periodic Checks" > Should it be mentioned somewhere in this section when a frozen check list > should become active? this is covered elsewhere in the spec > > "(as defined in [12]," > Closing bracket missing. fixed > > "If the check list is frozen, and there is at least one pair in > the check list whose foundation matches a pair in the valid > list under consideration, the state of all pairs in the check > list whose foundation matches a pair in the valid list under > consideration are set to Waiting." > Do we need to say anything about starting the timer for periodic checks? added asentence and a reference to the section on periodic checks > > "This flag > indicates that this valid pair should be used for media if it is the > highest priority one amongst those whose nominated flag is set." > Since the formula for computing priorities produces unique priorities only > "in most cases", we should have some statement here about how to deal with > equal priorities. actually I was able to mathematically prove that if each side provided candidates with unique priority (which is a MUST) and one side is controller and the other controlled (true with extremely high priority due to conflict resolution procedures), the pair priority is always unique. So I removed the 'in most cases'. > > "In > cases where multiple STUN requests are received before the answer, > this may cause several triggered notifications to all be sent at the > same time," > Incomplete sentence. Or maybe the comma should be a period. period. > > "In unusual cases it is possible for both agents to mistakenly believe > they are controlled or controlling. To deal with such cases, at the > time an agent determines its role, it MUST select a random number, > called the tie-breaker, uniformly distributed between 0 and (2**64) - > 1 (that is, a 64 bit positive integer)." > Notwithstanding the comment I made in a separate email about the need for a > tie-breaker, if we really do need a tie-breaker why can't the ice-pwd be > used instead, because that has a similar amount of randomness? I suppose. You need the stun check in either case. With this at least your random number is already an integer. If I use ice-pwd we'd have to specify how to convert to an integer. > > "9.1.1.1. ICE Restarts" > If an endpoint receives a SIP re-INVITE without an SDP offer, and as a > result has to send an SDP offer in a SIP 2xx response, should this be > treated as an ICE restart or a new session. It could be as a result of a > 3PCC transfer, so effectively it would need to be a new session, but the > endpoint has no way of knowing that. So it would have to treat it as a new > session to be safe. This then means that existing media cannot continue to > flow, which would be a disadvantage if it isn't really a new session. We > should make some statement about this situation. Furthermore, if the peer > rejects the offer, what should happen? The offerer is supposed to do a restart. This is described in Section 12.5. WIth restarts media continues to flow. > > "The only > difference between an ICE restart and a brand new media session is > that, during the restart, media can continue to be sent to the > previously validated pair." > Presumably with a restart, if the offer gets rejected, existing media will > still continue. Furthermore existing period connectivity checking will > continue using the old password. Should clarify. Thats really true in general for O/A, and applies to everything in the spec. For example if I send an offer to add a candidate, and the offer is rejected, we continue with what we had before. I added a sentencve to clarify. > > "In that case, when > receiving an offer or answer containing an FQDN in an a=candidate > attribute, the FQDN is looked up in the DNS using an A or AAAA > record, and the resulting IP address is used for the remainder of > ICE processing." > What if the DNS look-up yields both an IPv4 and an IPv6 address? This is now clarified. > > "Consequently, ICE serves to repair the brittleness introduced in > other UNSAF mechanisms, and does not introduce any additional > brittleness into the system." > Probably true, but isn't it worth mentioning the performance impact, i.e., > potentially longer call set-up time? Wow! SOmeone is reading the IAB considerations section. Amazing. I'll mention. > > "A full implementation will reduce call setup times." > Why would a full implementation reduce call set up times compared to lite? > Some explanation would be appropriate. The only reason I can think of is the > fact that lite prevents use of aggressive mode. Exactly. I mentioned. Thanks, 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 From mmusic-bounces@ietf.org Tue Jun 12 17:16:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDj5-0005vX-B3; Tue, 12 Jun 2007 17:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDj4-0005vS-G1 for mmusic@ietf.org; Tue, 12 Jun 2007 17:16:30 -0400 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 1HyDj1-0008PW-KA for mmusic@ietf.org; Tue, 12 Jun 2007 17:16:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2007 14:16:26 -0700 X-IronPort-AV: i="4.16,413,1175497200"; d="scan'208"; a="378806031:sNHT55859482" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5CLGPLc026588; Tue, 12 Jun 2007 14:16:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5CLGEtp007371; Tue, 12 Jun 2007 21:16:27 GMT 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); Tue, 12 Jun 2007 14:16:19 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:16:19 -0700 Message-ID: <466F0D22.9030808@cisco.com> Date: Tue, 12 Jun 2007 17:16:18 -0400 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: "Elwell, John" References: <50B1CBA96870A34799A506B2313F26670B6C564A@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B6C564A@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2007 21:16:19.0170 (UTC) FILETIME=[EB598420:01C7AD36] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1802; t=1181682985; x=1182546985; c=relaxed/simple; s=sjdkim2002; 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=20ICE-15=20comments |Sender:=20; bh=i0dwtzaM+z0Ia0qo1jubWJLeaHoKvPi87BrGBUMRi2k=; b=Rlinh53jJqEfCNcGwFFX7rSdC7mX3fEyPihr012pktr+FGtqcTia3lJarK0RVHSVa8AVkm2f TIlL0Bm0gnDV2Hjzr6jKFX9wP0B6VS9TzqBJaud6+oBVfs2WqAYYeX6h; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: ICE-15 comments 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 Elwell, John wrote: > Section "Introduction" > Because this obsoletes RFC 4091, there really should be some mention of this > in the introduction - otherwise the reader might not see the connection. > Perhaps add to the end of the last paragraph something along the lines of: > "Additional IP addresses and ports can be gathered by IPv4/IPv6 dual stack > endpoints to allow the selection of a suitable IP version for media." added > > "they tend to carry the IP of media sources" > Change to > "they tend to carry the IP addresses and ports of media sources" > fixed > > "but only the > outermost server reflexive candidate will be discovered by the agent" > To make it clearer, change to > "but only the > outermost server reflexive candidate (nearest the STUN server) will be > discovered by the agent" fixed > > In section 4.2 "Lite implementation" it states: > "If an agent has included two candidates for a component, the v4 > candidate SHOULD be selected as the default." According to other > statements, a lite implementation is not allowed to include two candidates. > Now there might be benefit in doing this in certain circumstances, but I > will think about it further and possibly send a separate message. However, > if that sentence does not apply to lite implementations it should not appear > in 4.2 or at least should avoid normative language. THis is fixed per our discussions. -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 From mmusic-bounces@ietf.org Tue Jun 12 22:26:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyIZG-0000gO-9G; Tue, 12 Jun 2007 22:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyIZE-0000ZY-LP for mmusic@ietf.org; Tue, 12 Jun 2007 22:26:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyIZC-0002yj-Bo for mmusic@ietf.org; Tue, 12 Jun 2007 22:26:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2007 19:26:34 -0700 X-IronPort-AV: i="4.16,413,1175497200"; d="scan'208"; a="163598117:sNHT56041182" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5D2QXir002815 for ; Tue, 12 Jun 2007 19:26:33 -0700 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 l5D2QXtV024710 for ; Wed, 13 Jun 2007 02:26:33 GMT 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); Tue, 12 Jun 2007 19:26:33 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 19:26:33 -0700 Message-ID: <466F55D8.9090504@cisco.com> Date: Tue, 12 Jun 2007 22:26:32 -0400 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: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2007 02:26:33.0555 (UTC) FILETIME=[42634230:01C7AD62] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4039; t=1181701593; x=1182565593; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE-16=20now=20posted |Sender:=20; bh=vBr3A+8o2no9ZkeZPESnxnWK5RRCxGirziX7GAKk0fc=; b=KffQtKA/UyC3EHw38sx2cO0uk/934HRbPlbxS/UeF9kvsL1uNXmMAxnS1LfpgQqgNFFU4hv6 D3Y5gQZApuMmMQuCOyPo1OxaQ7rAVfi055gTn1a82cHDnLI10zMctlxI; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [MMUSIC] ICE-16 now posted 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 ICE-16 is now available: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt This revision incorporates comments received during WGLC. Besides many editorial changes, here are the substantive ones: * changed pair priority formula to be based on controlling/controlled roles rather than offerer/answerer. This allows pair prioritization to get fixed when there is a role conflict * clarified that a 300 error response is not permitted for connectivity checks * added upper bounds to the number of characters in the foundation, component-ID, priority, password and ufrag components of the grammar. * spreading out of the start timers for check lists is RECOMMENDED, to avoid synchronized checks across streams * previously, if there was at least one candidate matching a default in an offer, we'd proceed with ICE. Now, there must be a candidate for all defaults. * aligned rules for verifying ICE support between offerer and answerer * added section on when you can free candidates after ICE has concluded. It is done immediately for lite implementations, and three seconds after ICE has concluded for full. Interactions with forking are mentioned. * Major change: ICE lite now allows for multiple v6 candidates and a single v4 candidate for each component. This came at the cost of some increase in complexity of the spec and procedures for lite implementations. In particular, ICE now proceeds when both agents are lite. Lite implementations now need to perform role selection, and when controlling, send an updated offer. They need to maintain a basic state for each media stream (RUnning or Completed). Role reversal is described based on usage of SIP signaling to resolve the conflicts. Lite implementations must send and process the remote-candidates attribute, though this processing is much simpler than the full case (where its a big pain in fact) and only needed for dual-stack (v4 only can ignore). Guidance added in the appendix that says you SHOULD still do a full implementation even if all you care about is ANAT replacement. * Major change: congestion control mechanism added. THis is done by adjusting Ta and RTO based on a formula that takes into account the media bandwidth. Also, triggered checks are now scheduled rather than being sent immediately; basically there is a priority queue where every Ta you send a triggered check fi there is one, else an 'ordinary' check. Ordinary check is the new name for periodic check since these are not so periodic anymore. * If a transaction is in progress when a triggered check is to be sent, it is cancelled and a new transaction is scheduled (previously, there was an adjustment to the retransmits for the existing transction). Cancellation implies retransmissions cease and the tranasction doesn't fail on timeout, but you still wait for a response if there is one * clarified that NONCE is not used with ICE * added an informational appendix on when the conflict resolution procedures are needed and why * clarified that when a FQDN is used in the candidate attribute, you look up AAAA first then A, and pick a single IP * for 'poor mans RFC3262', if the offerer is lite, you won't get a STUN Binding request to terminate 18x retransmits. For this case, the spec now mandates no more than four retransmits of the 18x. Another reason to implement full. * inclusion of FINGERPRINT is MUST: motivation for this captured in rfc3489bis * ICMP support is a MAY I believe this is now ready for another WGLC. -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 From mmusic-bounces@ietf.org Wed Jun 13 11:27:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUkr-00037I-CS; Wed, 13 Jun 2007 11:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRbx-0006xE-AZ; Wed, 13 Jun 2007 08:06:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyRbu-00075t-Hy; Wed, 13 Jun 2007 08:06:05 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EEFF521046; Wed, 13 Jun 2007 14:06:01 +0200 (CEST) X-AuditID: c1b4fb3e-afe77bb0000007e1-6e-466fdda9870b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CC433200C9; Wed, 13 Jun 2007 14:06:01 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:06:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Jun 2007 14:05:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEGACO] New draft: multiple [packet] times problem description: draft-garcia-mmusic-multiple-ptimes-problem-00.txt Thread-Index: AcetsyUJMnDEuQCNQSi0gBUIKWpe2w== From: "Stephen Mell (CV/ETL)" To: X-OriginalArrivalTime: 13 Jun 2007 12:06:01.0384 (UTC) FILETIME=[35A0F280:01C7ADB3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Wed, 13 Jun 2007 11:27:27 -0400 Cc: mmusic@ietf.org Subject: [MMUSIC] [MEGACO] New draft: multiple [packet] times problem description: draft-garcia-mmusic-multiple-ptimes-problem-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: , Content-Type: multipart/mixed; boundary="===============0844864787==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0844864787== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ADB3.35A3F4D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADB3.35A3F4D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Megaco List, I'd like to draw peoples attention to this posting on MMUSIC mailing list: http://www1.ietf.org/mail-archive/web/mmusic/current/msg05776.html It concerns the specification of packetization times in SDP on a per media type basis. The draft mentioned is now on the ietf site and can be accessed at: http://tools.ietf.org/id/draft-garcia-mmusic-multiple-ptimes-problem-00. txt The correct place to contribute views is the MMUSIC mailing list. At the minute I think that Miguel is establishing if there is consensus that a problem exists that cannot be adequately addressed by the any of the standards currently in place. Regards, Steve=20 ------_=_NextPart_001_01C7ADB3.35A3F4D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [MEGACO] New draft: multiple [packet] times problem description: = draft-garcia-mmusic-multiple-ptimes-problem-00.txt

Hello Megaco List,

I'd like to draw peoples attention to = this posting on MMUSIC mailing list:

http://www1.ietf.org/mail-archive/web/mmusic/current/msg05= 776.html

It concerns the specification of = packetization times in SDP on a per media type basis.

The draft mentioned is now on the ietf = site and can be accessed at:

http://tools.ietf.org/id/draft-garcia-mmusic-multiple-ptim= es-problem-00.txt

The correct place to contribute views = is the MMUSIC mailing list. At the minute I think that Miguel is = establishing if there is consensus that a problem exists that cannot be = adequately addressed by the any of the standards currently in = place.


Regards,

Steve


------_=_NextPart_001_01C7ADB3.35A3F4D0-- --===============0844864787== 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 --===============0844864787==-- From mmusic-bounces@ietf.org Wed Jun 13 11:57:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVDV-00089x-7O; Wed, 13 Jun 2007 11:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVDT-00088q-MW for mmusic@ietf.org; Wed, 13 Jun 2007 11:57:03 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyVCN-0001FH-Pn for mmusic@ietf.org; Wed, 13 Jun 2007 11:55:56 -0400 Received: by an-out-0708.google.com with SMTP id c17so54912anc for ; Wed, 13 Jun 2007 08:55:55 -0700 (PDT) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=cOnFZUS0IcvmvvQsBK468L35Kw5RxvDm9gu2yv9DHnXCTGqmM/hL4KJC2Ydq8M4eysaBVc21kbLXQKIdE3zIAqPQLNKvNuev4gKCmbZgUOIeDSOf+2qJVfwF4B0ydz3rxfaJNSPPyaa9jdKkrRNNYy9yhvwiOP3EKs6nZ+GJ1pE= 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=mQq6x/dJA6o8hWjiBeVtVE5toLdD2A/eiodTFsX58BCfHJL/5gPkpaNyv+X/DDpk1xieN9pwGsFQacEpZKn3hCmh2y+GzwuErTlpOr1GZH8FEPEL7TPzOSYNKTQatO0DEhuj1rWZKnuhEPr3yaR0V3dd5O0ZFhe0zrJ4q7KfefU= Received: by 10.100.121.12 with SMTP id t12mr432134anc.1181750155479; Wed, 13 Jun 2007 08:55:55 -0700 (PDT) Received: by 10.100.190.17 with HTTP; Wed, 13 Jun 2007 08:55:55 -0700 (PDT) Message-ID: <458913680706130855s3c504aebm162940bdce748a6e@mail.gmail.com> Date: Wed, 13 Jun 2007 17:55:55 +0200 From: "Xavier Marjou" To: "Parameshwar Hegde" Subject: Re: [MMUSIC] Status of draft-whitehead-mmusic-sip-for-streaming-media-02 In-Reply-To: <8F798BFDA851B943B3A1B2510E92878504BE40D5@airmail.wirelessworld.airvananet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8F798BFDA851B943B3A1B2510E92878504BE40D5@airmail.wirelessworld.airvananet.com> X-Google-Sender-Auth: 16f963a721d0b0cd X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 The draft is currently on-hold: there are some important open-points when coming to protocol details. They need to be investigated, and the authors are still motivated to continue activities on this, but letting RTSPv2 finish comes first as it is a WG item. By the way, I have not seen recent news about the RTSPv2 review team. Could somebody also give some few details about this ongoing work? Xavier On 6/11/07, Parameshwar Hegde wrote: > > Hi, > > Could someone please let me know the status of following proposal/draft. It > expired in April 07. > > draft-whitehead-mmusic-sip-for-streaming-media-02 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 14 02:37:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyixM-00050A-NL; Thu, 14 Jun 2007 02:37:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyixL-0004zk-JT for mmusic@ietf.org; Thu, 14 Jun 2007 02:37:19 -0400 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 1HyixK-0001Ec-1w for mmusic@ietf.org; Thu, 14 Jun 2007 02:37:19 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJM007AD51TWK@siemenscomms.co.uk> for mmusic@ietf.org; Thu, 14 Jun 2007 07:37:05 +0100 (BST) Date: Thu, 14 Jun 2007 07:37:15 +0100 From: "Elwell, John" Subject: RE: [MMUSIC] ICE-16 now posted In-reply-to: <466F55D8.9090504@cisco.com> To: Jonathan Rosenberg , IETF MMUSIC WG Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E63F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [MMUSIC] ICE-16 now posted Thread-Index: AcetYlOUmd17YpNWRKy5hBNn1wOvOwA67yCA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <466F55D8.9090504@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 Jonathan, Is it correct that lite implementations are required to initiate keep-alives? This seems to be indicated by the statement in section 10 "All endpoints MUST send keepalives for each media session. These keepalives serve the purpose of keeping NAT bindings alive for the media session." However, it seems unnecessary. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 13 June 2007 03:27 > To: IETF MMUSIC WG > Subject: [MMUSIC] ICE-16 now posted > > ICE-16 is now available: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt > > This revision incorporates comments received during WGLC. > Besides many > editorial changes, here are the substantive ones: > > * changed pair priority formula to be based on controlling/controlled > roles rather than offerer/answerer. This allows pair prioritization > to get fixed when there is a role conflict > > * clarified that a 300 error response is not permitted for > connectivity checks > > * added upper bounds to the number of characters in the foundation, > component-ID, priority, password and ufrag components of the > grammar. > > * spreading out of the start timers for check lists is RECOMMENDED, to > avoid synchronized checks across streams > > * previously, if there was at least one candidate matching a default > in an offer, we'd proceed with ICE. Now, there must be a candidate > for all defaults. > > * aligned rules for verifying ICE support between offerer and answerer > > * added section on when you can free candidates after ICE has > concluded. It is done immediately for lite implementations, and > three seconds after ICE has concluded for full. Interactions with > forking are mentioned. > > * Major change: ICE lite now allows for multiple v6 candidates and a > single v4 candidate for each component. This came at the cost of > some increase in complexity of the spec and procedures for lite > implementations. In particular, ICE now proceeds when both agents > are lite. Lite implementations now need to perform role selection, > and when controlling, send an updated offer. They need to > maintain a > basic state for each media stream (RUnning or Completed). Role > reversal is described based on usage of SIP signaling to > resolve the > conflicts. Lite implementations must send and process the > remote-candidates attribute, though this processing is much simpler > than the full case (where its a big pain in fact) and only needed > for dual-stack (v4 only can ignore). Guidance added in > the appendix that says you SHOULD still do a full implementation > even if all you care about is ANAT replacement. > > * Major change: congestion control mechanism added. THis is done by > adjusting Ta and RTO based on a formula that takes into account the > media bandwidth. Also, triggered checks are now scheduled rather > than being sent immediately; basically there is a priority queue > where every Ta you send a triggered check fi there is one, else an > 'ordinary' check. Ordinary check is the new name for periodic check > since these are not so periodic anymore. > > * If a transaction is in progress when a triggered check is to be > sent, it is cancelled and a new transaction is scheduled > (previously, there was an adjustment to the retransmits for the > existing transction). Cancellation implies retransmissions > cease and > the tranasction doesn't fail on timeout, but you still wait for a > response if there is one > > * clarified that NONCE is not used with ICE > > * added an informational appendix on when the conflict resolution > procedures are needed and why > > * clarified that when a FQDN is used in the candidate attribute, you > look up AAAA first then A, and pick a single IP > > * for 'poor mans RFC3262', if the offerer is lite, you won't get a > STUN Binding request to terminate 18x retransmits. For this case, > the spec now mandates no more than four retransmits of the > 18x. Another reason to implement full. > > * inclusion of FINGERPRINT is MUST: motivation for this captured in > rfc3489bis > > * ICMP support is a MAY > > I believe this is now ready for another WGLC. > > -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 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 14 04:40:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hykse-00017V-Jv; Thu, 14 Jun 2007 04:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyksd-000113-Ew for mmusic@ietf.org; Thu, 14 Jun 2007 04:40:35 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyksb-0003Ye-Pk for mmusic@ietf.org; Thu, 14 Jun 2007 04:40:35 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2FD6F21307; Thu, 14 Jun 2007 10:40:33 +0200 (CEST) X-AuditID: c1b4fb3e-b167abb0000007e1-34-4670ff01784c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1D2C02136E; Thu, 14 Jun 2007 10:40:33 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 10:40:32 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 10:40:32 +0200 Message-ID: <4670FF00.6090004@ericsson.com> Date: Thu, 14 Jun 2007 10:40:32 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Xavier Marjou Subject: Re: [MMUSIC] Status of draft-whitehead-mmusic-sip-for-streaming-media-02 References: <8F798BFDA851B943B3A1B2510E92878504BE40D5@airmail.wirelessworld.airvananet.com> <458913680706130855s3c504aebm162940bdce748a6e@mail.gmail.com> In-Reply-To: <458913680706130855s3c504aebm162940bdce748a6e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2007 08:40:32.0412 (UTC) FILETIME=[AB66DDC0:01C7AE5F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Xavier Marjou skrev: > The draft is currently on-hold: there are some important open-points > when coming to protocol details. They need to be investigated, and the > authors are still motivated to continue activities on this, but > letting RTSPv2 finish comes first as it is a WG item. > > By the way, I have not seen recent news about the RTSPv2 review team. > Could somebody also give some few details about this ongoing work? > Martin Stimerling is currently working on converting the LaTeX source to XML2RFC so that we can produce the draft without all the issues it has been suffering from for a long time. It will also speed up the publication process the day it is approved. We will definitely get a new version out before the Chicago IETF deadline. The big question is how much of the open issues identified that we will be able to address. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 14 04:45:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hykxb-0004Am-R1; Thu, 14 Jun 2007 04:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hykxa-0004Ac-Lu for mmusic@ietf.org; Thu, 14 Jun 2007 04:45:42 -0400 Received: from mxs2.siemens.at ([194.138.12.133] helo=atvies1zrx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HykxU-0004dt-L0 for mmusic@ietf.org; Thu, 14 Jun 2007 04:45:42 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zrx.siemens.at with ESMTP id l5E8jYUb009496; Thu, 14 Jun 2007 10:45:34 +0200 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 l5E8j0K2018623; Thu, 14 Jun 2007 10:45:32 +0200 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 10:45:17 +0200 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, 14 Jun 2007 10:45:16 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-andreasen-mmusic-sdpcapneg-att-del-00.txt Thread-Index: AceqBsOHlMoiy8SDT46Cc8sN+3SDwgEUps/w References: From: "Stach, Thomas" To: "Flemming Andreasen" , X-OriginalArrivalTime: 14 Jun 2007 08:45:17.0487 (UTC) FILETIME=[5551DBF0:01C7AE60] 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::070614104534-0AAF9BB0-3521E75B/0-0/0-15 X-purgate-size: 3669/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Subject: [MMUSIC] RE: I-D ACTION:draft-andreasen-mmusic-sdpcapneg-att-del-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 Fleming, thanks for providing this collection of use case for the DELETE and REPLACE operators.=20 I think it clearly shows that at the DELETE operator provides an essential capability for the core capability negotiation mechanism.=20 I support your conclusion that the REPLACE operator is an optimization to the DELETE operator and that it shows most of its benefits with media capabilities.=20 Therefore removing the REPLACE operator from the core spec (and possibly moving it into the media capabilities extension) makes a lot of sense to me in simplifying the core spec. I hope that a draft-06 witout the REPLACE operator will be ready for last call. It is complete for the purpose of negotiation attribute capabilities and we should get it done now. Regards Thomas > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Friday, June 08, 2007 9:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-andreasen-mmusic-sdpcapneg-att-del-00.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : SDP Capability Negotiation: Deleting=20 > and Replacing Attributes=20 > Author(s) : F. Andreasen > Filename :=20 > draft-andreasen-mmusic-sdpcapneg-att-del-00.txt > Pages : 13 > Date : 2007-6-8 > =09 > The current SDP Capability Negotiation solution=20 > includes the ability=20 > for a potential configuration to delete and replace=20 > individual=20 > attributes from the actual configuration. This=20 > capability introduces=20 > some complexity into the SDP Capability Negotiation=20 > framework and=20 > this document examines the need for having this=20 > feature and proposes=20 > a way forward. =20 >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp > capneg-att-del-00.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-andreasen-mmusic-sdpcapneg-att-del-00.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-andreasen-mmusic-sdpcapneg-att-del-00.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 Thu Jun 14 10:28:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqJ2-00012H-Q9; Thu, 14 Jun 2007 10:28:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqJ1-0000xd-02 for mmusic@ietf.org; Thu, 14 Jun 2007 10:28:11 -0400 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 1HyqJ0-0003m4-C0 for mmusic@ietf.org; Thu, 14 Jun 2007 10:28:10 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2007 07:28:09 -0700 X-IronPort-AV: i="4.16,421,1175497200"; d="scan'208"; a="494128398:sNHT54274290" 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 l5EES9KM013047; Thu, 14 Jun 2007 07:28:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5EES920004969; Thu, 14 Jun 2007 14:28:09 GMT 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); Thu, 14 Jun 2007 07:28:09 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 07:28:09 -0700 Message-ID: <46715078.3040004@cisco.com> Date: Thu, 14 Jun 2007 10:28:08 -0400 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: "Elwell, John" Subject: Re: [MMUSIC] ICE-16 now posted References: <466F55D8.9090504@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D019E63F@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E63F@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2007 14:28:09.0361 (UTC) FILETIME=[3B1CB810:01C7AE90] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5480; t=1181831289; x=1182695289; c=relaxed/simple; s=sjdkim2002; 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=20[MMUSIC]=20ICE-16=20now=20posted |Sender:=20; bh=SFqEq2ns2qamKa1Qj30QmnqYUME0i16A3p9iqAA3ACA=; b=IqQcxApnuWDYSu+V7vYKoVlQcAxyHrhyeMbnPZ4yyHRn7L0gwSf3qo2YrZuPa43IY8l0UYlI FwiXSi8/9wVZKCuDZIrzJnJkXFA4InvdYvAiAW/ZIQtAXFqu1quMN4XE; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: IETF 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 I think its good practice regardless of NAT traversal. In this case the endpoint doesn't need to send STUN; it can use any of the mechanisms mentioned there. -Jonathan R. Elwell, John wrote: > Jonathan, > > Is it correct that lite implementations are required to initiate > keep-alives? This seems to be indicated by the statement in section 10 > "All endpoints MUST send keepalives for each media session. These > keepalives serve the purpose of keeping NAT bindings alive for the > media session." > However, it seems unnecessary. > > John > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: 13 June 2007 03:27 >>To: IETF MMUSIC WG >>Subject: [MMUSIC] ICE-16 now posted >> >>ICE-16 is now available: >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt >> >>This revision incorporates comments received during WGLC. >>Besides many >>editorial changes, here are the substantive ones: >> >>* changed pair priority formula to be based on controlling/controlled >> roles rather than offerer/answerer. This allows pair prioritization >> to get fixed when there is a role conflict >> >>* clarified that a 300 error response is not permitted for >> connectivity checks >> >>* added upper bounds to the number of characters in the foundation, >> component-ID, priority, password and ufrag components of the >> grammar. >> >>* spreading out of the start timers for check lists is RECOMMENDED, to >> avoid synchronized checks across streams >> >>* previously, if there was at least one candidate matching a default >> in an offer, we'd proceed with ICE. Now, there must be a candidate >> for all defaults. >> >>* aligned rules for verifying ICE support between offerer and answerer >> >>* added section on when you can free candidates after ICE has >> concluded. It is done immediately for lite implementations, and >> three seconds after ICE has concluded for full. Interactions with >> forking are mentioned. >> >>* Major change: ICE lite now allows for multiple v6 candidates and a >> single v4 candidate for each component. This came at the cost of >> some increase in complexity of the spec and procedures for lite >> implementations. In particular, ICE now proceeds when both agents >> are lite. Lite implementations now need to perform role selection, >> and when controlling, send an updated offer. They need to >>maintain a >> basic state for each media stream (RUnning or Completed). Role >> reversal is described based on usage of SIP signaling to >>resolve the >> conflicts. Lite implementations must send and process the >> remote-candidates attribute, though this processing is much simpler >> than the full case (where its a big pain in fact) and only needed >> for dual-stack (v4 only can ignore). Guidance added in >> the appendix that says you SHOULD still do a full implementation >> even if all you care about is ANAT replacement. >> >>* Major change: congestion control mechanism added. THis is done by >> adjusting Ta and RTO based on a formula that takes into account the >> media bandwidth. Also, triggered checks are now scheduled rather >> than being sent immediately; basically there is a priority queue >> where every Ta you send a triggered check fi there is one, else an >> 'ordinary' check. Ordinary check is the new name for periodic check >> since these are not so periodic anymore. >> >>* If a transaction is in progress when a triggered check is to be >> sent, it is cancelled and a new transaction is scheduled >> (previously, there was an adjustment to the retransmits for the >> existing transction). Cancellation implies retransmissions >>cease and >> the tranasction doesn't fail on timeout, but you still wait for a >> response if there is one >> >>* clarified that NONCE is not used with ICE >> >>* added an informational appendix on when the conflict resolution >> procedures are needed and why >> >>* clarified that when a FQDN is used in the candidate attribute, you >> look up AAAA first then A, and pick a single IP >> >>* for 'poor mans RFC3262', if the offerer is lite, you won't get a >> STUN Binding request to terminate 18x retransmits. For this case, >> the spec now mandates no more than four retransmits of the >> 18x. Another reason to implement full. >> >>* inclusion of FINGERPRINT is MUST: motivation for this captured in >> rfc3489bis >> >>* ICMP support is a MAY >> >>I believe this is now ready for another WGLC. >> >>-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 >> > > -- 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 From mmusic-bounces@ietf.org Thu Jun 14 12:47:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysUH-0002GU-RV; Thu, 14 Jun 2007 12:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysUH-0002GK-4p for mmusic@ietf.org; Thu, 14 Jun 2007 12:47:57 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HysUF-0004ak-Qe for mmusic@ietf.org; Thu, 14 Jun 2007 12:47:57 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out4.apple.com (Postfix) with ESMTP id 3705D904343 for ; Thu, 14 Jun 2007 09:47:36 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 24CA9300A2 for ; Thu, 14 Jun 2007 09:47:36 -0700 (PDT) X-AuditID: 11807125-9ef62bb000000801-4e-467171273ab9 Received: from [17.210.48.141] (singda.apple.com [17.202.35.52]) by relay7.apple.com (Apple SCV relay) with ESMTP id D58A2300D7 for ; Thu, 14 Jun 2007 09:47:35 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Thu, 14 Jun 2007 09:45:46 -0700 To: mmusic From: Dave Singer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [MMUSIC] ISMA on trick modes and cookies 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. At the recent ISMA meeting we had a discussion on trick modes in RTSP, and what we'd like. We also discussed cookies. The overall model for RTSP+RTP is that the RTP receivers are unaware of RTSP operations. So we have suggestions on how to handle trick modes there. However, it's worth pointing out that this model is rather restrictive. The issues are most obvious with audio; playing a video stream at a different rate can be achieved by re-timing the frames (and maybe dropping some), Playing an audio stream at a different rate really means treating it as if it were at a different sampling rate. Think of a server that has an AAC coded 44.1 audio stream; playing at double really would be best done by decoding it, treating that as if it were coded at 88.2, and maybe pitch-shifting it back down, and re-sampling that to 44.1 and re-encoding and packetizing that. Few servers are willing to do such a loop. So we think it's worth exploring the 'RTP aware' model. In the RTP-unaware model, the 'scale' parameter seems fine. We think it should be clear that the server is re-timing the media to achieve the scale. It needs a companion parameter which allows the client to indicate how much bandwidth, compared to normal, the server can use. The server can use less than this, but not more; it should probably default to 1.0. So, scale=2;bandwidthmultiplier=1 means I want double-speed but you cannot use more bandwidth. scale=2; bandwidthmultiplier=2 means that from the client's point of view, it's OK to use twice the bandwidth (but the server may still thin for some other reason). The current suggested use of the 'speed' parameter -- to send data at the 'wrong' speed for the current play rate -- seems wrong. The suggestion is that it can be used for managing client buffer-fill, but that is better done, in our opinion, at the RTP level, using a client-server bandwidth and buffer management protocol, like TCP or the 3GPP RTP buffer management protocol. However, it does work for the RTP aware case. If I ask the server to send at speed=2, and then run my RTP stack treating the clockrate as having doubled, and the audio output (if it's audio) as if the sample rate had doubled, then this works. Again, it could do with an explicit bandwidth management companion parameter. Finally, we think cookies should be supported, that it should be clear whether the client cookie database is per-protocol (i.e. distinct for HTTP and RTSP) or shared. It does seem as if more and more people are using cookies with RTSP, and this ought to be standardized. -- David Singer Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 15 12:57:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzF6l-0007Zq-SV; Fri, 15 Jun 2007 12:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzF6l-0007ZB-1T for mmusic@ietf.org; Fri, 15 Jun 2007 12:57:11 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzF5N-0003Rl-FI for mmusic@ietf.org; Fri, 15 Jun 2007 12:55:46 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l5FGtfLo022190; Fri, 15 Jun 2007 10:55:42 -0600 (MDT) Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 15 Jun 2007 10:55:40 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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, 15 Jun 2007 10:55:38 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C621FF94@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE - additional 2-week WGLC on draft-ietf-mmusic-ice-16.txt Thread-Index: AcdyE/OWnQfYTwALS9CjtEPt+fPC2A9WDZSw From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Colin Perkins , Joerg Ott Subject: [MMUSIC] ICE - additional 2-week WGLC on draft-ietf-mmusic-ice-16.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 This is to announce an additional Working Group Last Call on ICE draft-ietf-mmusic-ice-16.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt This WGLC will end on Friday June 29 2007. Note that, as previously communicated by Colin, updated IPR disclosures were submitted on April 13th pertaining to ICE: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D838 https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D839 https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D840 For a full list of IPR disclosures on ICE, use this link: https://datatracker.ietf.org/public/ipr_search.cgi?option=3Ddocument_sear= c h&id_document_tag=3D11119 or use the IETF IPR search at https://datatracker.ietf.org/public/ipr_search.cgi Please send your final comments to the author and the mmusic mailing list. Jean-Francois (as WG co-chair) jfm@cablelabs.com=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jun 17 14:39:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzzed-0007y1-9T; Sun, 17 Jun 2007 14:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzzec-0007ta-39 for mmusic@ietf.org; Sun, 17 Jun 2007 14:39:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzzeb-0003Td-2C for mmusic@ietf.org; Sun, 17 Jun 2007 14:39:14 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 78B7C200F6 for ; Sun, 17 Jun 2007 20:39:12 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-57-46757fd0540e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5AD74200D0 for ; Sun, 17 Jun 2007 20:39:12 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 20:39:12 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MMUSIC] RE: New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 17 Jun 2007 20:38:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RE: New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt Thread-Index: AcexDW/tw2GXyajLQie3sVnHoTaY7AAASOSg From: "Stephen Mell (CV/ETL)" To: X-OriginalArrivalTime: 17 Jun 2007 18:39:12.0184 (UTC) FILETIME=[CC7E5B80:01C7B10E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.3 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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="===============0219546409==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0219546409== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B10E.CC4C12CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B10E.CC4C12CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Hi Miguel, >=20 > I would strongly agree that there is a need to explicitly specify an > exact packetisation time per media type within SDP. >=20 > Joe Stone has focussed on the interoperability of end points in his > postings; I think that the network itself also deserves some > consideration. >=20 > The maxmptime attribute given in V.152 (and I guess also the > packetcable "mptime" attribute) also helps prevent the endpoints from > generating a packet *SIZE* which is too large for the network, but I > don't know of a mechanism that allows the endpoints some flexibility > in negotiating and choosing packet times whilst still preventing them > from from generating a packet *RATE* which is considered too large for > network. >=20 > Given that network restrictions can often be expressed in terms of > these limits of sizes and rates, then a "minptime" (single valued) > attribute could perhaps be considered, so that endpoints can be given > an offer which allows them to choose (or negotiate, via an > intermeddiary) a media flow with charectersitics which falls within > these twin constraints of Maximum Payload size and Maximum Packet > Rate. >=20 > Having said that, we should also consider that in general, network > policing policy may need to be defined more rigorously, such that only > flows which exactly match specific traffic criteria are admitted > and/or transitted on policed parts of a network. Also real-world > endpoint implementations may impose additional restrictions on what > combinations of media types and packetisation times can be supported > (or at least viable without excessive use of available resources). >=20 > For these reasons I think that it is more important to address the > issue of providing an exact packetisation time for each media type > (allowing the media flow to be exactly specified) than it is to > provide a flexible framework (allowing the media flow to be bounded > within certain constraints). >=20 >=20 > My particular interest is in H.248. I've considered the problem with > respect to H.248, and come to the conclusion that a solution to the > "multiple ptimes" problem would be beneficial to interoperability, and > that H.248 does not in itself provide any solution to the problem. >=20 > The arguments relating to H.248 follow: >=20 > Within H.248 there are facilities which exist which allow multiple > SDPs (each containing exactly one media section, m line) to be passed > from Controller to Gateway, with flags (ReserveGroup) which instruct > the Gateway to reserve either one (ReserveGroup=3DOff) or all > (ReserveGroup=3DOn) of the SDPs (referred to as Groups). >=20 > At first sight, this might seem to provide H.248 with an escape from > the "multiple ptime" problem. By using multiple SDP groups, each with > its own "ptime" attribute and a single fully specified media type, the > specification of per-media type packetisation time can be achieved. >=20 > However this is problematic, as it restricts the Controller from using > a single Group, with ReserveValue=3DOn, and CHOOSE ( "$" ) as the = media > type, thus allowing the Gateway to choose a number of different media > types to reserve, according to the support for codecs, availablitity > of codecs, and importantly, the Gateways own preference policy with > regard to codecs. >=20 > To solve the "multiple ptimes" problem by using multiple groups, the > Controller must always fully specify the media type in each SDP group, > These use of underspecified or overspecified media types in the > controllers offer could mean (when ReserveValue=3DOn) that the > combination of media type and packet time in the Gateway's Answer is > no longer unambiguous. The CHOOSE facility allows the Controller to > know nothing about the media types that are supported on the network > and delegate responsibility for the media selection entirely the > Gateways. This CHOOSE facility cannot therefore be used, if the > "multiple ptimes" problem were tackled this way, using multiple > groups, as the use of mutiple groups defines a convention that then > limits the use of other constructs within the protocol. >=20 > Also each of the SDPs (Groups) has its own Session details eg: When > using multiple groups it is harder for the Controller to prevent the > Gateway from allocating separate session details to each of the > groups. Commonly, the controller will ask the Gateway to choose its > own session settings for each group and the Gateway then is at liberty > to assign different session details (inc. addressing details) to each > SDP Group. Where switching between reserved media types is > subsequently co-ordinated by the Controller this is not a problem. > When autonomous switching between the reserved media types occurs, as > in the case of the V.152 fallback mechanism, the consequences are > disasterous; the switch to a reserved non-compression codec must *NOT* > be accompanied by a change in source address as the the far end would > then interpret this as barge-in and ignore the packets. >=20 > To avoid the above problem and ensure that reservation of multiple > groups is made with the same session details in each Group, the > Gateway would require two reservation requests rather than one. The > first reservation would ask for single group asking the Gateway to add > its address details, and the second reservation would ask the Gateway > to reserve both groups with the identical address details explicitly, > learned from the first reservation response, supplied by the > controller in each group. This makes the "multiple groups" solution to > the "multiple ptimes" problem start to make the H.248 a little > unwieldy. >=20 > In conclusion, I believe, due to these two arguments, that H.248 > doesn't provides any viable workaround for the "multiple ptimes" > problem, when SDP is carried over H.248. >=20 >=20 >=20 > Regards, >=20 > Steve=20 ------_=_NextPart_001_01C7B10E.CC4C12CE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [MMUSIC] RE: New draft: multiple times problem = description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt

Hi Miguel,

I would strongly agree that there is a = need to explicitly specify an exact packetisation time per media type = within SDP.

Joe Stone has focussed on the = interoperability of end points in his postings; I think that the network = itself also deserves some consideration.

The maxmptime attribute given in V.152 = (and I guess also the packetcable "mptime" attribute) also = helps prevent the endpoints from generating a packet *SIZE* which is too = large for the network, but I don't know of a mechanism that allows the = endpoints some flexibility in negotiating and choosing packet times = whilst still preventing them from from generating a packet *RATE* which = is considered too large for network.

Given that network restrictions can = often be expressed in terms of these limits of sizes and rates, then a = "minptime" (single valued) attribute could perhaps be = considered, so that endpoints can be given an offer which allows them to = choose (or negotiate, via an intermeddiary) a media flow with = charectersitics which falls within these twin constraints of Maximum = Payload size and Maximum Packet Rate.

Having said that, we should also = consider that in general, network policing policy may need to be defined = more rigorously, such that only flows which exactly match specific = traffic criteria are admitted and/or transitted on policed parts of a = network. Also real-world endpoint implementations may impose additional = restrictions on what combinations of media types and packetisation times = can be supported (or at least viable without excessive use of available = resources).

For these reasons I think that it is = more important to address the issue of providing an exact packetisation = time for each media type (allowing the media flow to be exactly = specified) than it is to provide a flexible framework (allowing the = media flow to be bounded within certain constraints).


My particular interest is in H.248. = I've considered the problem with respect to H.248, and come to the = conclusion that a solution to the "multiple ptimes" problem = would be beneficial to interoperability, and that H.248 does not in = itself provide any solution to the problem.

The arguments relating to H.248 = follow:

Within H.248 there are facilities which = exist which allow multiple SDPs (each containing exactly one media = section, m line) to be passed from Controller to Gateway, with flags = (ReserveGroup) which instruct the Gateway to reserve either one = (ReserveGroup=3DOff) or all (ReserveGroup=3DOn) of the SDPs (referred to = as Groups).

At first sight, this might seem to = provide H.248 with an escape from the "multiple ptime" = problem. By using multiple SDP groups, each with its own = "ptime" attribute and a single fully specified media type, the = specification of per-media type packetisation time can be = achieved.

However this is problematic, as it = restricts the Controller from using a single Group, with = ReserveValue=3DOn, and CHOOSE  ( "$" ) as the media type, = thus allowing the Gateway to choose a number of different media types to = reserve, according to the support for codecs, availablitity of codecs, = and importantly, the Gateways own preference policy with regard to = codecs.

To solve the "multiple = ptimes" problem by using multiple groups, the Controller must = always fully specify the media type in each SDP group, These use of = underspecified or overspecified media types in the controllers offer = could mean (when ReserveValue=3DOn) that the combination of media type = and packet time in the Gateway's Answer is no longer unambiguous. The = CHOOSE facility allows the Controller to know nothing about the media = types that are supported on the network and delegate responsibility for = the media selection entirely the Gateways. This CHOOSE facility cannot = therefore be used, if the "multiple ptimes" problem were = tackled this way, using multiple groups, as the use of mutiple groups = defines a convention that then limits the use of other constructs within = the protocol.

Also each of the SDPs (Groups) has its = own Session details eg: When using multiple groups it is harder for the = Controller to prevent the Gateway from allocating separate session = details to each of the groups. Commonly, the controller will ask the = Gateway to choose its own session settings for each group and the = Gateway then is at liberty to assign different session details (inc. = addressing details) to each SDP Group. Where switching between reserved = media types is subsequently co-ordinated by the Controller this is not a = problem. When autonomous switching between the reserved media types = occurs, as in the case of the V.152 fallback mechanism, the consequences = are disasterous; the switch to a reserved non-compression codec must = *NOT* be accompanied by a change in source address as the the far end = would then interpret this as barge-in and ignore the packets.

To avoid the above problem and ensure = that reservation of multiple groups is made with the same session = details in each Group, the Gateway would require two reservation = requests rather than one. The first reservation would ask for single = group asking the Gateway to add its address details, and the second = reservation would ask the Gateway to reserve both groups with the = identical address details explicitly, learned from the first reservation = response,  supplied by the controller in each group. This makes the = "multiple groups" solution to the "multiple ptimes" = problem start to make the H.248 a little unwieldy.

In conclusion, I believe, due to these = two arguments, that H.248 doesn't provides any viable workaround for the = "multiple ptimes" problem, when SDP is carried over = H.248.



Regards,

Steve

------_=_NextPart_001_01C7B10E.CC4C12CE-- --===============0219546409== 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 --===============0219546409==-- From mmusic-bounces@ietf.org Mon Jun 18 03:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0BIM-0004oj-UZ; Mon, 18 Jun 2007 03:05:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0BIL-0004oK-6I; Mon, 18 Jun 2007 03:05:01 -0400 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 1I0BIK-0005jY-G8; Mon, 18 Jun 2007 03:05:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5I74c8c007058; Mon, 18 Jun 2007 10:04:58 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:04:51 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:04:50 +0300 Received: from [10.162.95.216] ([10.162.95.216]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:04:48 +0300 Message-ID: <46762E8D.3010406@nsn.com> Date: Mon, 18 Jun 2007 10:04:45 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Stephen Mell (CV/ETL)" Subject: Re: [MMUSIC] New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2007 07:04:49.0967 (UTC) FILETIME=[F64A4BF0:01C7B176] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: megaco@ietf.org, 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 Stephen: Thanks for your post. Some inline comments. Stephen Mell (CV/ETL) wrote: > Hi Miguel, > > I would strongly agree that there is a need to explicitly specify an > exact packetisation time per media type within SDP. Great > > Joe Stone has focussed on the interoperability of end points in his > postings; I think that the network itself also deserves some consideration. > I agree, there are different scenarios we should consider. I always thought this was related to network constraints, but Joe indicated that implementations in endpoints have restrictions, so we need to take both into account. > The maxmptime attribute given in V.152 (and I guess also the packetcable > "mptime" attribute) also helps prevent the endpoints from generating a > packet *SIZE* which is too large for the network, but I don't know of a > mechanism that allows the endpoints some flexibility in negotiating and > choosing packet times whilst still preventing them from from generating > a packet *RATE* which is considered too large for network. I guess packet rate is a a complex issue, which depends primarily on the selected codec. I would say that this is a separate topic. > > Given that network restrictions can often be expressed in terms of these > limits of sizes and rates, then a "minptime" (single valued) attribute > could perhaps be considered, so that endpoints can be given an offer > which allows them to choose (or negotiate, via an intermeddiary) a media > flow with charectersitics which falls within these twin constraints of > Maximum Payload size and Maximum Packet Rate. I think, based on the discussions, we are heading to a direction where we are going to need some sort of threshold for the packetization time, which is negotiated between the endpoints. In other cases, where negotiation is not really needed, a hint might be enough. > > Having said that, we should also consider that in general, network > policing policy may need to be defined more rigorously, such that only > flows which exactly match specific traffic criteria are admitted and/or > transitted on policed parts of a network. Also real-world endpoint > implementations may impose additional restrictions on what combinations > of media types and packetisation times can be supported (or at least > viable without excessive use of available resources). I agree, the network policy in many cases influence these decisions. There are quite a few options for transferring the policy to the endpoints, all of them are outside the scope of the problem. So, I think we need to consider that there might be a mechanism for the endpoint to discover a policy that affects the packetization time. And we should take this into account. > > For these reasons I think that it is more important to address the issue > of providing an exact packetisation time for each media type (allowing > the media flow to be exactly specified) than it is to provide a flexible > framework (allowing the media flow to be bounded within certain > constraints). I think we are going to need to both. In fact, an interval of packetization times can be set to a fixed limit, if both limits are equal. > > > My particular interest is in H.248. I've considered the problem with > respect to H.248, and come to the conclusion that a solution to the > "multiple ptimes" problem would be beneficial to interoperability, and > that H.248 does not in itself provide any solution to the problem. Great > > The arguments relating to H.248 follow: > > Within H.248 there are facilities which exist which allow multiple SDPs > (each containing exactly one media section, m line) to be passed from > Controller to Gateway, with flags (ReserveGroup) which instruct the > Gateway to reserve either one (ReserveGroup=Off) or all > (ReserveGroup=On) of the SDPs (referred to as Groups). > > At first sight, this might seem to provide H.248 with an escape from the > "multiple ptime" problem. By using multiple SDP groups, each with its > own "ptime" attribute and a single fully specified media type, the > specification of per-media type packetisation time can be achieved. Something similar has been suggested as a solution, not only for H.248. I don't like grouping, or in this case, ungrouping codecs, just because of a simple limitation in the protocol. > > However this is problematic, as it restricts the Controller from using a > single Group, with ReserveValue=On, and CHOOSE ( "$" ) as the media > type, thus allowing the Gateway to choose a number of different media > types to reserve, according to the support for codecs, availablitity of > codecs, and importantly, the Gateways own preference policy with regard > to codecs. > > To solve the "multiple ptimes" problem by using multiple groups, the > Controller must always fully specify the media type in each SDP group, > These use of underspecified or overspecified media types in the > controllers offer could mean (when ReserveValue=On) that the combination > of media type and packet time in the Gateway's Answer is no longer > unambiguous. The CHOOSE facility allows the Controller to know nothing > about the media types that are supported on the network and delegate > responsibility for the media selection entirely the Gateways. This > CHOOSE facility cannot therefore be used, if the "multiple ptimes" > problem were tackled this way, using multiple groups, as the use of > mutiple groups defines a convention that then limits the use of other > constructs within the protocol. > > Also each of the SDPs (Groups) has its own Session details eg: When > using multiple groups it is harder for the Controller to prevent the > Gateway from allocating separate session details to each of the groups. > Commonly, the controller will ask the Gateway to choose its own session > settings for each group and the Gateway then is at liberty to assign > different session details (inc. addressing details) to each SDP Group. > Where switching between reserved media types is subsequently > co-ordinated by the Controller this is not a problem. When autonomous > switching between the reserved media types occurs, as in the case of the > V.152 fallback mechanism, the consequences are disasterous; the switch > to a reserved non-compression codec must *NOT* be accompanied by a > change in source address as the the far end would then interpret this as > barge-in and ignore the packets. > > To avoid the above problem and ensure that reservation of multiple > groups is made with the same session details in each Group, the Gateway > would require two reservation requests rather than one. The first > reservation would ask for single group asking the Gateway to add its > address details, and the second reservation would ask the Gateway to > reserve both groups with the identical address details explicitly, > learned from the first reservation response, supplied by the controller > in each group. This makes the "multiple groups" solution to the > "multiple ptimes" problem start to make the H.248 a little unwieldy. > > In conclusion, I believe, due to these two arguments, that H.248 doesn't > provides any viable workaround for the "multiple ptimes" problem, when > SDP is carried over H.248. The conclusion is as expected, thanks for making it 100% clear. /Miguel > > > > Regards, > > Steve > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 18 03:56:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0C5j-0003r2-EF; Mon, 18 Jun 2007 03:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0C5i-0003qs-Cn; Mon, 18 Jun 2007 03:56:02 -0400 Received: from ipmail03.adl2.internode.on.net ([203.16.214.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0C5h-0000ho-89; Mon, 18 Jun 2007 03:56:02 -0400 X-IronPort-AV: E=Sophos;i="4.16,434,1175437800"; d="scan'208";a="104435519" Received: from ppp121-44-192-243.lns3.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.192.243]) by ipmail03.adl2.internode.on.net with ESMTP; 18 Jun 2007 17:25:31 +0930 Message-ID: <46763A72.9080108@nteczone.com> Date: Mon, 18 Jun 2007 17:55:30 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Stephen Mell (CV/ETL)" Subject: Re: [MMUSIC] RE: New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: megaco ietf , 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 Hello Stephen, I didn't see what H.248 command/flow that you want to be able to support? Did you want to the MGC to CHOOSE a media type (single group) based on a list of ptimes it provides? Or CHOOSE a media type (single group) and then get the list of ptimes? or CHOOSE on a single group and get back multiple groups? or? An example of the flow you want would be good. There are other mechanisms e.g. ReserveValue, Overspecification, choose on ptime etc I'm not sure if these may be suitable. Is it correct that you are advocating not to use the ReserveGroup concept in general as your arguments seem to be general in nature? Regards, Christian Stephen Mell (CV/ETL) wrote: > > Hi Miguel, > > I would strongly agree that there is a need to explicitly specify an > exact packetisation time per media type within SDP. > > Joe Stone has focussed on the interoperability of end points in his > postings; I think that the network itself also deserves some > consideration. > > The maxmptime attribute given in V.152 (and I guess also the > packetcable "mptime" attribute) also helps prevent the endpoints from > generating a packet *SIZE* which is too large for the network, but I > don't know of a mechanism that allows the endpoints some flexibility > in negotiating and choosing packet times whilst still preventing them > from from generating a packet *RATE* which is considered too large for > network. > > Given that network restrictions can often be expressed in terms of > these limits of sizes and rates, then a "minptime" (single valued) > attribute could perhaps be considered, so that endpoints can be given > an offer which allows them to choose (or negotiate, via an > intermeddiary) a media flow with charectersitics which falls within > these twin constraints of Maximum Payload size and Maximum Packet Rate. > > Having said that, we should also consider that in general, network > policing policy may need to be defined more rigorously, such that only > flows which exactly match specific traffic criteria are admitted > and/or transitted on policed parts of a network. Also real-world > endpoint implementations may impose additional restrictions on what > combinations of media types and packetisation times can be supported > (or at least viable without excessive use of available resources). > > For these reasons I think that it is more important to address the > issue of providing an exact packetisation time for each media type > (allowing the media flow to be exactly specified) than it is to > provide a flexible framework (allowing the media flow to be bounded > within certain constraints). > > > My particular interest is in H.248. I've considered the problem with > respect to H.248, and come to the conclusion that a solution to the > "multiple ptimes" problem would be beneficial to interoperability, and > that H.248 does not in itself provide any solution to the problem. > > The arguments relating to H.248 follow: > > Within H.248 there are facilities which exist which allow multiple > SDPs (each containing exactly one media section, m line) to be passed > from Controller to Gateway, with flags (ReserveGroup) which instruct > the Gateway to reserve either one (ReserveGroup=Off) or all > (ReserveGroup=On) of the SDPs (referred to as Groups). > > At first sight, this might seem to provide H.248 with an escape from > the "multiple ptime" problem. By using multiple SDP groups, each with > its own "ptime" attribute and a single fully specified media type, the > specification of per-media type packetisation time can be achieved. > > However this is problematic, as it restricts the Controller from using > a single Group, with ReserveValue=On, and CHOOSE ( "$" ) as the media > type, thus allowing the Gateway to choose a number of different media > types to reserve, according to the support for codecs, availablitity > of codecs, and importantly, the Gateways own preference policy with > regard to codecs. > > To solve the "multiple ptimes" problem by using multiple groups, the > Controller must always fully specify the media type in each SDP group, > These use of underspecified or overspecified media types in the > controllers offer could mean (when ReserveValue=On) that the > combination of media type and packet time in the Gateway's Answer is > no longer unambiguous. The CHOOSE facility allows the Controller to > know nothing about the media types that are supported on the network > and delegate responsibility for the media selection entirely the > Gateways. This CHOOSE facility cannot therefore be used, if the > "multiple ptimes" problem were tackled this way, using multiple > groups, as the use of mutiple groups defines a convention that then > limits the use of other constructs within the protocol. > > Also each of the SDPs (Groups) has its own Session details eg: When > using multiple groups it is harder for the Controller to prevent the > Gateway from allocating separate session details to each of the > groups. Commonly, the controller will ask the Gateway to choose its > own session settings for each group and the Gateway then is at liberty > to assign different session details (inc. addressing details) to each > SDP Group. Where switching between reserved media types is > subsequently co-ordinated by the Controller this is not a problem. > When autonomous switching between the reserved media types occurs, as > in the case of the V.152 fallback mechanism, the consequences are > disasterous; the switch to a reserved non-compression codec must *NOT* > be accompanied by a change in source address as the the far end would > then interpret this as barge-in and ignore the packets. > > To avoid the above problem and ensure that reservation of multiple > groups is made with the same session details in each Group, the > Gateway would require two reservation requests rather than one. The > first reservation would ask for single group asking the Gateway to add > its address details, and the second reservation would ask the Gateway > to reserve both groups with the identical address details explicitly, > learned from the first reservation response, supplied by the > controller in each group. This makes the "multiple groups" solution to > the "multiple ptimes" problem start to make the H.248 a little unwieldy. > > In conclusion, I believe, due to these two arguments, that H.248 > doesn't provides any viable workaround for the "multiple ptimes" > problem, when SDP is carried over H.248. > > > > Regards, > > Steve > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jun 18 05:02:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0D8P-0000Gx-Oz; Mon, 18 Jun 2007 05:02:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0D8P-0000Gr-9b for mmusic@ietf.org; Mon, 18 Jun 2007 05:02:53 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0D8N-0000cG-FY for mmusic@ietf.org; Mon, 18 Jun 2007 05:02:53 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B5F4320741 for ; Mon, 18 Jun 2007 11:02:50 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-e7-46764a3af87b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9EA8A20715 for ; Mon, 18 Jun 2007 11:02:50 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:02:48 +0200 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: Mon, 18 Jun 2007 11:02:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt Thread-Index: AcexDW/tw2GXyajLQie3sVnHoTaY7AAASOSgAB4kZ2A= From: "Stephen Mell (CV/ETL)" To: X-OriginalArrivalTime: 18 Jun 2007 09:02:48.0133 (UTC) FILETIME=[7134B750:01C7B187] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [MMUSIC] RE: New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-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 Hello List, I would strongly agree that there is a need to explicitly specify an exact packetisation time per media type within SDP. Joe Stone has focussed on the interoperability of end points in his postings; I think that the network itself also deserves some consideration. The maxmptime attribute given in V.152 (and I guess also the packetcable "mptime" attribute) also helps prevent the endpoints from generating a packet *SIZE* which is too large for the network, but I don't know of a mechanism that allows the endpoints some flexibility in negotiating and choosing packet times whilst still preventing them from from generating a packet *RATE* which is considered too large for network. Given that network restrictions can often be expressed in terms of these limits of sizes and rates, then a "minptime" (single valued) attribute could perhaps be considered, so that endpoints can be given an offer which allows them to choose (or negotiate, via an intermeddiary) a media flow with charectersitics which falls within these twin constraints of Maximum Payload size and Maximum Packet Rate. Having said that, we should also consider that in general, network policing policy may need to be defined more rigorously, such that only flows which exactly match specific traffic criteria are admitted and/or transitted on policed parts of a network. Also real-world endpoint implementations may impose additional restrictions on what combinations of media types and packetisation times can be supported (or at least viable without excessive use of available resources). For these reasons I think that it is more important to address the issue of providing an exact packetisation time for each media type (allowing the media flow to be exactly specified) than it is to provide a flexible framework (allowing the media flow to be bounded within certain constraints). My particular interest is in H.248. I've considered the problem with respect to H.248, and come to the conclusion that a solution to the "multiple ptimes" problem would be beneficial to interoperability, and that H.248 does not in itself provide any solution to the problem. The arguments relating to H.248 follow: Within H.248 there are facilities which exist which allow multiple SDPs (each containing exactly one media section, m line) to be passed from Controller to Gateway, with flags (ReserveGroup) which instruct the Gateway to reserve either one (ReserveGroup=3DOff) or all (ReserveGroup=3DOn) of the SDPs (referred to as Groups). At first sight, this might seem to provide H.248 with an escape from the "multiple ptime" problem. By using multiple SDP groups, each with its own "ptime" attribute and a single fully specified media type, the specification of per-media type packetisation time can be achieved. However this is problematic, as it restricts the Controller from using a single Group, with ReserveValue=3DOn, and CHOOSE ( "$" ) as the media type, thus allowing the Gateway to choose a number of different media types to reserve, according to the support for codecs, availablitity of codecs, and importantly, the Gateways own preference policy with regard to codecs. To solve the "multiple ptimes" problem by using multiple groups, the Controller must always fully specify the media type in each SDP group, These use of underspecified or overspecified media types in the controllers offer could mean (when ReserveValue=3DOn) that the = combination of media type and packet time in the Gateway's Answer is no longer unambiguous. The CHOOSE facility allows the Controller to know nothing about the media types that are supported on the network and delegate responsibility for the media selection entirely the Gateways. This CHOOSE facility cannot therefore be used, if the "multiple ptimes" problem were tackled this way, using multiple groups, as the use of mutiple groups defines a convention that then limits the use of other constructs within the protocol. Also each of the SDPs (Groups) has its own Session details eg: When using multiple groups it is harder for the Controller to prevent the Gateway from allocating separate session details to each of the groups. Commonly, the controller will ask the Gateway to choose its own session settings for each group and the Gateway then is at liberty to assign different session details (inc. addressing details) to each SDP Group. Where switching between reserved media types is subsequently co-ordinated by the Controller this is not a problem. When autonomous switching between the reserved media types occurs, as in the case of the V.152 fallback mechanism, the consequences are disasterous; the switch to a reserved non-compression codec must *NOT* be accompanied by a change in source address as the the far end would then interpret this as barge-in and ignore the packets. To avoid the above problem and ensure that reservation of multiple groups is made with the same session details in each Group, the Gateway would require two reservation requests rather than one. The first reservation would ask for single group asking the Gateway to add its address details, and the second reservation would ask the Gateway to reserve both groups with the identical address details explicitly, learned from the first reservation response, supplied by the controller in each group. This makes the "multiple groups" solution to the "multiple ptimes" problem start to make the H.248 a little unwieldy. In conclusion, I believe, due to these two arguments, that H.248 doesn't provides any viable workaround for the "multiple ptimes" problem, when SDP is carried over H.248. Regards, Steve=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 18 10:23:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0I8I-00088F-EG; Mon, 18 Jun 2007 10:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0I8H-00088A-Pe for mmusic@ietf.org; Mon, 18 Jun 2007 10:23:05 -0400 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 1I0I8F-0004rC-QG for mmusic@ietf.org; Mon, 18 Jun 2007 10:23:05 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJU000AT5A3XC@siemenscomms.co.uk> for mmusic@ietf.org; Mon, 18 Jun 2007 15:22:51 +0100 (BST) Date: Mon, 18 Jun 2007 15:23:00 +0100 From: "Elwell, John" Subject: RE: [MMUSIC] ICE-16 now posted In-reply-to: <46715078.3040004@cisco.com> To: Jonathan Rosenberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E881@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [MMUSIC] ICE-16 now posted Thread-Index: AceukE7nNCrEbnPORuOLxsUn2/OPlADI4R8A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <466F55D8.9090504@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D019E63F@GBNTHT12009MSX.gb002.siemens.net> <46715078.3040004@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: IETF 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 It says: "ICE endpoints allow for STUN-based keepalives for UDP streams, and as such, STUN keepalives MUST be used when an agent is communicating with a peer that supports ICE." So this statement and the statement I quoted previously seem to say that a lite implementation MUST send STUN keepalives - it cannot choose different mechanisms. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 14 June 2007 15:28 > To: Elwell, John > Cc: IETF MMUSIC WG > Subject: Re: [MMUSIC] ICE-16 now posted > > I think its good practice regardless of NAT traversal. In > this case the > endpoint doesn't need to send STUN; it can use any of the mechanisms > mentioned there. > > -Jonathan R. > > Elwell, John wrote: > > > Jonathan, > > > > Is it correct that lite implementations are required to initiate > > keep-alives? This seems to be indicated by the statement in > section 10 > > "All endpoints MUST send keepalives for each media session. These > > keepalives serve the purpose of keeping NAT bindings > alive for the > > media session." > > However, it seems unnecessary. > > > > John > > > > > >>-----Original Message----- > >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>Sent: 13 June 2007 03:27 > >>To: IETF MMUSIC WG > >>Subject: [MMUSIC] ICE-16 now posted > >> > >>ICE-16 is now available: > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt > >> > >>This revision incorporates comments received during WGLC. > >>Besides many > >>editorial changes, here are the substantive ones: > >> > >>* changed pair priority formula to be based on > controlling/controlled > >> roles rather than offerer/answerer. This allows pair > prioritization > >> to get fixed when there is a role conflict > >> > >>* clarified that a 300 error response is not permitted for > >> connectivity checks > >> > >>* added upper bounds to the number of characters in the foundation, > >> component-ID, priority, password and ufrag components of the > >> grammar. > >> > >>* spreading out of the start timers for check lists is > RECOMMENDED, to > >> avoid synchronized checks across streams > >> > >>* previously, if there was at least one candidate matching a default > >> in an offer, we'd proceed with ICE. Now, there must be a > candidate > >> for all defaults. > >> > >>* aligned rules for verifying ICE support between offerer > and answerer > >> > >>* added section on when you can free candidates after ICE has > >> concluded. It is done immediately for lite implementations, and > >> three seconds after ICE has concluded for full. Interactions with > >> forking are mentioned. > >> > >>* Major change: ICE lite now allows for multiple v6 candidates and a > >> single v4 candidate for each component. This came at the cost of > >> some increase in complexity of the spec and procedures for lite > >> implementations. In particular, ICE now proceeds when both agents > >> are lite. Lite implementations now need to perform role > selection, > >> and when controlling, send an updated offer. They need to > >>maintain a > >> basic state for each media stream (RUnning or Completed). Role > >> reversal is described based on usage of SIP signaling to > >>resolve the > >> conflicts. Lite implementations must send and process the > >> remote-candidates attribute, though this processing is > much simpler > >> than the full case (where its a big pain in fact) and only needed > >> for dual-stack (v4 only can ignore). Guidance added in > >> the appendix that says you SHOULD still do a full implementation > >> even if all you care about is ANAT replacement. > >> > >>* Major change: congestion control mechanism added. THis is done by > >> adjusting Ta and RTO based on a formula that takes into > account the > >> media bandwidth. Also, triggered checks are now scheduled rather > >> than being sent immediately; basically there is a priority queue > >> where every Ta you send a triggered check fi there is > one, else an > >> 'ordinary' check. Ordinary check is the new name for > periodic check > >> since these are not so periodic anymore. > >> > >>* If a transaction is in progress when a triggered check is to be > >> sent, it is cancelled and a new transaction is scheduled > >> (previously, there was an adjustment to the retransmits for the > >> existing transction). Cancellation implies retransmissions > >>cease and > >> the tranasction doesn't fail on timeout, but you still wait for a > >> response if there is one > >> > >>* clarified that NONCE is not used with ICE > >> > >>* added an informational appendix on when the conflict resolution > >> procedures are needed and why > >> > >>* clarified that when a FQDN is used in the candidate attribute, you > >> look up AAAA first then A, and pick a single IP > >> > >>* for 'poor mans RFC3262', if the offerer is lite, you won't get a > >> STUN Binding request to terminate 18x retransmits. For this case, > >> the spec now mandates no more than four retransmits of the > >> 18x. Another reason to implement full. > >> > >>* inclusion of FINGERPRINT is MUST: motivation for this captured in > >> rfc3489bis > >> > >>* ICMP support is a MAY > >> > >>I believe this is now ready for another WGLC. > >> > >>-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 > >> > > > > > > -- > 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 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 19 04:38:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZDx-0002V4-UZ; Tue, 19 Jun 2007 04:38:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZDw-0002Uo-HX for mmusic@ietf.org; Tue, 19 Jun 2007 04:38:04 -0400 Received: from neptune.azu.com ([67.15.54.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0ZDu-0006nX-09 for mmusic@ietf.org; Tue, 19 Jun 2007 04:38:04 -0400 Received: (qmail 1326 invoked by uid 89); 19 Jun 2007 17:37:56 +0900 Received: from unknown (HELO IBM-T42) (59.143.41.119) by 0 with SMTP; 19 Jun 2007 17:37:56 +0900 Date: Tue, 19 Jun 2007 17:37:59 +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: 14582b0692e7f70ce7111d04db3781c8 Subject: [MMUSIC] Final Call for Tutorial: IEEE/WIC/ACM WI-IAT'07 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] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2007 IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology (WI-IAT 2007) Silicon Valley, USA, November 2-5, 2007 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++ Call for Tutorials ++++++++++++++++++ The 2007 IEEE/WIC/ACM International Joint Conference on Web Intelligence (WI'07) and Intelligent Agent Technology (IAT'07) takes place on November 2-5, 2007, in Silicon Valley, the center of high tech and web technology. The IEEE/WIC/ACM 2007 joint conference is organized by San Jose State University, and sponsored by IEEE Computer Society Technical Committee on Intelligent Informatics (TCII), Web Intelligence Consortium (WIC), and ACM-SIGART. Homepage: http://www.cs.sjsu.edu/wi07/wi/?index=tutorial and http://www.cs.sjsu.edu/wi07/iat/?index=tutorial WI 2007 and IAT 2007 will include tutorials providing in-depth background on subjects that are of broad interest to the intelligent agent community. Both short (2 hours) and long (half day) tutorials will be considered. The following is a *non-exclusive* list of preferred topic areas for tutorial proposals: Web Intelligence: - Intelligent/Semantic Web Services - Intelligent Wireless Web and Ubiquitous Computing - Rules and Inference Engines for the Web - Semantic Web Concepts and Techniques for Security and Trust - Service-Oriented Computing - Social Networks and Social Intelligence - e-learning and e-science - Web Intelligence and Education Intelligent Agent Technology: - Agent-Based Modeling and Simulation - Agent Technologies in e-Business Systems - Agent-Mediated Knowledge Management - Peer-to-Peer Models for Multi-Agent Systems - Agent-Based Grid Computing Submission Details: Proposals for tutorials should consist of an outline and background information on the presenter(s). The tutorial outline should be limited to 2 pages and contain the following information: 1. Title and abstract of the tutorial 2. Proposed duration: 2 hours or half-day 3. Intended audience: to whom is the tutorial of interest 4. Prerequisite knowledge: what the attendees should already know 5. Detailed outline The background information on the presenter(s) should be limited to 1-2 pages and contain: 1. Names, affiliations, homepages and contact details 2. Short biographies 3. Information about previous tutorials given by the same presenters (title, location, number of attendees, etc.) Tutorial materials such as handouts and slides should be included if already available, but are not required for submission. Please send your proposal to pawan@cs.smu.ca or Pawan.Lingras@smu.ca Important Dates: July 1, 2007 Tutorial submissions July 10, 2007 Acceptance notices October 1, 2007 Camera-ready copy of tutorial handouts November 2-5, 2007 WI-IAT'07 tutorials Tutorial Chair: Pawan Lingras, Saint Mary's University, Canada Email: pawan@cs.smu.ca or Pawan.Lingras@smu.ca +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 19 08:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0chA-0005bg-C6; Tue, 19 Jun 2007 08:20:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ch9-0005bb-QK for mmusic@ietf.org; Tue, 19 Jun 2007 08:20:27 -0400 Received: from webidcmail.tatanova.com ([203.124.230.9] helo=tataisp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ch8-0000sW-Df for mmusic@ietf.org; Tue, 19 Jun 2007 08:20:27 -0400 Received: (qmail 3202 invoked for bounce); 19 Jun 2007 12:12:29 -0000 Received: from unknown (HELO smtp-gateway.tataisp.com) ([203.124.230.5]) (envelope-sender ) by 203.124.230.9 (qmail-ldap-1.03) with SMTP for ; 19 Jun 2007 12:12:29 -0000 Received: from localhost ([203.124.230.123]) by smtp-gateway.tataisp.com with InterScan Messaging Security Suite; Tue, 19 Jun 2007 18:25:45 +0530 Received: from dsl-KK-static-093.205.95.61.airtelbroadband.in (dsl-KK-static-093.205.95.61.airtelbroadband.in [61.95.205.93]) by idcwebmail.tatanova.com (IMP) with HTTP for ; Tue, 19 Jun 2007 17:39:45 +0530 Message-ID: <1182254985.4677c7899f7d4@idcwebmail.tatanova.com> Date: Tue, 19 Jun 2007 17:39:45 +0530 From: vvrevathi@ncoretech.com To: mmusic@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.4 X-Originating-IP: 61.95.205.93 X-imss-version: 2.047 X-imss-result: Passed X-imss-scores: Clean:94.10730 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:2 M:2 S:3 R:2 (0.1500 0.1500) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [MMUSIC] Regarding ICE 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, I am implement ICE functionality. I have some queries related with ICE. 1. What is the difference between peer reflexive candidate in Section 7.2.1.3 and 7.1.2.2.1 2. When to start Regular nomination check.... Regards Revathi _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 19 17:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lj4-0002Kr-Bs; Tue, 19 Jun 2007 17:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lj3-0002Kj-QR for mmusic@ietf.org; Tue, 19 Jun 2007 17:59:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lj2-0008QB-BP for mmusic@ietf.org; Tue, 19 Jun 2007 17:59:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Jun 2007 17:59:00 -0400 X-IronPort-AV: i="4.16,439,1175486400"; d="scan'208"; a="63195924:sNHT63419668" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5JLwxBX003895; Tue, 19 Jun 2007 17:58:59 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5JLwp5l027448; Tue, 19 Jun 2007 21:59:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 17:58:53 -0400 Received: from [63.118.137.64] ([10.82.240.17]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 17:58:53 -0400 Message-ID: <4678519C.1030401@cisco.com> Date: Tue, 19 Jun 2007 17:58:52 -0400 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: "Elwell, John" Subject: Re: [MMUSIC] ICE-16 now posted References: <466F55D8.9090504@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D019E63F@GBNTHT12009MSX.gb002.siemens.net> <46715078.3040004@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D019E881@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E881@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 21:58:53.0032 (UTC) FILETIME=[06762E80:01C7B2BD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7099; t=1182290340; x=1183154340; c=relaxed/simple; s=rtpdkim2001; 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=20[MMUSIC]=20ICE-16=20now=20posted |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=92bEjArpfftFExPmHu+asLQvnRYH+nIQgElbPh7jY9M=; b=lUKv2E9rnCJsszxIYKgW75nWIBhhoCrD/oXdSixuII2rB+AKzExRi7nv07L7nmc3FDTsYNcM a2trwohSQFUC2RA9KsWAgpMYBgRe923/vj9zwUiJRWXHAr4Ptp1c/qKM; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: IETF 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 OK, this text needs to be clarified. If an agent is ICE-lite it doesn't need to send STUN in general, including keepalives. -Jonathan R. Elwell, John wrote: > It says: > "ICE endpoints allow for > STUN-based keepalives for UDP streams, and as such, STUN keepalives > MUST be used when an agent is communicating with a peer that supports > ICE." > So this statement and the statement I quoted previously seem to say that > a lite implementation MUST send STUN keepalives - it cannot choose > different mechanisms. > > John > > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: 14 June 2007 15:28 >>To: Elwell, John >>Cc: IETF MMUSIC WG >>Subject: Re: [MMUSIC] ICE-16 now posted >> >>I think its good practice regardless of NAT traversal. In >>this case the >>endpoint doesn't need to send STUN; it can use any of the mechanisms >>mentioned there. >> >>-Jonathan R. >> >>Elwell, John wrote: >> >> >>>Jonathan, >>> >>>Is it correct that lite implementations are required to initiate >>>keep-alives? This seems to be indicated by the statement in >> >>section 10 >> >>>"All endpoints MUST send keepalives for each media session. These >>> keepalives serve the purpose of keeping NAT bindings >> >>alive for the >> >>> media session." >>>However, it seems unnecessary. >>> >>>John >>> >>> >>> >>>>-----Original Message----- >>>>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>>>Sent: 13 June 2007 03:27 >>>>To: IETF MMUSIC WG >>>>Subject: [MMUSIC] ICE-16 now posted >>>> >>>>ICE-16 is now available: >>>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt >>>> >>>>This revision incorporates comments received during WGLC. >>>>Besides many >>>>editorial changes, here are the substantive ones: >>>> >>>>* changed pair priority formula to be based on >> >>controlling/controlled >> >>>> roles rather than offerer/answerer. This allows pair >> >>prioritization >> >>>> to get fixed when there is a role conflict >>>> >>>>* clarified that a 300 error response is not permitted for >>>> connectivity checks >>>> >>>>* added upper bounds to the number of characters in the foundation, >>>> component-ID, priority, password and ufrag components of the >>>> grammar. >>>> >>>>* spreading out of the start timers for check lists is >> >>RECOMMENDED, to >> >>>> avoid synchronized checks across streams >>>> >>>>* previously, if there was at least one candidate matching a default >>>> in an offer, we'd proceed with ICE. Now, there must be a >> >>candidate >> >>>> for all defaults. >>>> >>>>* aligned rules for verifying ICE support between offerer >> >>and answerer >> >>>>* added section on when you can free candidates after ICE has >>>> concluded. It is done immediately for lite implementations, and >>>> three seconds after ICE has concluded for full. Interactions with >>>> forking are mentioned. >>>> >>>>* Major change: ICE lite now allows for multiple v6 candidates and a >>>> single v4 candidate for each component. This came at the cost of >>>> some increase in complexity of the spec and procedures for lite >>>> implementations. In particular, ICE now proceeds when both agents >>>> are lite. Lite implementations now need to perform role >> >>selection, >> >>>> and when controlling, send an updated offer. They need to >>>>maintain a >>>> basic state for each media stream (RUnning or Completed). Role >>>> reversal is described based on usage of SIP signaling to >>>>resolve the >>>> conflicts. Lite implementations must send and process the >>>> remote-candidates attribute, though this processing is >> >>much simpler >> >>>> than the full case (where its a big pain in fact) and only needed >>>> for dual-stack (v4 only can ignore). Guidance added in >>>> the appendix that says you SHOULD still do a full implementation >>>> even if all you care about is ANAT replacement. >>>> >>>>* Major change: congestion control mechanism added. THis is done by >>>> adjusting Ta and RTO based on a formula that takes into >> >>account the >> >>>> media bandwidth. Also, triggered checks are now scheduled rather >>>> than being sent immediately; basically there is a priority queue >>>> where every Ta you send a triggered check fi there is >> >>one, else an >> >>>> 'ordinary' check. Ordinary check is the new name for >> >>periodic check >> >>>> since these are not so periodic anymore. >>>> >>>>* If a transaction is in progress when a triggered check is to be >>>> sent, it is cancelled and a new transaction is scheduled >>>> (previously, there was an adjustment to the retransmits for the >>>> existing transction). Cancellation implies retransmissions >>>>cease and >>>> the tranasction doesn't fail on timeout, but you still wait for a >>>> response if there is one >>>> >>>>* clarified that NONCE is not used with ICE >>>> >>>>* added an informational appendix on when the conflict resolution >>>> procedures are needed and why >>>> >>>>* clarified that when a FQDN is used in the candidate attribute, you >>>> look up AAAA first then A, and pick a single IP >>>> >>>>* for 'poor mans RFC3262', if the offerer is lite, you won't get a >>>> STUN Binding request to terminate 18x retransmits. For this case, >>>> the spec now mandates no more than four retransmits of the >>>> 18x. Another reason to implement full. >>>> >>>>* inclusion of FINGERPRINT is MUST: motivation for this captured in >>>> rfc3489bis >>>> >>>>* ICMP support is a MAY >>>> >>>>I believe this is now ready for another WGLC. >>>> >>>>-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 >>>> >>> >>> >>-- >>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 >> > > -- 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 From mmusic-bounces@ietf.org Tue Jun 19 20:11:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nn7-0004Dt-NN; Tue, 19 Jun 2007 20:11:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nn5-00041z-NJ for mmusic@ietf.org; Tue, 19 Jun 2007 20:11:19 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nn4-0002kB-F2 for mmusic@ietf.org; Tue, 19 Jun 2007 20:11:19 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2007 20:11:18 -0400 X-IronPort-AV: i="4.16,440,1175486400"; d="scan'208"; a="124079085:sNHT55763696" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5K0BF1u031956; Tue, 19 Jun 2007 20:11:15 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5K08V5x025478; Wed, 20 Jun 2007 00:11:10 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 20:10:12 -0400 Received: from [63.115.24.215] ([10.86.243.145]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 20:10:12 -0400 Message-ID: <46787060.6080406@cisco.com> Date: Tue, 19 Jun 2007 20:10:08 -0400 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: vvrevathi@ncoretech.com Subject: Re: [MMUSIC] Regarding ICE References: <1182254985.4677c7899f7d4@idcwebmail.tatanova.com> In-Reply-To: <1182254985.4677c7899f7d4@idcwebmail.tatanova.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2007 00:10:12.0481 (UTC) FILETIME=[5EFAAF10:01C7B2CF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1033; t=1182298278; x=1183162278; c=relaxed/simple; s=rtpdkim1001; 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=20[MMUSIC]=20Regarding=20ICE |Sender:=20 |To:=20vvrevathi@ncoretech.com; bh=mqOiRHk9Eb6FF+Y9LP16hzs6NwpL5eKoKCv8UyYLRyQ=; b=CQhXfp7OzTIj+b0MAVb0InQr2/XJUnfciSRx0uiUH1VVR3/KUpoc9bxef5+GFTHWr2b+oYBJ CxfYUyW8OBMMueQOpSqi08hCc1i/daFZaLKeNd+hLZvZqCkBquzsCyBH; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 vvrevathi@ncoretech.com wrote: > Hi all, > > I am implement ICE functionality. I have some queries related with ICE. > > 1. What is the difference between peer reflexive candidate in Section 7.2.1.3 > and 7.1.2.2.1 Section 7.2.1.3 are procedures for the STUN *server* and 7.1.2.2.1 are procedures for the STUN *client*. > > 2. When to start Regular nomination check.... You mean the check with the USE-CANDIDATE flag? Its a matter of local implemnetation choice. You would typically wait until at least one check for each component of a media stream has suceeded, and then pick the candidate pairs you want to use and repeat the checks for them. Thanks, 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 From mmusic-bounces@ietf.org Mon Jun 25 13:13:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s7r-0004zm-H1; Mon, 25 Jun 2007 13:13:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s7q-0004yL-HP for mmusic@ietf.org; Mon, 25 Jun 2007 13:13:18 -0400 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 1I2s7p-0000ev-6e for mmusic@ietf.org; Mon, 25 Jun 2007 13:13:18 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2007 10:13:16 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="4733007:sNHT20354766" 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 l5PHDGC0025797 for ; Mon, 25 Jun 2007 10:13:16 -0700 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 l5PHD9n0028329 for ; Mon, 25 Jun 2007 17:13:16 GMT 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, 25 Jun 2007 10:13:13 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:13:13 -0700 Message-ID: <467FF7A8.6040303@cisco.com> Date: Mon, 25 Jun 2007 13:13:12 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 17:13:14.0086 (UTC) FILETIME=[1D551060:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1195; t=1182791596; x=1183655596; 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:=20SDPCapNeg=20Issue=20#1=3A=20To=20Add, =20Delete=20and=20Replac e=20Attributes |Sender:=20; bh=RkWLNg6JmpKvYSOrKiHsx4+huY11uQKslNwgsjPrfKM=; b=LN97pkGu20c61m/A5FPJ6IW0Zet1vMPCgyhYLtO8by3oBd5qHHKy/mcRlLiff6nMix6w5OEz 7M38iIHLXjOi+PkODfSfE3UgFb9zRYmAX+3VtuJOFdv/pxyVHk4HjDkm; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes 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 Probably the biggest open issue we have in the SDP Capability Negotiation Framework at this point is the ability to replace and delete attributes from an actual configuration SDP when generating a potential configuration. At the Prague IETF, people asked for some more motiviation and use cases for this feature before deciding whether we should include it in the core capability negotiation framework or not. I have written a short I-D in the subject, which you can find at: http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att-del-00.txt Please take a look at this and let me know how you think we should resolve this issue. Options include: A) Remove the ability to delete and replace attributes completely. B) Remove the ability to delete and replace individual attributes, but allow for complete removal of all attributes (clean slate) C) Keep the current ability to delete and remove individual and all attributes. My personal preference is for option A, however in the interest of moving forward and making a reasonable compromise between functionality and complexity, my recommendation is option B. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 25 13:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s8Q-0005FD-U6; Mon, 25 Jun 2007 13:13:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s8Q-0005Ey-4F for mmusic@ietf.org; Mon, 25 Jun 2007 13:13:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2s8O-0000h9-Oj for mmusic@ietf.org; Mon, 25 Jun 2007 13:13:54 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2007 10:13:45 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208,217"; a="171681319:sNHT262993410" 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 l5PHDjkx026619 for ; Mon, 25 Jun 2007 10:13:45 -0700 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 l5PHDjka020642 for ; Mon, 25 Jun 2007 17:13:45 GMT 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, 25 Jun 2007 10:13:45 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:13:45 -0700 Message-ID: <467FF7C8.6080807@cisco.com> Date: Mon, 25 Jun 2007 13:13:44 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 25 Jun 2007 17:13:45.0478 (UTC) FILETIME=[300B1A60:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2238; t=1182791625; x=1183655625; 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:=20SDPCapNeg=20Issue=20#2=3A=20Answer=20not=20getting=20through= 20middle-boxes=20if=20transport=0A=20protocol=20in=20answer=20differs=20fr om=20offer |Sender:=20; bh=alk7yjZsN2/wW5pdJgIQEBs038OHKNkeT7U8RUz8hlw=; b=Nl0ss4ojU3YY75UOjfQQCWutpNuwQLNelXz4yZs85Q32JGdUH/rdmFw4g+tBe/WzvL0/VPJP 19N0zIf0nX6VyXSQGthSePoM73zNabLq2qJUnp7l1t6RTo3o7IYbFQmS; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 1.0 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [MMUSIC] SDPCapNeg Issue #2: Answer not getting through middle-boxes if transport protocol in answer differs from offer 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="===============2074982895==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============2074982895== Content-Type: multipart/alternative; boundary="------------070201090008010809080104" This is a multi-part message in MIME format. --------------070201090008010809080104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The current document allows for one transport protocol to be listed in the offer "m=" line, and based on the potential configuration, the answer SDP may include a different transport protocol in the corresponding "m=" line. Hadriel Kaplan had pointed out that some SBCs will not pass an answer that has a different transport protocol than the offer. The design team discussed this in Prague, however the feeling was that addressing it would make the solution even more complicated (generate two valid answers essentially, one of which has to be encoded in attributes), so we want to keep the current solution as-is and instead hope that such SBCs will be updated. The draft will be updated to explain this issue. If you have a major concern with this approach, please speak up. Thanks -- Flemming --------------070201090008010809080104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The current document allows for one transport protocol to be listed in the offer "m=" line, and based on the potential configuration, the answer SDP may include a different transport protocol in the corresponding "m=" line. Hadriel Kaplan had pointed out that some SBCs will not pass an answer that has a different transport protocol than the offer.

The design  team discussed this in Prague, however the feeling was that addressing it would make the solution even more complicated (generate two valid answers essentially, one of which has to be encoded in attributes), so we want to keep the current solution as-is and instead hope that such SBCs will be updated. The draft will be updated to explain this issue.

If you have a major concern with this approach, please speak up.

Thanks

-- Flemming

--------------070201090008010809080104-- --===============2074982895== 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 --===============2074982895==-- From mmusic-bounces@ietf.org Mon Jun 25 13:14:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s8k-00060H-Lq; Mon, 25 Jun 2007 13:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s8j-0005wu-4u for mmusic@ietf.org; Mon, 25 Jun 2007 13:14:13 -0400 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 1I2s8i-0000iV-FO for mmusic@ietf.org; Mon, 25 Jun 2007 13:14:13 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2007 10:14:09 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArdeAAaUf0arR7O6h2dsb2JhbACCKjeFcINegm8BAQkOLJpW X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208,217"; a="381653790:sNHT7049460604" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5PHE9et025445 for ; Mon, 25 Jun 2007 10:14:09 -0700 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 l5PHE0kc020816 for ; Mon, 25 Jun 2007 17:14:09 GMT 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, 25 Jun 2007 10:14:02 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:14:02 -0700 Message-ID: <467FF7D9.1030702@cisco.com> Date: Mon, 25 Jun 2007 13:14:01 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 25 Jun 2007 17:14:02.0478 (UTC) FILETIME=[3A2D18E0:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7455; t=1182791649; x=1183655649; 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:=20SDPCapNeg=20Issue=20#3=3A=20Inconsistent=20media-level=20sele ction=20of=20session-level=0A=20attribute=20capabilities |Sender:=20; bh=UdpwnabrO9UiKbiebnLuDyVtqVHNYQC5i02H5hrgf+o=; b=VTiVW+gfb/zofVJGG41BMp4oIlL+VbSvLifjZ0+1kehckIrboT6XpjUOEhSzQo5IeCWLf4lr IB7m3Eq37TVIyE4euPUI6t/NCTpYMvD+LdgQ2+ltPQr00XFij1xow9rR; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Subject: [MMUSIC] SDPCapNeg Issue #3: Inconsistent media-level selection of session-level attribute capabilities 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="===============0229915203==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0229915203== Content-Type: multipart/alternative; boundary="------------000903060907070503020206" This is a multi-part message in MIME format. --------------000903060907070503020206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The SDP Capability Negotiation framework allows attribute capabilities to be defined at the session-level and at the media-level. When a session-level attribute capability is used by a potential configuration, the session-level attribute is effectively added to the SDP. The capability negotiation framework however does not provide for any coordination between potential configurations chosen by media stream A and media stream B. Thus, it is possible that media stream A selects a potential configuration that uses session-level attribute A, and media stream B selects a potential configuration that uses session-level (or media-level) attribute B, where attribute A and B conflict or interact with each other. The design team discussed two different solutions to this issue in Prague: 1) Explain the issue in the document as outlined above and recommend that people avoid using session-level capabilities for cases where such inconsistencies may occur. 2) On the offering side, make sure that we generate sane offers where this issue is not present in the actual configuration SDP to begin with. On the answering side, the answerer will need to look at the resulting potential configuration SDPs. If a potential configuration SDP doesn't make sense (e.g. as a result of the above), the answerer must discard it and move on to the next. Note that the above is only a problem if we have one or more session-level attributes that can interact or conflict with another session-level or media-level attribute. This is related to SDPCapNeg Issue #1, where we recognized this as a general issue, but didn't find a lot of examples with existing SDP attributes. The primary example we found in terms of conflicts was with a session-level "keymgt" attribute and a media level "crypto" attribute (or potentially multiple "keymgt" attributes at the session-level), however this particular interaction is well-known. A slightly different set of problems related to this issue is when we need *coordination* between session-level attributes from multiple media streams in order for a particular functionality to actually work. The grouping framework (RFC 3388) is an example of this. If we use the SDP capability negotiation framework to select a session-level group attribute (provided as an attribute capability), and we require two media streams to do this consistently, we could have a problem. The FEC grouping semantics is at least in theory one example where this could cause problems, however in practice, it is unclear that this poses a significant problem with the currently defined grouping semantics. In terms of a solution to this CapNeg issue, I believe it is difficult to rely on the answerer to determine what does and does not make sense, at least if we want to have consistent operation between different implementations. Since there doesn't seem to be a huge problem here in practice anyway, the recommended solution is option 1, i.e. explain the issue in the document and avoid using session-level capabilities where this may pose a problem. If you disagree with this, please let me know. Thanks -- Flemming --------------000903060907070503020206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The SDP Capability Negotiation framework allows attribute capabilities to be defined at the session-level and at the media-level. When a session-level attribute capability is used by a potential configuration, the session-level attribute is effectively added to the SDP. The capability negotiation framework however does not provide for any coordination between potential configurations chosen by media stream A and media stream B. Thus, it is possible that media stream A selects a potential configuration that uses session-level attribute A, and media stream B selects a potential configuration that uses session-level (or media-level) attribute B, where attribute A and B conflict or interact with each other.

The design team discussed two different solutions to this issue in Prague:
1) Explain the issue in the document as outlined above and recommend that people avoid using session-level capabilities for cases where such inconsistencies may occur.
2) On the offering side, make sure that we generate sane offers where this issue is not present in the actual configuration SDP to begin with. On the answering side, the answerer will need to look at the resulting potential configuration SDPs. If a potential configuration SDP doesn't make sense (e.g. as a result of the above), the answerer must discard it and move on to the next.


Note that the above is only a problem if we have one or more session-level attributes that can interact or conflict with another session-level or media-level attribute. This is related to SDPCapNeg Issue #1, where we recognized this as a general issue, but didn't find a lot of examples with existing SDP attributes. The primary example we found in terms of conflicts was with a session-level "keymgt" attribute and a media level "crypto" attribute (or potentially multiple "keymgt" attributes at the session-level), however this particular interaction is well-known.


A slightly different set of problems related to this issue is when we need *coordination* between session-level attributes from multiple media streams in order for a particular functionality to actually work. The grouping framework (RFC 3388) is an example of this. If we use the SDP capability negotiation framework to select a session-level group attribute (provided as an attribute capability), and we require two media streams to do this consistently, we could have a problem. The FEC grouping semantics is at least in theory one example where this could cause problems, however in practice, it is unclear that this poses a significant problem with the currently defined grouping semantics.


In terms of a solution to this CapNeg issue, I believe it is difficult to rely on the answerer to determine what does and does not make sense, at least if we want to have consistent operation between different implementations. Since there doesn't seem to be a huge problem here in practice anyway, the recommended solution is option 1, i.e. explain the issue in the document and avoid using session-level capabilities where this may pose a problem. If you disagree with this, please let me know.

Thanks

-- Flemming




 




















--------------000903060907070503020206-- --===============0229915203== 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 --===============0229915203==-- From mmusic-bounces@ietf.org Mon Jun 25 13:14:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s98-0007bS-9l; Mon, 25 Jun 2007 13:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s97-0007Qt-0f for mmusic@ietf.org; Mon, 25 Jun 2007 13:14:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2s95-0000qQ-Im for mmusic@ietf.org; Mon, 25 Jun 2007 13:14:37 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2007 10:14:35 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208,217"; a="171681920:sNHT73533870" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5PHEZDm026267 for ; Mon, 25 Jun 2007 10:14:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5PHE8l2020911 for ; Mon, 25 Jun 2007 17:14:35 GMT 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, 25 Jun 2007 10:14:24 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:14:23 -0700 Message-ID: <467FF7EE.1000801@cisco.com> Date: Mon, 25 Jun 2007 13:14:22 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic , Jonathan Rosenberg X-OriginalArrivalTime: 25 Jun 2007 17:14:23.0837 (UTC) FILETIME=[46E838D0:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3665; t=1182791675; x=1183655675; 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:=20SDPCapNeg=20Issue=20#4=3A=20Does=203PCC=20imply=20a=20need=20 to=20always=20include=20=22creq=22=0A=20attribute=20with=20base=20option-t ag=20? |Sender:=20; bh=dU9eEQpkz8VT5wPKEUcn9V+AwLNYtaxOdSN9gPax0gs=; b=RN/ULWdiCGFFPU8S3KOEslBYM3j67Or9E6mGefaO6tH0CR8N+x/+aK6SX6CrovMWK0f7izmH Ob+JSJg+/H67cU+nYWiTa5udNg6H/Zi3LvbYg3TsLHY9/4WcHF8XiFcx; 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: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [MMUSIC] SDPCapNeg Issue #4: Does 3PCC imply a need to always include "creq" attribute with base option-tag ? 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="===============0706213691==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0706213691== Content-Type: multipart/alternative; boundary="------------090702040505080106080307" This is a multi-part message in MIME format. --------------090702040505080106080307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The SDP Capability Negotiation currently defines the "creq" attribute as follows: The Required Capability Negotiation Extensions attribute ("a=creq") contains a comma-separated list of option tags (see Section 3.3.1. ) identifying the SDP Capability negotiation extensions that MUST be supported by the entity receiving the SDP in order for that entity to properly process the SDP Capability Negotiation attributes and associated procedures. Support for the basic negotiation framework is implied by the presence of an "a=pcfg" attribute (see Section 3.5.1. ) and hence there is no need to include the "a=creq" attribute with the base option-tag ("cap-v0"). Still, it is allowed to do so. Jonathan Rosenberg raised the question whether 3PCC can wreak havoc with the above scheme of inferring support for the basic SDP Capability Negotiation framework by looking for "pcfg" attributes, as opposed to explicitly including the "creq" attribute with the base option-tag. The design team discussed this issue in Prague and didn't see how inclusion of the "creq" attribute-tag with a base option-tag would be any better than just looking for "pcfg" attributes. In the absence of Jonathan pointing out any specific problems with the above scheme, it will stay as-is. If you disagree with this, please let me know. Thanks -- Flemming --------------090702040505080106080307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The SDP Capability Negotiation currently defines the "creq" attribute as follows:

<quote>
   The Required Capability Negotiation Extensions attribute ("a=creq")
   contains a comma-separated list of option tags (see Section 3.3.1. )
   identifying the SDP Capability negotiation extensions that MUST be
   supported by the entity receiving the SDP in order for that entity to
   properly process the SDP Capability Negotiation attributes and
   associated procedures. Support for the basic negotiation framework is
   implied by the presence of an "a=pcfg" attribute (see Section 3.5.1.
   ) and hence there is no need to include the "a=creq" attribute with
   the base option-tag ("cap-v0"). Still, it is allowed to do so. 
</quote>

Jonathan Rosenberg raised the question whether 3PCC can wreak havoc with the above scheme of inferring support for the basic SDP Capability Negotiation framework by looking for "pcfg" attributes, as opposed to explicitly including the "creq" attribute with the base option-tag.

The design team discussed this issue in Prague and didn't see how inclusion of the "creq" attribute-tag with a base option-tag would be any better than just looking for "pcfg" attributes. In the absence of Jonathan pointing out any specific problems with the above scheme, it will stay as-is.

If you disagree with this, please let me know.

Thanks

-- Flemming




--------------090702040505080106080307-- --===============0706213691== 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 --===============0706213691==-- From mmusic-bounces@ietf.org Mon Jun 25 13:14:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s9M-0000Gh-WE; Mon, 25 Jun 2007 13:14:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s9K-0008HY-TR for mmusic@ietf.org; Mon, 25 Jun 2007 13:14:50 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2s9K-0000r4-Hf for mmusic@ietf.org; Mon, 25 Jun 2007 13:14:50 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2007 10:14:50 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208,217"; a="171682111:sNHT72981936" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5PHEosV027668 for ; Mon, 25 Jun 2007 10:14:50 -0700 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 l5PHEfw3000760 for ; Mon, 25 Jun 2007 17:14:49 GMT 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, 25 Jun 2007 10:14:44 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:14:43 -0700 Message-ID: <467FF802.9050909@cisco.com> Date: Mon, 25 Jun 2007 13:14:42 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 25 Jun 2007 17:14:44.0057 (UTC) FILETIME=[52F58C90:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3471; t=1182791690; x=1183655690; 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:=20SDPCapNeg=20Issue=20#5=3A=20Media=20before=20answer |Sender:=20; bh=afET/iuWrbKOdgYfTmW4RupQ4/B8ohVBqgCQRLmk/UA=; b=PG4qXF5bxi0XaGoVuJX1Ua5Z6X3RNwX+Jmxsi1JqEMBagd5YL8kWGR5hDHBoboDI3qF11+Fy d1gkg75sdxyMmFB5vnJ82OxUVp/5PxjLQBGU7kDUy4kux64CJg1F2Uh/EfulXhXbNHFdOx81vZ 1eZGCNEiAKSJXlY0OqXAzcF/w=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer 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="===============0226123034==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0226123034== Content-Type: multipart/alternative; boundary="------------000505040401090607060408" This is a multi-part message in MIME format. --------------000505040401090607060408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The answerer may select a potential configuration containing parameters that require the offerer to receive the answer before he can process media correctly. The issue is explained in Section 3.8 in the SDP Capability Negotiation framework, where one possible solutions is outlined (preconditions), but not actually specified. The question was raised whether we want to say more about this issue and if we want to define additional solutions to it. For example, Jonathan Rosenberg suggested that use of ICE can help the answerer determine when the answer has been received by the offerer and hence it is safe to send media to the offerer. The design team discussed this issue in Prague and agreed to elaborate slightly on the current text. It will be noted that the offerer can discard media until he receives the answer, if he wants to make sure he doesn't play garbage. If the offerer wants to avoid clipping on the other hand, he can play media as soon as it is received, but at the risk of playing garbage. To avoid both, a three-way handshake is needed (e.g. precondtion), however that is outside the basic SDP Capability Negotiation. We will add a note to mention the use of ICE (STUN) as a possible solution to this three-way handshake as well. If you disagree with this, please let me know. Thanks -- Flemming --------------000505040401090607060408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The answerer may select a potential configuration containing parameters that require the offerer to receive the answer before he can process media correctly. The issue is explained in Section 3.8 in the SDP Capability Negotiation framework, where one possible solutions is outlined (preconditions), but not actually specified. The question was raised whether we want to say more about this issue and if we want to define additional solutions to it. For example, Jonathan Rosenberg suggested that use of ICE can help the answerer determine when the answer has been received by the offerer and hence it is safe to send media to the offerer.

The design team discussed this issue in Prague and agreed to elaborate slightly on the current text. It will be noted that the offerer can discard media until he receives the answer, if he wants to make sure he doesn't play garbage. If the offerer wants to avoid clipping on the other hand, he can play media as soon as it is received, but at the risk of playing garbage. To avoid both, a three-way handshake is needed (e.g. precondtion), however that is outside the basic SDP Capability Negotiation. We will add a note to mention the use of ICE (STUN) as a possible solution to this three-way handshake as well.

If you disagree with this, please let me know.

Thanks

-- Flemming




--------------000505040401090607060408-- --===============0226123034== 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 --===============0226123034==-- From mmusic-bounces@ietf.org Mon Jun 25 13:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s9m-0002dm-DI; Mon, 25 Jun 2007 13:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s9k-0002P5-7r for mmusic@ietf.org; Mon, 25 Jun 2007 13:15:16 -0400 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 1I2s9i-0000uB-KT for mmusic@ietf.org; Mon, 25 Jun 2007 13:15:16 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2007 10:15:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8/AAWVf0arR7O6h2dsb2JhbACCKzaFcINegm8BAQkOLJpW X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208,217"; a="381654141:sNHT170950878" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5PHFDC5027620 for ; Mon, 25 Jun 2007 10:15:13 -0700 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 l5PHEwGw000686 for ; Mon, 25 Jun 2007 17:15:13 GMT 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, 25 Jun 2007 10:15:04 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:15:03 -0700 Message-ID: <467FF816.8080908@cisco.com> Date: Mon, 25 Jun 2007 13:15:02 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 25 Jun 2007 17:15:04.0041 (UTC) FILETIME=[5EDEDD90:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6766; t=1182791713; x=1183655713; 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:=20SDPCapNeg=20Issue=20#6=3A=20Second=20Offer/Answer=20exchange |Sender:=20; bh=5U3e/7Ux5RMOcbu8L7dDD+kSB/z3HMLAzoL5R3r7jng=; b=1oeJCQKrQe1i+tE9HpivC3JLbzY5bv03WqA9aczcTu0z+gPQ39cgwO8untdheRGSPi8P4shx 1FZmMwyqAe2CgSFmY6JENE1ErsPni98aFVO/gFG3VHFLVaBJuM1GS2eD; 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: 29dc808194f5fb921c09d0040806d6eb Subject: [MMUSIC] SDPCapNeg Issue #6: Second Offer/Answer exchange 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="===============0431812612==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0431812612== Content-Type: multipart/alternative; boundary="------------030506030700070309070502" This is a multi-part message in MIME format. --------------030506030700070309070502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The SDP Capability Negotiation framework currently specifies the following operation when the offerer receives the answer: If the offer/answer exchange was successful, and if the answerer selected one of the potential configurations from the offer as the actual configuration, then the offerer MAY 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. If it is known or suspected that one or more such intermediaries exist, then this second offer/answer SHOULD be performed (this is already done when using Interactive Connectivity Establishment [ICE]). ICE has this second offer/answer exchange at MUST strenght, and hence the question was raised whether this second offer/answer exchange should be at MAY, SHOULD, or MUST strength. Francois Audet was against having this second exchange at MUST strength, but is OK with the current text. Since there were no objections to the current text/recommendation otherwise, it will stay as-is. A problem scenario was brougth up though: 1) Offerer generates an offer SDP with the actual configuration specifying a low-bandwidht configuration, and a potential configuration specifying a high(er) bandwidth configuration. 2) A middle-box (e.g. P-CSCF or SBC) that is SDPCapNeg unaware authorizes the session based on the actual configuration. 3) The answerer chooses the high(er) bandwidth configuration and generates an answer accordingly. 4) Middle-box passes through the answer 5) Offerer now generates a second O/A exchange as a courtesy to any middle-box, which specifies the high(er) bandwidth configuration that was chosen. 6) Middle-box sees the second O/A exchange, does not want to authorize use of the QoS required and hence rejects it. 7) Offerer receives the rejected offer. After step 7, per RFC 3264, the original (completed) O/A exchange remains in effect, however since the middle-box has not authorized the QoS, quality may suffer. There is not a lot we can (or will) do about this issue in the base SDP Capability Negotiation framework, however the document will elaborate on the issue per the above example and explain why an SBC, P-CSCF, etc. should understand the capability negotiation framework (so it can authorize correctly in the first place). If you disagree with this, please let me know. Thanks -- Flemming --------------030506030700070309070502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The SDP Capability Negotiation framework currently specifies the following operation when the offerer receives the answer:

<quote>
   If the offer/answer exchange was successful, and if the answerer
   selected one of the potential configurations from the offer as the
   actual configuration, then the offerer MAY 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. If it is known or suspected that one or
   more such intermediaries exist, then this second offer/answer SHOULD
   be performed (this is already done when using Interactive
   Connectivity Establishment [ICE]).
</quote>

ICE has this second offer/answer exchange at MUST strenght, and hence the question was raised whether this second offer/answer exchange should be at MAY, SHOULD, or MUST strength. Francois Audet was against having this second exchange at MUST strength, but is OK with the current text. Since there were no objections to the current text/recommendation otherwise, it will stay as-is.


A problem scenario was brougth up though:
1) Offerer generates an offer SDP with the actual configuration specifying a low-bandwidht configuration, and a potential configuration specifying a high(er) bandwidth configuration.
2) A middle-box (e.g. P-CSCF or SBC) that is SDPCapNeg unaware authorizes the session based on the actual configuration.
3) The answerer chooses the high(er) bandwidth configuration and generates an answer accordingly.
4) Middle-box passes through the answer
5) Offerer now generates a second O/A exchange as a courtesy to any middle-box, which specifies the high(er) bandwidth configuration that was chosen.
6) Middle-box sees the second O/A exchange, does not want to authorize use of the QoS required and hence rejects it.
7) Offerer receives the rejected offer.

After step 7, per RFC 3264, the original (completed) O/A exchange remains in effect, however since the middle-box has not authorized the QoS, quality may suffer.

There is not a lot we can (or will) do about this issue in the base SDP Capability Negotiation framework, however the document will elaborate on the issue per the above example and explain why an SBC, P-CSCF, etc. should understand the capability negotiation framework (so it can authorize correctly in the first place).

If you disagree with this, please let me know.

Thanks

-- Flemming


--------------030506030700070309070502-- --===============0431812612== 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 --===============0431812612==-- From mmusic-bounces@ietf.org Mon Jun 25 13:15:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s9p-0002ie-UB; Mon, 25 Jun 2007 13:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s9p-0002hE-Dy for mmusic@ietf.org; Mon, 25 Jun 2007 13:15:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2s9n-0000xy-3E for mmusic@ietf.org; Mon, 25 Jun 2007 13:15:21 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2007 10:15:18 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="171682528:sNHT44504613" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5PHFIeT028734; Mon, 25 Jun 2007 10:15:18 -0700 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 l5PHEwH2000686; Mon, 25 Jun 2007 17:15:17 GMT 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, 25 Jun 2007 10:15:16 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:15:15 -0700 Message-ID: <467FF822.3080109@cisco.com> Date: Mon, 25 Jun 2007 13:15:14 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic , "'Robert R. Gilman'" , "Even, Roni" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 17:15:15.0933 (UTC) FILETIME=[65F570D0:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1577; t=1182791718; x=1183655718; 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:=20SDPCapNeg=20Issue=20#7=3A=20Media-level=20attributes=20at=20t he=20session-level |Sender:=20; bh=2NCBfW8LQ3TSvcfL+Zi9/qnNrK0RxCzv4SIh+eE4/hw=; b=YWYfWzgF/aK2Ip4lnF7ZWJgdZVyF5ALNlondz2eZv2QuSyUMR9dI52txwqGQ4vbMTIDo+U5T mIILAVJ085hUyC6sdkm/+LIl5SSxq9HSwYBakP7b+jq4ZeEdorjZjLZm7WZa5Kqin4z7wjILKD 5hYJOFwX8/oi2jOZXYDqtUBO0=; 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [MMUSIC] SDPCapNeg Issue #7: Media-level attributes at the session-level 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 Currently, the SDP Capability Negotiation framework says that you MUST NOT provide a media-level attribute capability at the session-level. The reason for this is that use of an attribute capability in a potential configuration simply adds that attribute to the SDP at the level where the attribute was provided. Thus an attribute capability provided at the session-level would be added at the session-level, which would be incorrect for media-level attributes. Bob Gilman noted that while this is fine for the basic SDP Capability Negotiation framework, it is too restrictive for the media capabilities extensions, which needs to list latent media capabilities at the session level. The design team did not discuss this issue in Prague, however below is a suggested resolution for it: Instead of disallowing media-level attribute capabilities at the session-level we instead say that the base SDP Capability Negotiation framework allows use of media-level attribute capabilities at the media level only in a potential configuration, however extensions may modify this behavior, as long as it is fully backwards compatible with the base specification. Thus, media-level attribute capabilities can be provided at the session-level, however they cannot be used by a potential configuration that follows the base specification only. Session-level attribute capabilities can still only be provided at the session-level. Please let me know if you disagree with this or otherwise have any comments on this. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 25 13:15:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sAJ-0002tV-GI; Mon, 25 Jun 2007 13:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sAI-0002sp-Dt for mmusic@ietf.org; Mon, 25 Jun 2007 13:15:50 -0400 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 1I2sAH-0000zs-4n for mmusic@ietf.org; Mon, 25 Jun 2007 13:15:50 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2007 10:15:48 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="4733969:sNHT19206084" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5PHFmgw025248; Mon, 25 Jun 2007 10:15:48 -0700 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 l5PHFmvv001489; Mon, 25 Jun 2007 17:15:48 GMT 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, 25 Jun 2007 10:15:48 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:15:46 -0700 Message-ID: <467FF841.6060801@cisco.com> Date: Mon, 25 Jun 2007 13:15:45 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic , Jonathan Lennox Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 17:15:46.0918 (UTC) FILETIME=[786D6060:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=879; t=1182791748; x=1183655748; 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:=20SDPCapNeg=20Issue=20#8=3A=20Interaction=20between=20SIP=20opt ion=20tags=20and=20SDP=20CapNeg=0A=20extensions |Sender:=20; bh=rpmJkZXBzrjexYrPJyH+JhXjnXonshcOquCPAXNOrTs=; b=BlOLp89Z748z+MW+6M8+T+syZHvEyuKRASB9QMChhjxeFxLQ3BDAhim2GVpCswyXVc443Ftb 4E2hCwmYhkihISaCzBGIycM1Qoh89+YLbJODkCFI0DnBXENqJgnfu8fy; 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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [MMUSIC] SDPCapNeg Issue #8: Interaction between SIP option tags and SDP CapNeg extensions 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 Jonathan Lennox noted that a potential configuration could require use of some SDP extension, whereas another potential configuration might not. For SDP extensions that have a SIP option tag associated with them (e.g. like RFC 3312 preconditions), this implies that we cannot use a SIP Require header with that SIP option tag if we want the SDP capability negotiation scheme to support either of these potential configurations. The SDP Capability Negotiation framework currently has no way of addressing that. This issue was brought up in Prague where it was discussed briefly. The general feeling was that it is not something we can address in the SDP Capability Negotiation framework, however we should note the issue in the document. Please let me know if you disagree with this and/or have a suggestion for resolving it. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 25 13:16:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sAi-0003dE-EK; Mon, 25 Jun 2007 13:16:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sAg-0003XW-J0 for mmusic@ietf.org; Mon, 25 Jun 2007 13:16:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2sAg-00013G-8x for mmusic@ietf.org; Mon, 25 Jun 2007 13:16:14 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2007 10:16:13 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="171683154:sNHT50455692" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5PHGDJf029476; Mon, 25 Jun 2007 10:16:13 -0700 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 l5PHG9w7001866; Mon, 25 Jun 2007 17:16:13 GMT 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, 25 Jun 2007 10:16:09 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:16:09 -0700 Message-ID: <467FF858.6020503@cisco.com> Date: Mon, 25 Jun 2007 13:16:08 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic , Jonathan Lennox Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 17:16:09.0541 (UTC) FILETIME=[85E95F50:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2848; t=1182791773; x=1183655773; 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:=20SDPCapNeg=20Issue=20#9=3A=20Unknown=20attributes=20and=20pote ntial=20configuration=0A=20selection |Sender:=20; bh=d1sZZO4pcDOTbZ+hOEslKnP+CaqUMKsmGyZnxsduKYI=; b=kQVT5etnSu1+go8UuImjgzDmVFW9VvRHxmBxBog/m9GtUYNwEJfGq7/TQSRfzDKtImm2Tcnj IrLDFEJNYRGJWpcaRrr/QR1toJ5chwU14S4i+0t6j1G8f1D1PK2uxAGC; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes and potential configuration selection 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 Jonathan Lennox had noted that the current potential configurationa algorithm combined with the standard SDP rules of ignoring unknown attributes, may lead an answerer to select a potential configuration with attributes it does not support, when the intent was to actually have the answerer select a potential configuration with attributes the answerer does support. Clearly, this does not produce the desired outcome. The reason for this is that we still use the standard SDP rules where we ignore unknown SDP attributes. The design team did not get a chance to discuss this issue in Prague, however there seems to be a few possible solutions to this one: 1) Continue with the current scheme, but allow the answerer to select only a potential configuration if the potential configuration makes sense and can be supported. This would ensure that any attributes that are required in order for a potential configuration to be used would have to be supported by the answerer in order for him to select that. For example, if the media stream is for SRTP, and the potential configuration specifies use of the "crypto" attribute for keying material, which the answerer didn't support, the answerer would move on to the next potential configuration (which could use a different keying mechanism). 2) Require that all attributes used by a potential configuration MUST be supported by the answerer in order for that potential configuration to be valid (and hence be able to be selected). An attribute is supported if both the attribute type and its value can be supported. This raises some potential ambiguity with payload types for example, where an rtpmap is both understood and supported, but the actual codec is not. 3) As 2), however allow for individual attribute capabilities to be marked as "optional" in a potential configuration. If an "optional" attribute capability is not supported by the answerer, the potential configuration would still be considered valid. 4) Similar to 3), except the default would be "optional", and we can mark certain attributes as mandatory. Option 1 seems flaky and is not recommended. Option 2 is simple to specify and use, however, as noted, it is not clear it has sufficient flexibility The recommendation here is for either option 3 or 4, with the choice depending on whether you believe optional or mandatory attributes are the more common use cases for SDP Capability Negotiation. My preference is for option 4. Compared to option 3, this option aligns slightly better with standard SDP as well, inasmuch as the default operation is normal SDP, and any changes from that requires an explicit indication (mandatory attribute). Please let me know if you disagree or have any comments on this. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jun 25 13:18: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 1I2sD4-0007gD-1m; Mon, 25 Jun 2007 13:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sD2-0007g1-JI for mmusic@ietf.org; Mon, 25 Jun 2007 13:18:40 -0400 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 1I2sD2-0001as-AA for mmusic@ietf.org; Mon, 25 Jun 2007 13:18:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2007 10:18:39 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="4735156:sNHT18867084" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5PHIdJx003337 for ; Mon, 25 Jun 2007 10:18:39 -0700 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 l5PHIQwB003486 for ; Mon, 25 Jun 2007 17:18:39 GMT 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, 25 Jun 2007 10:18:35 -0700 Received: from [10.21.112.189] ([10.21.112.189]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:18:35 -0700 Message-ID: <467FF8EA.5020500@cisco.com> Date: Mon, 25 Jun 2007 13:18:34 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 17:18:35.0761 (UTC) FILETIME=[DD10C610:01C7B74C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=945; t=1182791919; x=1183655919; 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:=20SDPCapNeg=3A=20Few=20other=20items=20that=20were=20discussion =20in=20Prague |Sender:=20; bh=Tsw2iqSxv7bb0jhr/JNeEUhTaGU0z/ip8Pswk2HPIU8=; b=kJrqXxVDI2Os8avb/SBSgpu5EAR5K7/bZqV6MvJZS5Y04TwXWwwwLo1DnXEocB56o4+JcvIC n9rZsANbzDrnsNWyhQGMYwS0MLprRoWntzG/WeD4Hu3UrZh/6fckWdiC; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [MMUSIC] SDPCapNeg: Few other items that were discussion in Prague 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) Should we allow for one or more "tcap" (transport protocol capability) attributes at each of the the session-level and media-level ? Currently, we allow for more than one. Design team consensus was to allow for only one. B) Do we need to say more about their syntax and semantics that we currently do, and if so what ? Desing team consensus was that current text is sufficient. C) Rename the "tcap" attribute ? It was suggested to rename the "tcap" attribute to something else to avoid confusing the SS7 crowd. Design team consensus was that we wanted the structure of all the capabilities to be similar (same number of letters). If we were to rename it to say "tpcap", this would require renaming the "acap" attribute as well. Based on this and to minimize churn, the design team decided to keep the current "tcap" name as-is. Please let me know if you disagree with any of the above. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 26 11:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CvR-0000La-SU; Tue, 26 Jun 2007 11:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CvQ-0000Kg-DE for mmusic@ietf.org; Tue, 26 Jun 2007 11:25:52 -0400 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 1I3CvM-0003lm-2B for mmusic@ietf.org; Tue, 26 Jun 2007 11:25:52 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 26 Jun 2007 08:25:47 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAK/MgEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,464,1175497200"; d="scan'208"; a="497777980:sNHT34507418" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5QFPlCY005490; Tue, 26 Jun 2007 08:25:47 -0700 Received: from dwingwxp (sjc-vpn6-185.cisco.com [10.21.120.185]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5QFPkGX023958; Tue, 26 Jun 2007 15:25:46 GMT From: "Dan Wing" To: "'Flemming Andreasen'" , "'mmusic'" Subject: RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer Date: Tue, 26 Jun 2007 08:25:45 -0700 Message-ID: <00c301c7b806$44dd0b00$b978150a@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.3138 In-Reply-To: <467FF802.9050909@cisco.com> Thread-Index: Ace3TFqsc+f0k6bbT2u+Sb26Evv/dwAaLDlg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2010; t=1182871547; x=1183735547; c=relaxed/simple; s=sjdkim2002; 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]=20SDPCapNeg=20Issue=20#5=3A=20Media=20before =20answer |Sender:=20; bh=bqJZdNYUzjQRP1z2MGYUklX+bdBc48P3BaxZ6EOk90c=; b=zf4RcgdkJJUoioVmGMivpJoRR6w3qF3bwtsoK7U007b4G130DeiS35QBQCZo/mJ2ffSFOZwd MjHykrHuN8ST3shGLklus5ivGeFnZ6CLTk4vjzti7ynzHBs5mnbWQwM3; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Was the use of a payload type for this, as mentioned in draft-kaplan-mmusic-best-effort-srtp-01, considered and discarded? I'm fine if it was, I'm just asking. It seemed useful although it only increases the chances of not playing garbage (because you don't know until you get the answer if the answerer understood that technique). -d > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Monday, June 25, 2007 10:15 AM > To: mmusic > Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer > > The answerer may select a potential configuration containing > parameters that require the offerer to receive the answer > before he can process media correctly. The issue is explained > in Section 3.8 in the SDP Capability Negotiation framework, > where one possible solutions is outlined (preconditions), but > not actually specified. The question was raised whether we > want to say more about this issue and if we want to define > additional solutions to it. For example, Jonathan Rosenberg > suggested that use of ICE can help the answerer determine > when the answer has been received by the offerer and hence it > is safe to send media to the offerer. > > The design team discussed this issue in Prague and agreed to > elaborate slightly on the current text. It will be noted that > the offerer can discard media until he receives the answer, > if he wants to make sure he doesn't play garbage. If the > offerer wants to avoid clipping on the other hand, he can > play media as soon as it is received, but at the risk of > playing garbage. To avoid both, a three-way handshake is > needed (e.g. precondtion), however that is outside the basic > SDP Capability Negotiation. We will add a note to mention the > use of ICE (STUN) as a possible solution to this three-way > handshake as well. > > If you disagree with this, please let me know. > > Thanks > > -- Flemming > > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jun 26 11:36:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3D5v-0002P2-1F; Tue, 26 Jun 2007 11:36:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3D5t-0002M4-Jn for mmusic@ietf.org; Tue, 26 Jun 2007 11:36:41 -0400 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 1I3D59-0006g4-N7 for mmusic@ietf.org; Tue, 26 Jun 2007 11:36:41 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 26 Jun 2007 08:35:54 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkdhAPTOgEarR7MV/2dsb2JhbACCMTaFcYNenXQ X-IronPort-AV: i="4.16,464,1175497200"; d="scan'208,217"; a="497781227:sNHT265542824" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5QFZsn3025137 for ; Tue, 26 Jun 2007 08:35:54 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5QFZomq007615 for ; Tue, 26 Jun 2007 15:35:54 GMT 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); Tue, 26 Jun 2007 08:35:50 -0700 Received: from [10.21.117.84] ([10.21.117.84]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 08:35:49 -0700 Message-ID: <46813243.6090807@cisco.com> Date: Tue, 26 Jun 2007 11:35:31 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer References: <00c301c7b806$44dd0b00$b978150a@amer.cisco.com> In-Reply-To: <00c301c7b806$44dd0b00$b978150a@amer.cisco.com> X-OriginalArrivalTime: 26 Jun 2007 15:35:50.0293 (UTC) FILETIME=[AC92C450:01C7B807] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5192; t=1182872154; x=1183736154; 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]=20SDPCapNeg=20Issue=20#5=3A=20Media=20before =20answer |Sender:=20; bh=UVSdmWUr0Yzbz1Sqk2gPgP3rDvgaVRemOmFbLLJBweM=; b=miaD/pIn10Eh91FG6Ujz7Av53tllJCPquKwRb97rm/nRXJZRqsabsGwnUWYajHA0Iy9CWtIa pxHOiZCd9fBQZI6Ff70buwAlBNFAS0vzCvjNBiauO43DUPYv1vbr4KZAr50xOpdfQS9gdoXzsY iVccBWPNVo06UztjLP7aS0wjM=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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="===============1774353638==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1774353638== Content-Type: multipart/alternative; boundary="------------080102070701000109060309" This is a multi-part message in MIME format. --------------080102070701000109060309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan Wing wrote: > Was the use of a payload type for this, as mentioned in > draft-kaplan-mmusic-best-effort-srtp-01, considered and discarded? I'm fine > if it was, I'm just asking. It seemed useful although it only increases the > chances of not playing garbage (because you don't know until you get the > answer if the answerer understood that technique). > It's mentioned as one possible approach in Section 3.8 (but not mandated). -- Flemming > -d > > >> -----Original Message----- >> From: Flemming Andreasen [mailto:fandreas@cisco.com] >> Sent: Monday, June 25, 2007 10:15 AM >> To: mmusic >> Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer >> >> The answerer may select a potential configuration containing >> parameters that require the offerer to receive the answer >> before he can process media correctly. The issue is explained >> in Section 3.8 in the SDP Capability Negotiation framework, >> where one possible solutions is outlined (preconditions), but >> not actually specified. The question was raised whether we >> want to say more about this issue and if we want to define >> additional solutions to it. For example, Jonathan Rosenberg >> suggested that use of ICE can help the answerer determine >> when the answer has been received by the offerer and hence it >> is safe to send media to the offerer. >> >> The design team discussed this issue in Prague and agreed to >> elaborate slightly on the current text. It will be noted that >> the offerer can discard media until he receives the answer, >> if he wants to make sure he doesn't play garbage. If the >> offerer wants to avoid clipping on the other hand, he can >> play media as soon as it is received, but at the risk of >> playing garbage. To avoid both, a three-way handshake is >> needed (e.g. precondtion), however that is outside the basic >> SDP Capability Negotiation. We will add a note to mention the >> use of ICE (STUN) as a possible solution to this three-way >> handshake as well. >> >> If you disagree with this, please let me know. >> >> Thanks >> >> -- Flemming >> >> >> >> >> >> >> > > --------------080102070701000109060309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Dan Wing wrote: 
Was the use of a payload type for this, as mentioned in
draft-kaplan-mmusic-best-effort-srtp-01, considered and discarded?  I'm fine
if it was, I'm just asking.  It seemed useful although it only increases the
chances of not playing garbage (because you don't know until you get the
answer if the answerer understood that technique).
It's mentioned as one possible approach in Section 3.8 (but not mandated).

-- Flemming 
-d

  
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: Monday, June 25, 2007 10:15 AM
To: mmusic
Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer

The answerer may select a potential configuration containing 
parameters that require the offerer to receive the answer 
before he can process media correctly. The issue is explained 
in Section 3.8 in the SDP Capability Negotiation framework, 
where one possible solutions is outlined (preconditions), but 
not actually specified. The question was raised whether we 
want to say more about this issue and if we want to define 
additional solutions to it. For example, Jonathan Rosenberg 
suggested that use of ICE can help the answerer determine 
when the answer has been received by the offerer and hence it 
is safe to send media to the offerer. 

The design team discussed this issue in Prague and agreed to 
elaborate slightly on the current text. It will be noted that 
the offerer can discard media until he receives the answer, 
if he wants to make sure he doesn't play garbage. If the 
offerer wants to avoid clipping on the other hand, he can 
play media as soon as it is received, but at the risk of 
playing garbage. To avoid both, a three-way handshake is 
needed (e.g. precondtion), however that is outside the basic 
SDP Capability Negotiation. We will add a note to mention the 
use of ICE (STUN) as a possible solution to this three-way 
handshake as well. 

If you disagree with this, please let me know. 

Thanks

-- Flemming
--------------080102070701000109060309-- --===============1774353638== 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 --===============1774353638==-- From mmusic-bounces@ietf.org Tue Jun 26 17:55:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3J0b-0002Ih-Qm; Tue, 26 Jun 2007 17:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3J0a-0002Ib-MG for mmusic@ietf.org; Tue, 26 Jun 2007 17:55:36 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Izx-0001yv-1s for mmusic@ietf.org; Tue, 26 Jun 2007 17:55:36 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l5QLrTb26426; Tue, 26 Jun 2007 21:53:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer Date: Tue, 26 Jun 2007 16:54:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF110A9241@zrc2hxm0.corp.nortel.com> In-Reply-To: <46813243.6090807@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg Issue #5: Media before answer Thread-Index: Ace4B9OJ+PBjdW8bSJ2X6plPLzd09AAM/ibQ References: <00c301c7b806$44dd0b00$b978150a@amer.cisco.com> <46813243.6090807@cisco.com> From: "Francois Audet" To: "Flemming Andreasen" , "Dan Wing" X-Spam-Score: 0.1 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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="===============1004411710==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1004411710== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B83C.A01B5786" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B83C.A01B5786 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The preconditions approach to me seems like the least likely approach to be used in the real world. =20 I really see only two practical way forward: 1.=09 You have to wait for the answer before playing anything. For this to work, we'd effectively have to rely on provisional responses including the SDP-answer (and not include the answer in the 200, since it would cause clipping). That in itself would be a change for many SIP clients who never tought it necessary to provide an answer before 200 before (at least, they didn't think they needed it). 2.=09 Use the different payload type as per our kaplan draft. My take is that option 1 is the more likely to have wide support. But we should explain it a bit. =20 Option 2 is interesting, in a geeky way, and probaly better than pre-conditions. But if people can live with 1, it seems much simpler. =20 My 2 cents. =20 ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: Tuesday, June 26, 2007 08:36 To: Dan Wing Cc: 'mmusic' Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer =09 =09 Dan Wing wrote:=20 Was the use of a payload type for this, as mentioned in draft-kaplan-mmusic-best-effort-srtp-01, considered and discarded? I'm fine if it was, I'm just asking. It seemed useful although it only increases the chances of not playing garbage (because you don't know until you get the answer if the answerer understood that technique). =20 It's mentioned as one possible approach in Section 3.8 (but not mandated).=20 =09 -- Flemming=20 =09 -d =09 =20 -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: Monday, June 25, 2007 10:15 AM To: mmusic Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer =09 The answerer may select a potential configuration containing=20 parameters that require the offerer to receive the answer=20 before he can process media correctly. The issue is explained=20 in Section 3.8 in the SDP Capability Negotiation framework,=20 where one possible solutions is outlined (preconditions), but=20 not actually specified. The question was raised whether we=20 want to say more about this issue and if we want to define=20 additional solutions to it. For example, Jonathan Rosenberg=20 suggested that use of ICE can help the answerer determine=20 when the answer has been received by the offerer and hence it=20 is safe to send media to the offerer.=20 =09 The design team discussed this issue in Prague and agreed to=20 elaborate slightly on the current text. It will be noted that=20 the offerer can discard media until he receives the answer,=20 if he wants to make sure he doesn't play garbage. If the=20 offerer wants to avoid clipping on the other hand, he can=20 play media as soon as it is received, but at the risk of=20 playing garbage. To avoid both, a three-way handshake is=20 needed (e.g. precondtion), however that is outside the basic=20 SDP Capability Negotiation. We will add a note to mention the=20 use of ICE (STUN) as a possible solution to this three-way=20 handshake as well.=20 =09 If you disagree with this, please let me know.=20 =09 Thanks =09 -- Flemming=20 =09 =09 =09 =09 =09 =09 =20 =09 =20 ------_=_NextPart_001_01C7B83C.A01B5786 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The preconditions approach to me seems like = the least=20 likely approach to be used in the real world.
 
I really see only two practical way=20 forward:
  1. You have to wait for the answer before = playing=20 anything. For this to work, we'd effectively have to rely on = provisional=20 responses including the SDP-answer (and not include the answer in the = 200,=20 since it would cause clipping). That in itself would be a change for = many SIP=20 clients who never tought it necessary to provide an answer before 200 = before=20 (at least, they didn't think they needed it).
  2. Use the different payload type as per our = kaplan=20 draft.
My=20 take is that option 1 is the more likely to have wide support. But we = should=20 explain it a bit.
 
Option=20 2 is interesting, in a geeky way, and probaly better than = pre-conditions. But if=20 people can live with 1, it seems much simpler.
 
My 2=20 cents.

 
From: Flemming Andreasen=20 [mailto:fandreas@cisco.com]
Sent: Tuesday, June 26, 2007=20 08:36
To: Dan Wing
Cc: 'mmusic'
Subject: = Re:=20 [MMUSIC] SDPCapNeg Issue #5: Media before answer



Dan Wing wrote:=20 
Was the use of a payload type for this, as =
mentioned in
draft-kaplan-mmusic-best-effort-srtp-01, considered and discarded?  I'm =
fine
if it was, I'm just asking.  It seemed useful although it only increases =
the
chances of not playing garbage (because you don't know until you get the
answer if the answerer understood that technique).
It's mentioned as one possible approach in Section = 3.8=20 (but not mandated).

-- Flemming 
-d

  
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]=20
Sent: Monday, June 25, 2007 10:15 AM
To: mmusic
Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer

The answerer may select a potential configuration containing=20
parameters that require the offerer to receive the answer=20
before he can process media correctly. The issue is explained=20
in Section 3.8 in the SDP Capability Negotiation framework,=20
where one possible solutions is outlined (preconditions), but=20
not actually specified. The question was raised whether we=20
want to say more about this issue and if we want to define=20
additional solutions to it. For example, Jonathan Rosenberg=20
suggested that use of ICE can help the answerer determine=20
when the answer has been received by the offerer and hence it=20
is safe to send media to the offerer.=20

The design team discussed this issue in Prague and agreed to=20
elaborate slightly on the current text. It will be noted that=20
the offerer can discard media until he receives the answer,=20
if he wants to make sure he doesn't play garbage. If the=20
offerer wants to avoid clipping on the other hand, he can=20
play media as soon as it is received, but at the risk of=20
playing garbage. To avoid both, a three-way handshake is=20
needed (e.g. precondtion), however that is outside the basic=20
SDP Capability Negotiation. We will add a note to mention the=20
use of ICE (STUN) as a possible solution to this three-way=20
handshake as well.=20

If you disagree with this, please let me know.=20

Thanks

-- Flemming=20
------_=_NextPart_001_01C7B83C.A01B5786-- --===============1004411710== 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 --===============1004411710==-- From mmusic-bounces@ietf.org Tue Jun 26 18:28:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3JWC-0002i7-Mj; Tue, 26 Jun 2007 18:28:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3JWB-0002dn-W6 for mmusic@ietf.org; Tue, 26 Jun 2007 18:28:15 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3JVF-0006CI-HF for mmusic@ietf.org; Tue, 26 Jun 2007 18:28:15 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Jun 2007 15:22:39 -0700 X-IronPort-AV: i="4.16,464,1175497200"; d="scan'208,217"; a="172606631:sNHT1264167225" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5QMMd4G005627; Tue, 26 Jun 2007 15:22:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5QMMcXJ026795; Tue, 26 Jun 2007 22:22:39 GMT 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); Tue, 26 Jun 2007 15:22:38 -0700 Received: from [10.21.95.123] ([10.21.95.123]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 15:22:30 -0700 Message-ID: <46819193.3070109@cisco.com> Date: Tue, 26 Jun 2007 18:22:11 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Francois Audet Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer References: <00c301c7b806$44dd0b00$b978150a@amer.cisco.com> <46813243.6090807@cisco.com> <1ECE0EB50388174790F9694F77522CCF110A9241@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF110A9241@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 26 Jun 2007 22:22:31.0153 (UTC) FILETIME=[7C9E8610:01C7B840] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10685; t=1182896559; x=1183760559; 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:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#5=3A=20Media=20before =20answer |Sender:=20; bh=LRllu0qMNyxr5a4nWAY/swDKyMK712lVSUvOiljAv6Q=; b=DxJjam4GrkQAsAra76/B+3le2emujCUDHq59PlBrd7X7toZtzkyhQOE4k/80bpC1rr3w5ypD K5rLS2Frij96YmSXKWBW4teokpMNKPf/3et0t1wicZbJRZucbkR6ioV5; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: mmusic , Dan Wing 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="===============0312888283==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0312888283== Content-Type: multipart/alternative; boundary="------------000208040607030405080101" This is a multi-part message in MIME format. --------------000208040607030405080101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Francois Audet wrote: > The preconditions approach to me seems like the least likely approach > to be used in the real world. > > I really see only two practical way forward: > > 1. > You have to wait for the answer before playing anything. For > this to work, we'd effectively have to rely on provisional > responses including the SDP-answer (and not include the answer > in the 200, since it would cause clipping). That in itself would > be a change for many SIP clients who never tought it necessary > to provide an answer before 200 before (at least, they didn't > think they needed it). > You'd have to include the answer in both the provisional response and the 200, unless you use reliable provisional responses. > 1. > Use the different payload type as per our kaplan draft. > > My take is that option 1 is the more likely to have wide support. But > we should explain it a bit. > Option 2 is interesting, in a geeky way, and probaly better than > pre-conditions. But if people can live with 1, it seems much simpler. I'll include an explanation of all of them (there's already some text on the above, however I'll elaborate on the points you made). -- Flemming > > My 2 cents. > > > > ------------------------------------------------------------------------ > *From:* Flemming Andreasen [mailto:fandreas@cisco.com] > *Sent:* Tuesday, June 26, 2007 08:36 > *To:* Dan Wing > *Cc:* 'mmusic' > *Subject:* Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer > > > > Dan Wing wrote: >> Was the use of a payload type for this, as mentioned in >> draft-kaplan-mmusic-best-effort-srtp-01, considered and discarded? I'm fine >> if it was, I'm just asking. It seemed useful although it only increases the >> chances of not playing garbage (because you don't know until you get the >> answer if the answerer understood that technique). >> > It's mentioned as one possible approach in Section 3.8 (but not > mandated). > > -- Flemming >> -d >> >> >>> -----Original Message----- >>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>> Sent: Monday, June 25, 2007 10:15 AM >>> To: mmusic >>> Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer >>> >>> The answerer may select a potential configuration containing >>> parameters that require the offerer to receive the answer >>> before he can process media correctly. The issue is explained >>> in Section 3.8 in the SDP Capability Negotiation framework, >>> where one possible solutions is outlined (preconditions), but >>> not actually specified. The question was raised whether we >>> want to say more about this issue and if we want to define >>> additional solutions to it. For example, Jonathan Rosenberg >>> suggested that use of ICE can help the answerer determine >>> when the answer has been received by the offerer and hence it >>> is safe to send media to the offerer. >>> >>> The design team discussed this issue in Prague and agreed to >>> elaborate slightly on the current text. It will be noted that >>> the offerer can discard media until he receives the answer, >>> if he wants to make sure he doesn't play garbage. If the >>> offerer wants to avoid clipping on the other hand, he can >>> play media as soon as it is received, but at the risk of >>> playing garbage. To avoid both, a three-way handshake is >>> needed (e.g. precondtion), however that is outside the basic >>> SDP Capability Negotiation. We will add a note to mention the >>> use of ICE (STUN) as a possible solution to this three-way >>> handshake as well. >>> >>> If you disagree with this, please let me know. >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>> >>> >>> >>> >>> >> >> > --------------000208040607030405080101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Francois Audet wrote:
The preconditions approach to me seems like the least likely approach to be used in the real world.
 
I really see only two practical way forward:
  1. You have to wait for the answer before playing anything. For this to work, we'd effectively have to rely on provisional responses including the SDP-answer (and not include the answer in the 200, since it would cause clipping). That in itself would be a change for many SIP clients who never tought it necessary to provide an answer before 200 before (at least, they didn't think they needed it).
You'd have to include the answer in both the provisional response and the 200, unless you use reliable provisional responses.

  1. Use the different payload type as per our kaplan draft.
My take is that option 1 is the more likely to have wide support. But we should explain it a bit.
Option 2 is interesting, in a geeky way, and probaly better than pre-conditions. But if people can live with 1, it seems much simpler.
I'll include an explanation of all of them (there's already some text on the above, however I'll elaborate on the points you made).

-- Flemming


 
My 2 cents.

 
From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Tuesday, June 26, 2007 08:36
To: Dan Wing
Cc: 'mmusic'
Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer



Dan Wing wrote: 
Was the use of a payload type for this, as mentioned in
draft-kaplan-mmusic-best-effort-srtp-01, considered and discarded?  I'm fine
if it was, I'm just asking.  It seemed useful although it only increases the
chances of not playing garbage (because you don't know until you get the
answer if the answerer understood that technique).
It's mentioned as one possible approach in Section 3.8 (but not mandated).

-- Flemming 
-d

  
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: Monday, June 25, 2007 10:15 AM
To: mmusic
Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer

The answerer may select a potential configuration containing 
parameters that require the offerer to receive the answer 
before he can process media correctly. The issue is explained 
in Section 3.8 in the SDP Capability Negotiation framework, 
where one possible solutions is outlined (preconditions), but 
not actually specified. The question was raised whether we 
want to say more about this issue and if we want to define 
additional solutions to it. For example, Jonathan Rosenberg 
suggested that use of ICE can help the answerer determine 
when the answer has been received by the offerer and hence it 
is safe to send media to the offerer. 

The design team discussed this issue in Prague and agreed to 
elaborate slightly on the current text. It will be noted that 
the offerer can discard media until he receives the answer, 
if he wants to make sure he doesn't play garbage. If the 
offerer wants to avoid clipping on the other hand, he can 
play media as soon as it is received, but at the risk of 
playing garbage. To avoid both, a three-way handshake is 
needed (e.g. precondtion), however that is outside the basic 
SDP Capability Negotiation. We will add a note to mention the 
use of ICE (STUN) as a possible solution to this three-way 
handshake as well. 

If you disagree with this, please let me know. 

Thanks

-- Flemming
--------------000208040607030405080101-- --===============0312888283== 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 --===============0312888283==-- From mmusic-bounces@ietf.org Tue Jun 26 18:50:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Jrs-0002bv-95; Tue, 26 Jun 2007 18:50:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Jrl-0002G5-5F; Tue, 26 Jun 2007 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3Jrk-0004Ew-U2; Tue, 26 Jun 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9F711175D0; Tue, 26 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3JrG-0001Q4-4I; Tue, 26 Jun 2007 18:50:02 -0400 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, 26 Jun 2007 18:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-15.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 : Real Time Streaming Protocol 2.0 (RTSP) Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-mmusic-rfc2326bis-15.txt Pages : 215 Date : 2007-6-26 This memorandum defines RTSP version 2.0 which is a revision of the Proposed Standard RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-15.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-rfc2326bis-15.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-rfc2326bis-15.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-6-26165434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-26165434.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 Tue Jun 26 20:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3LC0-0007Dp-AL; Tue, 26 Jun 2007 20:15:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3LBy-0007De-FH for mmusic@ietf.org; Tue, 26 Jun 2007 20:15:30 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3LBy-0002Iq-51 for mmusic@ietf.org; Tue, 26 Jun 2007 20:15:30 -0400 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 l5R0Efh17791; Wed, 27 Jun 2007 00:14:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer Date: Tue, 26 Jun 2007 19:14:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF110A93D9@zrc2hxm0.corp.nortel.com> In-Reply-To: <46819193.3070109@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg Issue #5: Media before answer Thread-Index: Ace4QKvl7WYH0G4wQcCuL/W+/Q/BHwAD1dmg References: <00c301c7b806$44dd0b00$b978150a@amer.cisco.com> <46813243.6090807@cisco.com> <1ECE0EB50388174790F9694F77522CCF110A9241@zrc2hxm0.corp.nortel.com> <46819193.3070109@cisco.com> From: "Francois Audet" To: "Flemming Andreasen" X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: mmusic , Dan Wing 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="===============1697617509==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1697617509== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B850.1F12E438" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B850.1F12E438 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Francois Audet wrote:=20 The preconditions approach to me seems like the least likely approach to be used in the real world. =20 I really see only two practical way forward: 1.=09 You have to wait for the answer before playing anything. For this to work, we'd effectively have to rely on provisional responses including the SDP-answer (and not include the answer in the 200, since it would cause clipping). That in itself would be a change for many SIP clients who never tought it necessary to provide an answer before 200 before (at least, they didn't think they needed it). You'd have to include the answer in both the provisional response and the 200, unless you use reliable provisional responses.=20 =20 Yes, agreed. Both cases are valid.=20 1.=09 Use the different payload type as per our kaplan draft. My take is that option 1 is the more likely to have wide support. But we should explain it a bit.=20 =09 Option 2 is interesting, in a geeky way, and probaly better than pre-conditions. But if people can live with 1, it seems much simpler. I'll include an explanation of all of them (there's already some text on the above, however I'll elaborate on the points you made).=20 Excellent. Thanks.=20 ------_=_NextPart_001_01C7B850.1F12E438 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

Francois Audet=20 wrote:
The preconditions approach to me seems = like the=20 least likely approach to be used in the real = world.
 
I really see only two practical way=20 forward:
  1. You have to wait for the answer before = playing=20 anything. For this to work, we'd effectively have to rely on = provisional=20 responses including the SDP-answer (and not include the answer in = the 200,=20 since it would cause clipping). That in itself would be a change = for many=20 SIP clients who never tought it necessary to provide an answer = before 200=20 before (at least, they didn't think they needed=20 it).
You'd have to include the answer in both the provisional response = and the=20 200, unless you use reliable provisional responses. 
 
Yes, agreed. Both cases are = valid. 
  1. Use the different payload type as per = our kaplan=20 draft.
My=20 take is that option 1 is the more likely to have wide support. But = we should=20 explain it a bit.
Option 2 is interesting, in a geeky way, and probaly better = than=20 pre-conditions. But if people can live with 1, it seems much=20 simpler.
I'll include an explanation of all of them (there's = already some=20 text on the above, however I'll elaborate on the points you=20 made). 

 Excellent.=20 Thanks. 
------_=_NextPart_001_01C7B850.1F12E438-- --===============1697617509== 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 --===============1697617509==-- From mmusic-bounces@ietf.org Wed Jun 27 04:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3SeI-0000GQ-GW; Wed, 27 Jun 2007 04:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3SeH-0000GK-Qu for mmusic@ietf.org; Wed, 27 Jun 2007 04:13:13 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Sdf-0002vd-L0 for mmusic@ietf.org; Wed, 27 Jun 2007 04:13:13 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3313713CF81 for ; Wed, 27 Jun 2007 10:12:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: mmusic@ietf.org Message-Id: <62AFA1BE-91CA-4FFA-9349-7D09D3C7F47B@netlab.nec.de> References: From: Martin Stiemerling Subject: Fwd: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-15.txt Date: Wed, 27 Jun 2007 10:12:33 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e 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="===============0189390119==" Errors-To: mmusic-bounces@ietf.org --===============0189390119== Content-Type: multipart/alternative; boundary=Apple-Mail-46-613807384 --Apple-Mail-46-613807384 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, The new version of draft-ietf-mmusic-rfc2326bis is just an XML-lized version of draft-ietf-mmusic-rfc2326bis-14.txt. draft-ietf-mmusic-rfc2326bis-14.txt was using tex sources and the first step was to convert the old draft sources to the newer xml format used by xml2rfc. Magnus and me have done a check of this version, but it would be good if other people could also take a look, whether the -14 and -15 are the same in terms of contents of the draft. The formatting is definitely looking different and some tables are not that nicely formatted yet. If somebody has experience with larger tables (requiring the full page width) it would be nice if he or she contacts me directly. How we are going to proceed: As the draft is now in the new format, it is time to get to technical issues to solve. I think Magnus and me will drive the discussion on the list in the next days and weeks. Thanks, Martin Anfang der weitergeleiteten E-Mail: > Von: Internet-Drafts@ietf.org > Datum: 27. Juni 2007 00:50:02 MESZ > An: i-d-announce@ietf.org > Kopie: mmusic@ietf.org > Betreff: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-15.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 : Real Time Streaming Protocol 2.0 (RTSP) > Author(s) : H. Schulzrinne, et al. > Filename : draft-ietf-mmusic-rfc2326bis-15.txt > Pages : 215 > Date : 2007-6-26 > > This memorandum defines RTSP version 2.0 which is a revision of the > Proposed Standard RTSP version 1.0 which is defined in RFC 2326. > > The Real Time Streaming Protocol, or RTSP, is an application-level > protocol for control over the delivery of data with real-time > properties. RTSP provides an extensible framework to enable > controlled, on-demand delivery of real-time data, such as audio and > video. Sources of data can include both live data feeds and stored > clips. This protocol is intended to control multiple data delivery > sessions, provide a means for choosing delivery channels such as > UDP, > multicast UDP and TCP, and provide a means for choosing delivery > mechanisms based upon RTP (RFC 3550). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic- > rfc2326bis-15.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-rfc2326bis-15.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-rfc2326bis-15.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. > Content-Type: text/plain > Content-ID: <2007-6-26165434.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-15.txt > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-46-613807384 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

The new version = of=A0draft-ietf-mmusic-rfc2326bis is just an XML-lized version = of=A0draft-ietf-mmusic-rfc2326bis-14.txt.=A0

draft-ietf-mmusic-rfc2326bis-= 14.txt was using tex sources and the first step was to convert the old = draft sources to the newer xml format used by xml2rfc.

Magnus and me have done a = check of this version, but it would be good if other people could also = take a look, whether the -14 and -15 are the same in terms of contents = of the draft.

The formatting is = definitely looking different and some tables are not that nicely = formatted yet. If somebody has experience with larger tables (requiring = the full page width) it would be nice if he or she=A0contacts me = directly.

How = we are going to proceed: As the draft is now in the new format, it is = time to get to technical issues to solve. I think Magnus and me will = drive the discussion on the list in the next days and = weeks.

Thanks,=A0

=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Datum: 27. Juni 2007 00:50:02 = MESZ
An: i-d-announce@ietf.org
Betreff: = [MMUSIC] I-D = ACTION:draft-ietf-mmusic-rfc2326bis-15.txt=A0

A New = Internet-Draft is available from the on-line Internet-Drafts=A0
This draft is a work item of the = Multiparty Multimedia Session Control Working Group of the = IETF.

Title : Real Time Streaming Protocol = 2.0 (RTSP)
Author(s) : H. = Schulzrinne, et al.
= Filename = : draft-ietf-mmusic-rfc2326bis-15.txt
Pages : 215
Date : 2007-6-26


This = memorandum defines RTSP version 2.0 which is a revision of the
=A0=A0 = Proposed Standard RTSP version 1.0 which is defined in RFC = 2326.

=A0=A0 = The Real Time Streaming Protocol, or RTSP, is an = application-level
=A0=A0 protocol for control over = the delivery of data with real-time
=A0=A0 properties.=A0 RTSP provides an extensible = framework to enable
=A0=A0 controlled, on-demand = delivery of real-time data, such as audio and
=A0=A0 = video.=A0 Sources of = data can include both live data feeds and stored
=A0=A0 = clips.=A0 This = protocol is intended to control multiple data delivery
=A0=A0 = sessions, provide a means for choosing delivery channels such as = UDP,
=A0=A0 multicast UDP and TCP, and = provide a means for choosing delivery
=A0=A0 mechanisms based upon RTP = (RFC 3550).

A URL for this Internet-Draft is:

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-ietf-mmusic-rfc2326bis-15.txt".

A list of = Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-mmusic-rfc2326bis-15.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 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
Content-Type: = text/plain


stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-46-613807384-- --===============0189390119== 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 --===============0189390119==-- From mmusic-bounces@ietf.org Wed Jun 27 07:12:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3VRq-00006X-JR; Wed, 27 Jun 2007 07:12:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3VRo-0008Kc-CK for mmusic@ietf.org; Wed, 27 Jun 2007 07:12:32 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3VRn-00022a-Ft for mmusic@ietf.org; Wed, 27 Jun 2007 07:12:32 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l5RBC3eC018646; Wed, 27 Jun 2007 13:12:03 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l5RBC3gV027419; Wed, 27 Jun 2007 13:12:03 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 13:12:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer Date: Wed, 27 Jun 2007 13:12:02 +0200 Message-ID: <3C1BD8897E747D46B6F037E1CABB9FFFE26FA2@MCHP7IEA.ww002.siemens.net> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF110A93D9@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg Issue #5: Media before answer Thread-Index: Ace4QKvl7WYH0G4wQcCuL/W+/Q/BHwAD1dmgABU0stA= References: <00c301c7b806$44dd0b00$b978150a@amer.cisco.com><46813243.6090807@cisco.com><1ECE0EB50388174790F9694F77522CCF110A9241@zrc2hxm0.corp.nortel.com><46819193.3070109@cisco.com> <1ECE0EB50388174790F9694F77522CCF110A93D9@zrc2hxm0.corp.nortel.com> From: "Belling, Thomas" To: "Francois Audet" , "Flemming Andreasen" X-OriginalArrivalTime: 27 Jun 2007 11:12:02.0694 (UTC) FILETIME=[FD009260:01C7B8AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: mmusic , Dan Wing 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="===============1524869973==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1524869973== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B8AB.FCABF385" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B8AB.FCABF385 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 in my understanding including an answer in an unreliable provisional = response is not allowed by RFC 3261 even it you repeat the answer in the = 200 OK, see top of page 79: "If the initial offer is in an INVITE, the answer MUST be in a reliable = non-failure message from UAS back to UAC which is correlated to that = INVITE." Note that this quotations speaks about "the" answer, and I read that as = a requirement that there is only one answer. =20 Even if you might argue there is a bit of ambiguity in the quotation, I = suspect that there may be interoperabilty issues with clients either not = beeing prepared to handle the answer in an unreliable provisional = response (e.g. if they do not support 100rel), or getting confused if = obtaining the same answer both in a provisional response and the 200 OK. =20 So I would recommend that you use at least 100rel for option 1 - = preconditions is not really related and indeed not required for this = issue. =20 Regards, Thomas =20 ----------------------------------=20 Dr. Thomas Belling=20 Nokia Siemens Networks GmbH & Co. KG. =20 =20 Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft/ Registered = office: M=FCnchen (Munich) - Registergericht /Commercial register: = M=FCnchen (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. Pers=F6nlich = haftende Gesellschafterin /General Partner: Nokia Siemens Networks = Management GmbH - Gesch=E4ftsf=FChrer /Board of Directors: Christian = Unterberger, Joachim Malterer, Roland Meinzer - Sitz der Gesellschaft / = Registered office: M=FCnchen (Munich) - Registergericht /Commercial = register: M=FCnchen (Munich), HRB 163416=20 ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, June 27, 2007 2:14 AM To: Flemming Andreasen Cc: mmusic; Dan Wing Subject: RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer =09 =09 =20 Francois Audet wrote:=20 The preconditions approach to me seems like the least likely approach = to be used in the real world. =20 I really see only two practical way forward: 1.=09 You have to wait for the answer before playing anything. For this to = work, we'd effectively have to rely on provisional responses including = the SDP-answer (and not include the answer in the 200, since it would = cause clipping). That in itself would be a change for many SIP clients = who never tought it necessary to provide an answer before 200 before (at = least, they didn't think they needed it). You'd have to include the answer in both the provisional response and = the 200, unless you use reliable provisional responses.=20 =20 Yes, agreed. Both cases are valid.=20 =09 1.=09 Use the different payload type as per our kaplan draft. My take is that option 1 is the more likely to have wide support. But = we should explain it a bit.=20 =09 Option 2 is interesting, in a geeky way, and probaly better than = pre-conditions. But if people can live with 1, it seems much simpler. I'll include an explanation of all of them (there's already some text = on the above, however I'll elaborate on the points you made).=20 =09 Excellent. Thanks.=20 ------_=_NextPart_001_01C7B8AB.FCABF385 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
in my understanding including an answer in = an=20 unreliable provisional response is not allowed by RFC 3261 even it = you=20 repeat the answer in the 200 OK, see top of page 79:
"If the initial offer is in an INVITE, the = answer MUST be=20 in a reliable non-failure message from UAS back to UAC which=20 is correlated to that INVITE."
Note that this quotations speaks about "the" = answer, and I=20 read that as a requirement that there is only one = answer.
 
Even if you might argue there is a bit of = ambiguity in the=20 quotation, I suspect that there may be interoperabilty issues with = clients=20 either not beeing prepared to handle the answer in an unreliable = provisional=20 response (e.g. if they do not support 100rel), or getting confused if = obtaining=20 the same answer both in a provisional response and the 200=20 OK.
 
So I would recommend that you use at least = 100rel for=20 option 1 - preconditions is not really related and indeed not required = for this=20 issue.
 
Regards, Thomas
 

----------------------------------
Dr. Thomas Belling
Nokia=20 Siemens Networks  GmbH &=20 Co. KG.        =20

 

Nokia Siemens Networks GmbH & Co. KG = - Sitz der=20 Gesellschaft/ Registered office: M=FCnchen (Munich) - Registergericht = /Commercial=20 register: M=FCnchen (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. = Pers=F6nlich=20 haftende Gesellschafterin /General Partner: Nokia Siemens Networks = Management=20 GmbH - Gesch=E4ftsf=FChrer /Board of Directors: Christian Unterberger, = Joachim=20 Malterer, Roland Meinzer - Sitz der Gesellschaft / Registered office: = M=FCnchen=20 (Munich) - Registergericht /Commercial register: M=FCnchen (Munich), HRB = 163416=20


From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Wednesday, June 27, 2007 2:14 AM
To: = Flemming=20 Andreasen
Cc: mmusic; Dan Wing
Subject: RE: = [MMUSIC]=20 SDPCapNeg Issue #5: Media before answer

 

Francois Audet=20 wrote:
The preconditions approach to me seems = like the=20 least likely approach to be used in the real = world.
 
I really see only two practical way=20 forward:
  1. You have to wait for the answer = before playing=20 anything. For this to work, we'd effectively have to rely on = provisional=20 responses including the SDP-answer (and not include the answer = in the=20 200, since it would cause clipping). That in itself would be a = change=20 for many SIP clients who never tought it necessary to provide an = answer=20 before 200 before (at least, they didn't think they needed=20 it).
You'd have to include the answer in both the provisional = response and=20 the 200, unless you use reliable provisional = responses. 
 
Yes, agreed. Both cases are = valid. 
  1. Use the different payload type as per = our=20 kaplan draft.
My take is that option 1 is the more likely to have wide = support.=20 But we should explain it a bit. =
Option 2 is interesting, in a geeky way, and probaly = better than=20 pre-conditions. But if people can live with 1, it seems much=20 simpler.
I'll include an explanation of all of them (there's = already some=20 text on the above, however I'll elaborate on the points you=20 made). 

 Excellent.=20 Thanks. 
------_=_NextPart_001_01C7B8AB.FCABF385-- --===============1524869973== 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 --===============1524869973==-- From mmusic-bounces@ietf.org Wed Jun 27 09:31:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Xbs-0006e1-LZ; Wed, 27 Jun 2007 09:31:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UtH-0006wW-Qy for mmusic@ietf.org; Wed, 27 Jun 2007 06:36:51 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3UtG-00072L-U6 for mmusic@ietf.org; Wed, 27 Jun 2007 06:36:51 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l5RAalFo021697; Wed, 27 Jun 2007 12:36:47 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l5RAakf8032008; Wed, 27 Jun 2007 12:36:47 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 12:36:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer Date: Wed, 27 Jun 2007 12:36:44 +0200 Message-ID: <3C1BD8897E747D46B6F037E1CABB9FFFE26FA1@MCHP7IEA.ww002.siemens.net> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF110A93D9@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg Issue #5: Media before answer Thread-Index: Ace4QKvl7WYH0G4wQcCuL/W+/Q/BHwAD1dmgABU0stA= References: <00c301c7b806$44dd0b00$b978150a@amer.cisco.com><46813243.6090807@cisco.com><1ECE0EB50388174790F9694F77522CCF110A9241@zrc2hxm0.corp.nortel.com><46819193.3070109@cisco.com> <1ECE0EB50388174790F9694F77522CCF110A93D9@zrc2hxm0.corp.nortel.com> From: "Belling, Thomas" To: "Francois Audet" , "Flemming Andreasen" X-OriginalArrivalTime: 27 Jun 2007 10:36:46.0432 (UTC) FILETIME=[0F9C9E00:01C7B8A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 X-Mailman-Approved-At: Wed, 27 Jun 2007 09:31:03 -0400 Cc: mmusic , Dan Wing 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="===============1754951080==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1754951080== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B8A7.0E9479E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B8A7.0E9479E7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 in my understanding including an answer in an unreliable provisional = response is not allowed by RFC 3261 even it you repeat the answer in the = 200 OK, see top of page 79: "If the initial offer is in an INVITE, the answer MUST be in a reliable = non-failure message from UAS back to UAC which is correlated to that = INVITE." Note that this quotations speaks about "the" answer, and I read that as = a requirement that there is only one answer. =20 Even if you might argue there is a bit of ambiguity in the quotation, I = suspect that there may be interoperabilty issues with clients either not = beeing prepared to handle the answer in an unreliable provisional = response (e.g. if they do not support 100rel), or getting confused if = obtaining the same answer both in a provisional response and the 200 OK. =20 So I would recommend that you use at least 100rel for option 1 - = preconditions is not really related and indeed not required for this = issue. =20 Regards, Thomas =20 ----------------------------------=20 Dr. Thomas Belling=20 Nokia Siemens Networks GmbH & Co. KG. =20 =20 Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft/ Registered = office: M=FCnchen (Munich) - Registergericht /Commercial register: = M=FCnchen (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. Pers=F6nlich = haftende Gesellschafterin /General Partner: Nokia Siemens Networks = Management GmbH - Gesch=E4ftsf=FChrer /Board of Directors: Christian = Unterberger, Joachim Malterer, Roland Meinzer - Sitz der Gesellschaft / = Registered office: M=FCnchen (Munich) - Registergericht /Commercial = register: M=FCnchen (Munich), HRB 163416=20 ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, June 27, 2007 2:14 AM To: Flemming Andreasen Cc: mmusic; Dan Wing Subject: RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer =09 =09 =20 Francois Audet wrote:=20 The preconditions approach to me seems like the least likely approach = to be used in the real world. =20 I really see only two practical way forward: 1.=09 You have to wait for the answer before playing anything. For this to = work, we'd effectively have to rely on provisional responses including = the SDP-answer (and not include the answer in the 200, since it would = cause clipping). That in itself would be a change for many SIP clients = who never tought it necessary to provide an answer before 200 before (at = least, they didn't think they needed it). You'd have to include the answer in both the provisional response and = the 200, unless you use reliable provisional responses.=20 =20 Yes, agreed. Both cases are valid.=20 =09 1.=09 Use the different payload type as per our kaplan draft. My take is that option 1 is the more likely to have wide support. But = we should explain it a bit.=20 =09 Option 2 is interesting, in a geeky way, and probaly better than = pre-conditions. But if people can live with 1, it seems much simpler. I'll include an explanation of all of them (there's already some text = on the above, however I'll elaborate on the points you made).=20 =09 Excellent. Thanks.=20 ------_=_NextPart_001_01C7B8A7.0E9479E7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
in my understanding including an answer in = an=20 unreliable provisional response is not allowed by RFC 3261 even it = you=20 repeat the answer in the 200 OK, see top of page 79:
"If the initial offer is in an INVITE, the = answer MUST be=20 in a reliable non-failure message from UAS back to UAC which=20 is correlated to that INVITE."
Note that this quotations speaks about "the" = answer, and I=20 read that as a requirement that there is only one = answer.
 
Even if you might argue there is a bit of = ambiguity in the=20 quotation, I suspect that there may be interoperabilty issues with = clients=20 either not beeing prepared to handle the answer in an unreliable = provisional=20 response (e.g. if they do not support 100rel), or getting confused if = obtaining=20 the same answer both in a provisional response and the 200=20 OK.
 
So I would recommend that you use at least = 100rel for=20 option 1 - preconditions is not really related and indeed not required = for this=20 issue.
 
Regards, Thomas
 

----------------------------------
Dr. Thomas Belling
Nokia=20 Siemens Networks  GmbH &=20 Co. KG.        =20

 

Nokia Siemens Networks GmbH & Co. KG = - Sitz der=20 Gesellschaft/ Registered office: M=FCnchen (Munich) - Registergericht = /Commercial=20 register: M=FCnchen (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. = Pers=F6nlich=20 haftende Gesellschafterin /General Partner: Nokia Siemens Networks = Management=20 GmbH - Gesch=E4ftsf=FChrer /Board of Directors: Christian Unterberger, = Joachim=20 Malterer, Roland Meinzer - Sitz der Gesellschaft / Registered office: = M=FCnchen=20 (Munich) - Registergericht /Commercial register: M=FCnchen (Munich), HRB = 163416=20


From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Wednesday, June 27, 2007 2:14 AM
To: = Flemming=20 Andreasen
Cc: mmusic; Dan Wing
Subject: RE: = [MMUSIC]=20 SDPCapNeg Issue #5: Media before answer

 

Francois Audet=20 wrote:
The preconditions approach to me seems = like the=20 least likely approach to be used in the real = world.
 
I really see only two practical way=20 forward:
  1. You have to wait for the answer = before playing=20 anything. For this to work, we'd effectively have to rely on = provisional=20 responses including the SDP-answer (and not include the answer = in the=20 200, since it would cause clipping). That in itself would be a = change=20 for many SIP clients who never tought it necessary to provide an = answer=20 before 200 before (at least, they didn't think they needed=20 it).
You'd have to include the answer in both the provisional = response and=20 the 200, unless you use reliable provisional = responses. 
 
Yes, agreed. Both cases are = valid. 
  1. Use the different payload type as per = our=20 kaplan draft.
My take is that option 1 is the more likely to have wide = support.=20 But we should explain it a bit. =
Option 2 is interesting, in a geeky way, and probaly = better than=20 pre-conditions. But if people can live with 1, it seems much=20 simpler.
I'll include an explanation of all of them (there's = already some=20 text on the above, however I'll elaborate on the points you=20 made). 

 Excellent.=20 Thanks. 
------_=_NextPart_001_01C7B8A7.0E9479E7-- --===============1754951080== 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 --===============1754951080==-- From mmusic-bounces@ietf.org Wed Jun 27 13:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bcM-0004uu-F3; Wed, 27 Jun 2007 13:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bcL-0004tZ-36 for mmusic@ietf.org; Wed, 27 Jun 2007 13:47:49 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3bbr-0006Kr-R4 for mmusic@ietf.org; Wed, 27 Jun 2007 13:47:49 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I3bbr-0004zC-51; Wed, 27 Jun 2007 13:47:19 -0400 Message-ID: <4682A2A7.8000606@bbn.com> Date: Wed, 27 Jun 2007 13:47:19 -0400 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: Flemming Andreasen Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes References: <467FF7A8.6040303@cisco.com> In-Reply-To: <467FF7A8.6040303@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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, Thanks for producing a draft that captures the motivation for deletion of attributes in capability negotiation. I also think that Option (B) is a good comprise that solves the problem without the perception of unnecessary complexity which seems to burden Option (A). The only downside of Option (B) seems to be that, unlike in Option (C), if deletion is used then one needs an a=acap line for attribute for every attribute, even those present in all potential configurations. For example: v=0 o=alice 2890844526 2890842807 IN IP4 10.0.0.1 s=Example SDP t=0 0 c=IN IP4 10.0.0.1 m=audio 51000 RTP/SAVP 0 99 a=crypto:1 AES_CM_128_HMAC_SHA1_32... a=ptime:30 a=rtpmap:99 L16/8000 a=tcap:1 RTP/AVP a=acap:1 a=ptime:30 a=acap:2 a=rtpmap:99 L16/8000 a=pcfg:1 t=1 a=-m:1,2 The above is an offer indicating a preference for RTP, and a willingness to accept an S-RTP audio stream. Since we need to delete the crypto attribute from the potential RTP configuration (and since in Option B we have only clean-slate delete-all-attributes available) we need to add a=acap lines for the a=ptime and a=rtpmap attributes. Adding these additional lines is a bit inefficient, but it doesn't seem like a serious problem to me. However, if someone has a use-case where deletion is required and yet the inefficiency of option (B) is unacceptable, then I'd be willing to support Option (C). - Matt Lepinski :-> Flemming Andreasen wrote: > Probably the biggest open issue we have in the SDP Capability > Negotiation Framework at this point is the ability to replace and > delete attributes from an actual configuration SDP when generating a > potential configuration. At the Prague IETF, people asked for some > more motiviation and use cases for this feature before deciding > whether we should include it in the core capability negotiation > framework or not. I have written a short I-D in the subject, which you > can find at: > > > http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att-del-00.txt > > > Please take a look at this and let me know how you think we should > resolve this issue. Options include: > > A) Remove the ability to delete and replace attributes completely. > B) Remove the ability to delete and replace individual attributes, but > allow for complete removal of all attributes (clean slate) > C) Keep the current ability to delete and remove individual and all > attributes. > > My personal preference is for option A, however in the interest of > moving forward and making a reasonable compromise between > functionality and complexity, my recommendation is option B. > > 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 Wed Jun 27 13:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bmh-00083B-1p; Wed, 27 Jun 2007 13:58:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bmg-000831-9X for mmusic@ietf.org; Wed, 27 Jun 2007 13:58:30 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3bmg-0000tz-0O for mmusic@ietf.org; Wed, 27 Jun 2007 13:58:30 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I3bmH-00056T-5R; Wed, 27 Jun 2007 13:58:05 -0400 Message-ID: <4682A52D.7020901@bbn.com> Date: Wed, 27 Jun 2007 13:58:05 -0400 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: Flemming Andreasen Subject: Re: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes and potential configuration selection References: <467FF858.6020503@cisco.com> In-Reply-To: <467FF858.6020503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Jonathan Lennox , 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, I'm concerned that marking individual attributes within a potential configuration as mandatory or optional will increase the perception of complexity for SDP capability negotiation. Therefore, my preference would be to avoid Options (3) and (4). Personally, I can't think of a use-case where the lack of flexibility in Option (2) would cause signficant problems. Therefore, I'd favor Option (2). - Matt Lepinski :-> Flemming Andreasen wrote: > Jonathan Lennox had noted that the current potential configurationa > algorithm combined with the standard SDP rules of ignoring unknown > attributes, may lead an answerer to select a potential configuration > with attributes it does not support, when the intent was to actually > have the answerer select a potential configuration with attributes the > answerer does support. Clearly, this does not produce the desired > outcome. > > The reason for this is that we still use the standard SDP rules where > we ignore unknown SDP attributes. > > The design team did not get a chance to discuss this issue in Prague, > however there seems to be a few possible solutions to this one: > > 1) Continue with the current scheme, but allow the answerer to select > only a potential configuration if the potential configuration makes > sense and can be supported. This would ensure that any attributes that > are required in order for a potential configuration to be used would > have to be supported by the answerer in order for him to select that. > For example, if the media stream is for SRTP, and the potential > configuration specifies use of the "crypto" attribute for keying > material, which the answerer didn't support, the answerer would move > on to the next potential configuration (which could use a different > keying mechanism). > > > 2) Require that all attributes used by a potential configuration MUST > be supported by the answerer in order for that potential configuration > to be valid (and hence be able to be selected). An attribute is > supported if both the attribute type and its value can be supported. > This raises some potential ambiguity with payload types for example, > where an rtpmap is both understood and supported, but the actual codec > is not. > > 3) As 2), however allow for individual attribute capabilities to be > marked as "optional" in a potential configuration. If an "optional" > attribute capability is not supported by the answerer, the potential > configuration would still be considered valid. > > 4) Similar to 3), except the default would be "optional", and we can > mark certain attributes as mandatory. > > > Option 1 seems flaky and is not recommended. > Option 2 is simple to specify and use, however, as noted, it is not > clear it has sufficient flexibility > The recommendation here is for either option 3 or 4, with the choice > depending on whether you believe optional or mandatory attributes are > the more common use cases for SDP Capability Negotiation. > > My preference is for option 4. Compared to option 3, this option > aligns slightly better with standard SDP as well, inasmuch as the > default operation is normal SDP, and any changes from that requires an > explicit indication (mandatory attribute). > > Please let me know if you disagree or have any comments on this. > > 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 Wed Jun 27 14:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3c1X-0001c9-IE; Wed, 27 Jun 2007 14:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3c1W-0001ZY-1F for mmusic@ietf.org; Wed, 27 Jun 2007 14:13:50 -0400 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 1I3c1G-0007fz-Fj for mmusic@ietf.org; Wed, 27 Jun 2007 14:13:50 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 27 Jun 2007 11:13:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAItFgkarR7PEh2dsb2JhbACPJgEBCQ4s X-IronPort-AV: i="4.16,467,1175497200"; d="scan'208"; a="382193803:sNHT4944700258" 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 l5RIDHWO020518; Wed, 27 Jun 2007 11:13:17 -0700 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 l5RIDHka029937; Wed, 27 Jun 2007 18:13:17 GMT 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); Wed, 27 Jun 2007 11:13:16 -0700 Received: from [10.21.148.86] ([10.21.148.86]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 11:13:15 -0700 Message-ID: <4682A8B4.90401@cisco.com> Date: Wed, 27 Jun 2007 14:13:08 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Matt Lepinski Subject: Re: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes and potential configuration selection References: <467FF858.6020503@cisco.com> <4682A52D.7020901@bbn.com> In-Reply-To: <4682A52D.7020901@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2007 18:13:15.0920 (UTC) FILETIME=[D504D100:01C7B8E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4025; t=1182967997; x=1183831997; 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:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#9=3A=20Unknown=20attr ibutes=20and=20potential=0A=20configuration=20selection |Sender:=20; bh=EYcyIlvmNqd8BDhi36yVuG2aXSAA0pfuvo9LnC6dqfU=; b=VKfWLsAZyet+miq0rnFZXcqTvyOYRcw7Kq0xdXN1Eqmux7X8QnNG3gD3IehQM0FFttLuBUso AkHheRTdVzrrg6Bn5J8vAm+YCN1CuHNtIWmoFeh/h8SkHvFHQvgGqV1Y; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Jonathan Lennox , 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 Matt Lepinski wrote: > Flemming, > > I'm concerned that marking individual attributes within a potential > configuration as mandatory or optional will increase the perception of > complexity for SDP capability negotiation. Therefore, my preference > would be to avoid Options (3) and (4). > > Personally, I can't think of a use-case where the lack of flexibility > in Option (2) would cause signficant problems. How about rtpmaps mapping to an unsupported codec (which codec negotiation/standard 3264 procedures would have taken care of) ? It will be a quite common use case for the media capabilities extension. > Therefore, I'd favor Option (2). > Per the above, I think there are important use cases that will make this option problematic. -- Flemming > - Matt Lepinski :-> > > Flemming Andreasen wrote: > >> Jonathan Lennox had noted that the current potential configurationa >> algorithm combined with the standard SDP rules of ignoring unknown >> attributes, may lead an answerer to select a potential configuration >> with attributes it does not support, when the intent was to actually >> have the answerer select a potential configuration with attributes >> the answerer does support. Clearly, this does not produce the desired >> outcome. >> >> The reason for this is that we still use the standard SDP rules where >> we ignore unknown SDP attributes. >> >> The design team did not get a chance to discuss this issue in Prague, >> however there seems to be a few possible solutions to this one: >> >> 1) Continue with the current scheme, but allow the answerer to select >> only a potential configuration if the potential configuration makes >> sense and can be supported. This would ensure that any attributes >> that are required in order for a potential configuration to be used >> would have to be supported by the answerer in order for him to select >> that. For example, if the media stream is for SRTP, and the potential >> configuration specifies use of the "crypto" attribute for keying >> material, which the answerer didn't support, the answerer would move >> on to the next potential configuration (which could use a different >> keying mechanism). >> >> >> 2) Require that all attributes used by a potential configuration MUST >> be supported by the answerer in order for that potential >> configuration to be valid (and hence be able to be selected). An >> attribute is supported if both the attribute type and its value can >> be supported. This raises some potential ambiguity with payload types >> for example, where an rtpmap is both understood and supported, but >> the actual codec is not. >> >> 3) As 2), however allow for individual attribute capabilities to be >> marked as "optional" in a potential configuration. If an "optional" >> attribute capability is not supported by the answerer, the potential >> configuration would still be considered valid. >> >> 4) Similar to 3), except the default would be "optional", and we can >> mark certain attributes as mandatory. >> >> >> Option 1 seems flaky and is not recommended. >> Option 2 is simple to specify and use, however, as noted, it is not >> clear it has sufficient flexibility >> The recommendation here is for either option 3 or 4, with the choice >> depending on whether you believe optional or mandatory attributes are >> the more common use cases for SDP Capability Negotiation. >> >> My preference is for option 4. Compared to option 3, this option >> aligns slightly better with standard SDP as well, inasmuch as the >> default operation is normal SDP, and any changes from that requires >> an explicit indication (mandatory attribute). >> >> Please let me know if you disagree or have any comments on this. >> >> 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 Wed Jun 27 14:54:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cfE-0004Ig-FG; Wed, 27 Jun 2007 14:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cfD-0004IW-1I for mmusic@ietf.org; Wed, 27 Jun 2007 14:54:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3cen-0005ft-K9 for mmusic@ietf.org; Wed, 27 Jun 2007 14:54:51 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1153554ugf for ; Wed, 27 Jun 2007 11:54:24 -0700 (PDT) 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:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=QV4BGoi+8/S/xWOA2w0hI/aeZ2Ok7nG/x2cl/iJGUItL1oBmxpR8NBpJQkNrIy97kgrp1BCgyjexuQCcrccO5WufZBKzoCNJZFzgktNU6Oc8J3fAq0ZYnPqi/fgtYAsWjJhMrzfWekstSBgB+Z5nWl1Fh3HCIVAQ3ITXTQtzwZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=qTX9ldWT2P7dX7cMLnJFhmEXun32+4NnT/NOGieuXEAjpFQsXrc2dhUuHVJwzGngoTLA7h9QL9M2VBzjwQ22X6UNUoE+aYqb/PputcwNB7SpPJwBKbKLa++SsLu2HrHup0KidCrIlyuGvQKRG+Xv9UDHLF410zxMOJeCpqOnIr4= Received: by 10.78.140.16 with SMTP id n16mr465490hud.1182970464678; Wed, 27 Jun 2007 11:54:24 -0700 (PDT) Received: by 10.78.200.7 with HTTP; Wed, 27 Jun 2007 11:54:24 -0700 (PDT) Message-ID: <4d0605c20706271154q54476ffk10aef075944cb50f@mail.gmail.com> Date: Wed, 27 Jun 2007 11:54:24 -0700 From: "Joseph Pallas" To: mmusic@ietf.org Subject: Re: Fwd: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-15.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 80219048270444c5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > The new version of draft-ietf-mmusic-rfc2326bis is just an XML-lized version > of draft-ietf-mmusic-rfc2326bis-14.txt. > > draft-ietf-mmusic-rfc2326bis-14.txt was using tex sources > and the first step was to convert the old draft sources to the newer xml > format used by xml2rfc. > > Magnus and me have done a check of this version, but it would be good if > other people could also take a look, whether the -14 and -15 are the same in > terms of contents of the draft. I couldn't spot any content differences, so I'm glad to know there weren't supposed to be any. On the formatting front, there are a couple of places where references are rendered oddly, as in The URI scheme "rtsp" requires that commands are issued via a reliable protocol (within the Internet, TCP), while the scheme "rtsps" identifies a reliable transport using secure transport (TLS [RFC4346], see Section (Section 18). There are also some places where SET_PARAMETER and GET_PARAMETER are missing the underscore. I'm not sure if that's new. joe _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 28 04:27:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pLq-0004nm-J2; Thu, 28 Jun 2007 04:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pLp-0004nc-0h for mmusic@ietf.org; Thu, 28 Jun 2007 04:27:41 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3pLg-0000MM-B5 for mmusic@ietf.org; Thu, 28 Jun 2007 04:27:40 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F93620BD5; Thu, 28 Jun 2007 10:27:31 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-b0-468370f3ec14 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0F81D20BD6; Thu, 28 Jun 2007 10:27:31 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 10:27:30 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 10:27:30 +0200 Message-ID: <468370F2.5090601@ericsson.com> Date: Thu, 28 Jun 2007 10:27:30 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Joseph Pallas Subject: Re: Fwd: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-15.txt References: <4d0605c20706271154q54476ffk10aef075944cb50f@mail.gmail.com> In-Reply-To: <4d0605c20706271154q54476ffk10aef075944cb50f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2007 08:27:30.0256 (UTC) FILETIME=[2AFBD500:01C7B95E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Joseph Pallas skrev: > > There are also some places where SET_PARAMETER and GET_PARAMETER are > missing the underscore. I'm not sure if that's new. > That is likely to be new. In the LATEX these methods where done using an alias as the underscore has meaning there and need escaping. This is fixed now in our source. I will let Martin handle the references. Thanks for the review Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 28 05:29:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3qJ8-0000do-Jc; Thu, 28 Jun 2007 05:28:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3qJ7-0000dh-UC for mmusic@ietf.org; Thu, 28 Jun 2007 05:28:57 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3qIn-0003JK-0A for mmusic@ietf.org; Thu, 28 Jun 2007 05:28:57 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 2FFD637C38B for ; Thu, 28 Jun 2007 14:52:45 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTP id 9230A37C443for ; Thu, 28 Jun 2007 14:52:23 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 14:57:08 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Jun 2007 14:56:07 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601ADD24F@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP and FAX Thread-Index: Ace5ZltgSPDBnxfGTuWphHwqvwMuQw== From: "Manivannan S, TLS-Chennai" To: , "Manivannan S, TLS-Chennai" X-OriginalArrivalTime: 28 Jun 2007 09:27:08.0629 (UTC) FILETIME=[7FDC3850:01C7B966] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-7.5539 TC:1F TRN:34 TV:3.6.1039(15264.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Subject: [MMUSIC] SIP and FAX 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="===============2024137250==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============2024137250== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B966.801719AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B966.801719AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Could anybody tell me which latest RFC/draft is explaining FAX T.38 over SIP and SDP? I have googled and found only expired drafts. Thanks, S. Manivannan =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7B966.801719AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

Could anybody= tell me=20 which latest RFC/draft is explaining FAX T.38 over SIP and SDP? I have= googled=20 and found only expired drafts.

Thanks,

S.=20 Manivannan

 
DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7B966.801719AC-- --===============2024137250== 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 --===============2024137250==-- From mmusic-bounces@ietf.org Thu Jun 28 08:25:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3t4A-0000E2-MZ; Thu, 28 Jun 2007 08:25:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3t49-0000Dw-Sy for mmusic@ietf.org; Thu, 28 Jun 2007 08:25:41 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3t49-0001mq-L1 for mmusic@ietf.org; Thu, 28 Jun 2007 08:25:41 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:62500) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1I3t3E-0003Sg-MS; Thu, 28 Jun 2007 13:24:44 +0100 In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601ADD24F@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> References: <66E8AEE9980BB44CA5FCAD39EBA56AC601ADD24F@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B69E941-0435-461D-A5C7-52A0C2B74472@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] SIP and FAX Date: Thu, 28 Jun 2007 13:24:42 +0100 To: "Manivannan S, TLS-Chennai" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 28 Jun 2007, at 10:26, Manivannan S, TLS-Chennai wrote: > Could anybody tell me which latest RFC/draft is explaining FAX T.38 > over SIP and SDP? I have googled and found only expired drafts. RFC 4612? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jun 28 09:14:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3tpE-0003yu-15; Thu, 28 Jun 2007 09:14:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3tpC-0003yn-Dw for mmusic@ietf.org; Thu, 28 Jun 2007 09:14:18 -0400 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3toV-0007sg-AU for mmusic@ietf.org; Thu, 28 Jun 2007 09:14:18 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 7BAD137C024; Thu, 28 Jun 2007 18:38:47 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTPid 5F31337C005; Thu, 28 Jun 2007 18:38:47 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 18:43:32 +0530 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, 28 Jun 2007 18:43:02 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601B0AD0E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] SIP and FAX Thread-Index: Ace5ZNtq99cT7OLMTY2Pqd+TPdhAXQAC7NRwAAU04eA= References: <20070628103709.B48471C802A@smtpauth01.csee.onr.siteprotect.com> From: "Manivannan S, TLS-Chennai" To: "Gaurav Kheterpal" , , X-OriginalArrivalTime: 28 Jun 2007 13:13:32.0655 (UTC) FILETIME=[209217F0:01C7B986] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-11.3657 TC:1F TRN:46 TV:3.6.1039(15264.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [MMUSIC] RE: [Sip-implementors] SIP and FAX 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 Gaurav, I get some information from this RFC, but I need call flow involved in FAX over SIP. I have found a draft(draft-ietf-sipping-realtimefax-01.txt), but it is expired. Any latest RFC/draft explaining the call flow of FAX t.38 over SIP. Thanks, S. Manivannan -----Original Message----- From: Gaurav Kheterpal [mailto:gkheterpal@ismartpanache.com]=20 Sent: Thursday, June 28, 2007 4:20 PM To: Manivannan S, TLS-Chennai; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: RE: [Sip-implementors] SIP and FAX You can refer to:- * RFC 4612 - Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration * http://www.iana.org/assignments/sdp-parameters * ITU-T T.38 Annexure D, Section 9 * draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00 - SDP Capability Negotiation: Requirements and Review of Existing Work Regards, Gaurav > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-=20 > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Manivannan S, > TLS-Chennai > Sent: Thursday, June 28, 2007 2:45 PM > To: sip-implementors@cs.columbia.edu; mmusic@ietf.org; Manivannan S,=20 > TLS- Chennai > Subject: [Sip-implementors] SIP and FAX >=20 >=20 > Hi all, >=20 >=20 >=20 > Could anybody tell me which latest RFC/draft is explaining FAX T.38=20 > over SIP and SDP? I have googled and found only expired drafts. >=20 >=20 >=20 > Thanks, >=20 > S. Manivannan >=20 >=20 >=20 > DISCLAIMER: > ---------------------------------------------------------------------- > ---- > --------------------------------------------- >=20 > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its=20 > affiliates. Any views or opinions presented in this email are solely=20 > those of the author and may not necessarily reflect the opinions of=20 > HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure,=20 > modification, distribution and / or publication of this message=20 > without the prior written consent of the author of this e- mail is=20 > strictly prohibited. If you have received this email in error please=20 > delete it and notify the sender immediately. Before opening any mail=20 > and attachments please check them for viruses and defect. >=20 > ---------------------------------------------------------------------- > ---- > --------------------------------------------- > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 29 02:31:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4A1K-0001JU-An; Fri, 29 Jun 2007 02:31:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4A1J-0001JJ-2m for mmusic@ietf.org; Fri, 29 Jun 2007 02:31:53 -0400 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 1I4A1E-0008NN-Ic for mmusic@ietf.org; Fri, 29 Jun 2007 02:31:53 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JKD00A56WSMLZ@siemenscomms.co.uk> for mmusic@ietf.org; Fri, 29 Jun 2007 07:31:35 +0100 (BST) Date: Fri, 29 Jun 2007 07:31:45 +0100 From: "Elwell, John" Subject: RE: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes In-reply-to: <4682A2A7.8000606@bbn.com> To: Matt Lepinski , Flemming Andreasen Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019EFE8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes Thread-Index: Ace4426JBp+feo1fRsGsr2I40KzUdwA4tk3A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <467FF7A8.6040303@cisco.com> <4682A2A7.8000606@bbn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 Me too for option B John > -----Original Message----- > From: Matt Lepinski [mailto:mlepinski@bbn.com] > Sent: 27 June 2007 18:47 > To: Flemming Andreasen > Cc: mmusic > Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and > Replace Attributes > > Flemming, > > Thanks for producing a draft that captures the motivation for > deletion > of attributes in capability negotiation. > > I also think that Option (B) is a good comprise that solves > the problem > without the perception of unnecessary complexity which seems > to burden > Option (A). > > The only downside of Option (B) seems to be that, unlike in > Option (C), > if deletion is used then one needs an a=acap line for attribute for > every attribute, even those present in all potential configurations. > > For example: > > v=0 > o=alice 2890844526 2890842807 IN IP4 10.0.0.1 > s=Example SDP > t=0 0 > c=IN IP4 10.0.0.1 > m=audio 51000 RTP/SAVP 0 99 > a=crypto:1 AES_CM_128_HMAC_SHA1_32... > a=ptime:30 > a=rtpmap:99 L16/8000 > a=tcap:1 RTP/AVP > a=acap:1 a=ptime:30 > a=acap:2 a=rtpmap:99 L16/8000 > a=pcfg:1 t=1 a=-m:1,2 > > The above is an offer indicating a preference for RTP, and a > willingness > to accept an S-RTP audio stream. Since we need to delete the crypto > attribute from the potential RTP configuration (and since in > Option B we > have only clean-slate delete-all-attributes available) we need to add > a=acap lines for the a=ptime and a=rtpmap attributes. > > Adding these additional lines is a bit inefficient, but it > doesn't seem > like a serious problem to me. However, if someone has a > use-case where > deletion is required and yet the inefficiency of option (B) is > unacceptable, then I'd be willing to support Option (C). > > - Matt Lepinski :-> > > Flemming Andreasen wrote: > > > Probably the biggest open issue we have in the SDP Capability > > Negotiation Framework at this point is the ability to replace and > > delete attributes from an actual configuration SDP when > generating a > > potential configuration. At the Prague IETF, people asked for some > > more motiviation and use cases for this feature before deciding > > whether we should include it in the core capability negotiation > > framework or not. I have written a short I-D in the > subject, which you > > can find at: > > > > > > > http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp capneg-att-del-00.txt > > > > > > Please take a look at this and let me know how you think we should > > resolve this issue. Options include: > > > > A) Remove the ability to delete and replace attributes completely. > > B) Remove the ability to delete and replace individual > attributes, but > > allow for complete removal of all attributes (clean slate) > > C) Keep the current ability to delete and remove individual and all > > attributes. > > > > My personal preference is for option A, however in the interest of > > moving forward and making a reasonable compromise between > > functionality and complexity, my recommendation is option B. > > > > 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 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 29 16:03:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4MgP-0004cs-5n; Fri, 29 Jun 2007 16:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4MgN-0004UT-3V for mmusic@ietf.org; Fri, 29 Jun 2007 16:03:07 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Mg1-0006Px-BM for mmusic@ietf.org; Fri, 29 Jun 2007 16:03:07 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l5TK2HPC006699; Fri, 29 Jun 2007 14:02:17 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 29 Jun 2007 14:02:17 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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, 29 Jun 2007 14:02:17 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E993A@srvxchg3.cablelabs.com> In-Reply-To: <30F0D7625E0DEC4E83A2A94596BC18B701D5E600@VRZIL-EX01.il.veraznetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] SIP and FAX Thread-Index: Ace5ZNtq99cT7OLMTY2Pqd+TPdhAXQAC7NRwAAU04eAAA0NmAAAlzIwg References: <20070628103709.B48471C802A@smtpauth01.csee.onr.siteprotect.com><66E8AEE9980BB44CA5FCAD39EBA56AC601B0AD0E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <30F0D7625E0DEC4E83A2A94596BC18B701D5E600@VRZIL-EX01.il.veraznetworks.com> From: "Jean-Francois Mule" To: "Meir Leshem" , "Manivannan S, TLS-Chennai" , "Gaurav Kheterpal" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: [MMUSIC] RE: [Sip-implementors] SIP and FAX 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, S. Manivannan > I get some information from this RFC, but I need call flow involved in > FAX over SIP. A call flow is only informative. Meir Leshem > As far as I know, draft-ietf-sipping-realtimefax-01 (which is expired > of > course) is the de-facto standard for negotiation of fax handling (T.38 > and fallback to G.711) in SIP. draft-ietf-sipping-realtimefax-01 is dead, RIP. As one of the original authors of the sipping draft, I guess I should chime in.=20 This old draft was put together back in 1999 when voip gateways started to implement t.38 fax and it helped in the first sipit where we tested fax way back then. The itu specs were also not stable and it helped debug issues and get some interop going. But this is now over and the draft should not be used as a reference: it was a work-in-progress. It was rightly decided by the sipping chairs at the time that the draft was about SDP attributes for t38 fax and then RFC 3362 was published, and then rfc4612.=20 That said, the old draft is still used by many folks to understand that you got to start with an audio session, wait for the fax whistling and some specific triggers to perform tone detection then switch to an appropriate codec (g711 fallback or switch to another one). Note that with super G3 fax machines, modem/voice band data, T.38v3 and V.152, implementers have a couple more options to transport fax/mode calls reliably and it's gotten a little bit more interesting. Also, in some networks, g711 just works fine. Colin wrote: > RFC 4612? Yes. This adds mime types for t.38 over rtp; many implementations still use udptl. It's been a while I moved away from this but the itu Recommendation should be reference spec (annex D?). Jean-Francois. > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Meir Leshem > Sent: Thursday, June 28, 2007 8:45 AM > To: Manivannan S, TLS-Chennai; Gaurav Kheterpal; sip- > implementors@cs.columbia.edu; mmusic@ietf.org > Subject: Re: [Sip-implementors] SIP and FAX >=20 > Hi, >=20 > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu > [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of > Manivannan S, TLS-Chennai > Sent: Thursday, June 28, 2007 4:13 PM > To: Gaurav Kheterpal; sip-implementors@cs.columbia.edu; > mmusic@ietf.org > Subject: Re: [Sip-implementors] SIP and FAX >=20 > Thanks Gaurav, >=20 > I get some information from this RFC, but I need call flow involved in > FAX over SIP. I have found a > draft(draft-ietf-sipping-realtimefax-01.txt), but it is expired. Any > latest RFC/draft explaining the call flow of FAX t.38 over SIP. >=20 > Thanks, > S. Manivannan >=20 > -----Original Message----- > From: Gaurav Kheterpal [mailto:gkheterpal@ismartpanache.com] > Sent: Thursday, June 28, 2007 4:20 PM > To: Manivannan S, TLS-Chennai; sip-implementors@cs.columbia.edu; > mmusic@ietf.org > Subject: RE: [Sip-implementors] SIP and FAX >=20 > You can refer to:- >=20 > * RFC 4612 - Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type > Registration >=20 > * http://www.iana.org/assignments/sdp-parameters >=20 > * ITU-T T.38 Annexure D, Section 9 >=20 > * draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00 - SDP > Capability Negotiation: Requirements and Review of Existing Work >=20 > Regards, > Gaurav >=20 > > -----Original Message----- > > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- > > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Manivannan > S, >=20 > > TLS-Chennai > > Sent: Thursday, June 28, 2007 2:45 PM > > To: sip-implementors@cs.columbia.edu; mmusic@ietf.org; Manivannan S, > > TLS- Chennai > > Subject: [Sip-implementors] SIP and FAX > > > > > > Hi all, > > > > > > > > Could anybody tell me which latest RFC/draft is explaining FAX T.38 > > over SIP and SDP? I have googled and found only expired drafts. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 29 17:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Nr5-00005V-FY; Fri, 29 Jun 2007 17:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Nr4-0008NX-DN for mmusic@ietf.org; Fri, 29 Jun 2007 17:18:14 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Npw-00018r-Tu for mmusic@ietf.org; Fri, 29 Jun 2007 17:18:14 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62255 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1I4Npw-0006EV-EV for mmusic@ietf.org; Fri, 29 Jun 2007 22:17:04 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <943719C1-BBF2-441D-A767-F34C9D8E509D@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 29 Jun 2007 22:17:03 +0100 To: MMUSIC WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [MMUSIC] Fwd: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA 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. Begin forwarded message: > Date: 29 June 2007 05:00:01 BDT > To: ietf-announce@ietf.org > > There are two (2) Internet-Draft cutoff dates for the 69th > IETF Meeting in Chicago, IL, USA: > > July 2nd: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > July 2nd 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, > June 25th at 9:00 AM ET. > > July 9th: 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, July 9th 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, July 23rd 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 69th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_69.html. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jun 29 17:22:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Nv3-0007Mj-0C; Fri, 29 Jun 2007 17:22:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Nv1-0007C2-88 for mmusic@ietf.org; Fri, 29 Jun 2007 17:22:19 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4NuR-0002gA-FA for mmusic@ietf.org; Fri, 29 Jun 2007 17:22:19 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l5TLLf4j031916; Fri, 29 Jun 2007 15:21:41 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 29 Jun 2007 15:21:41 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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, 29 Jun 2007 15:21:30 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9951@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Few comments on ICE-16 Thread-Index: Ace6k3Y2c0PgTroMR32lOSs5qdzGyA== From: "Jean-Francois Mule" To: "Jonathan Rosenberg" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [MMUSIC] Few comments on ICE-16 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 Jonathan, Here are a few comments. - in 4.1.1.2., paragraph 2: The current text puts 2 conditional MUSTs depending on the deployment usage but does not clearly spell out what MUST be implemented and configurable. As you did in the first paragraph, it would be a plus to have a clear requirement on what is RECOMMENDED for the agent to implement (SHOULD for both STUN Allocate & Binding).=20 - re: the new formula for Ta: I understand that this came out of the ICE pacing discussion and Dan's proposal on the TSVWG list and following discussions but nonetheless, it adds significant complexity. 1) nit - while you point folks to read section B.1 for more details, it is a bit opaque as presented. Adding one sentence around this formula's goals (same bandwidth as RTP) or risks if implementers choose to hardcode this as 20ms may help. 2) what happens when you have a media stream being offered with a codec and different ptimes supported (e.g. G.711, ptime=3D10, 20)? Should an implementation should the default ptime for the codec or the ptime that will result in the greater sum value?=20 - RTO: consider removing "/" from the formula=20 - what happens if an agent receives SDP with changes in the SDP that would have required an ICE restart but the sending agent did not change pwg/frag (not fully compliant or buggy implementation)? Should it reject the changes by sending an error response (which one)? or gracefully assume a restart and proceed with an ICE restart? does this impact the controlled/controlling role? This could be clarified to handle the error case - may be it is and I missed it. - re: IPv6, the email I sent to the v6 list on 5/24 and copied you Jonathan on asking for their review & guidance never made it to the v6 list. I realized this today searching through the archive. I will update it and resend - sorry about that. Given the changes though, getting more eyeballs on the new text for dual-stack hosts will be a plus. Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jun 30 01:51:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4VrG-0004W6-GJ; Sat, 30 Jun 2007 01:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4VrF-0004Si-8G for mmusic@ietf.org; Sat, 30 Jun 2007 01:50:57 -0400 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 1I4Vr8-0001TY-NW for mmusic@ietf.org; Sat, 30 Jun 2007 01:50:57 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Jun 2007 22:50:50 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAG6LhUarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,478,1175497200"; d="scan'208"; a="499049825:sNHT28068084" 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 l5U5oniY030442; Fri, 29 Jun 2007 22:50:49 -0700 Received: from dwingwxp (sjc-vpn5-928.cisco.com [10.21.91.160]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5U5ommo017378; Sat, 30 Jun 2007 05:50:48 GMT From: "Dan Wing" To: "'Jean-Francois Mule'" , "'Jonathan Rosenberg'" , Subject: RE: [MMUSIC] Few comments on ICE-16 Date: Fri, 29 Jun 2007 22:50:49 -0700 Message-ID: <090f01c7bada$9cfd20a0$a296150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ace6k3Y2c0PgTroMR32lOSs5qdzGyAARhatw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C62E9951@srvxchg3.cablelabs.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3164; t=1183182649; x=1184046649; c=relaxed/simple; s=sjdkim4002; 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]=20Few=20comments=20on=20ICE-16 |Sender:=20; bh=hKLGUn+1KIlCDkiMBdaYvO0svN/Lm9Z2VDuYXynCeBg=; b=RRwckhj2Au8g8t6bHhvPa3l99oPd6FHug6cQGMZTkmFg3wpUCsJUp3CL935msGCefr40mlbE D98Rf3tVKgLbRVHQSB8CK+f+J66ovkMYf7w+JhVn8WkxSbqCfB2u4TWe; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, June 29, 2007 2:22 PM > To: Jonathan Rosenberg; mmusic@ietf.org > Subject: [MMUSIC] Few comments on ICE-16 > > Jonathan, > > Here are a few comments. > > - in 4.1.1.2., paragraph 2: > The current text puts 2 conditional MUSTs depending on the deployment > usage but does not clearly spell out what MUST be implemented and > configurable. > As you did in the first paragraph, it would be a plus to have a clear > requirement on what is RECOMMENDED for the agent to implement (SHOULD > for both STUN Allocate & Binding). > > - re: the new formula for Ta: > I understand that this came out of the ICE pacing discussion and Dan's > proposal on the TSVWG list and following discussions but > nonetheless, it adds significant complexity. I don't believe it does; it merely defines a formula to calculate Ta and RTO, rather than using hard-coded values. The STUN state machine stays the same, and ICE and ICE's operation do not interfere with the STUN state machine or STUN timers due to this change. > 1) nit - while you point folks to read section B.1 for more > details, it > is a bit opaque as presented. Adding one sentence around this > formula's > goals (same bandwidth as RTP) or risks if implementers choose to > hardcode this as 20ms may help. > 2) what happens when you have a media stream being offered > with a codec > and different ptimes supported (e.g. G.711, ptime=10, 20)? Should an > implementation should the default ptime for the codec or the > ptime that will result in the greater sum value? It's impossible for the offerer to send a connectivity check until it receives the SDP answer (because until the answer arrives, it doesn't know the IP address and UDP port to send its connectivity checks to). When the answer arrives, the offerer will know which ptime to use. The RTO and Ta formulas are calculated at the time the answer is received (not when the offer is generated). > - RTO: consider removing "/" from the formula -d > - what happens if an agent receives SDP with changes in the SDP that > would have required an ICE restart but the sending agent did > not change > pwg/frag (not fully compliant or buggy implementation)? > Should it reject > the changes by sending an error response (which one)? or gracefully > assume a restart and proceed with an ICE restart? does this impact the > controlled/controlling role? > This could be clarified to handle the error case - may be it is and I > missed it. > > - re: IPv6, the email I sent to the v6 list on 5/24 and copied you > Jonathan on asking for their review & guidance never made it to the v6 > list. I realized this today searching through the archive. I > will update > it and resend - sorry about that. Given the changes though, > getting more > eyeballs on the new text for dual-stack hosts will be a plus. > > Jean-Francois. > > > _______________________________________________ > 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 Sat Jun 30 08:11:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4bnf-0006Hx-DB; Sat, 30 Jun 2007 08:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rYS-0001F8-TX for mmusic@ietf.org; Thu, 28 Jun 2007 06:48:52 -0400 Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3rXi-0005TW-53 for mmusic@ietf.org; Thu, 28 Jun 2007 06:48:52 -0400 Received: from gauravk (unknown [221.134.154.130]) (Authenticated sender: gkheterpal@ismartpanache.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id B48471C802A; Thu, 28 Jun 2007 05:37:09 -0500 (CDT) From: "Gaurav Kheterpal" To: "'Manivannan S, TLS-Chennai'" , , Date: Thu, 28 Jun 2007 16:19:34 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace5ZNtq99cT7OLMTY2Pqd+TPdhAXQAC7NRw In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601ADD209@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Message-Id: <20070628103709.B48471C802A@smtpauth01.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Sat, 30 Jun 2007 08:11:37 -0400 Cc: Subject: [MMUSIC] RE: [Sip-implementors] SIP and FAX 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 You can refer to:- * RFC 4612 - Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration * http://www.iana.org/assignments/sdp-parameters * ITU-T T.38 Annexure D, Section 9 * draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00 - SDP Capability Negotiation: Requirements and Review of Existing Work Regards, Gaurav > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Manivannan S, > TLS-Chennai > Sent: Thursday, June 28, 2007 2:45 PM > To: sip-implementors@cs.columbia.edu; mmusic@ietf.org; Manivannan S, TLS- > Chennai > Subject: [Sip-implementors] SIP and FAX > > > Hi all, > > > > Could anybody tell me which latest RFC/draft is explaining FAX T.38 over > SIP and SDP? I have googled and found only expired drafts. > > > > Thanks, > > S. Manivannan > > > > DISCLAIMER: > -------------------------------------------------------------------------- > --------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect > the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this e- > mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > -------------------------------------------------------------------------- > --------------------------------------------- > ____________From mmusic-bounces@ietf.org Sat Jun 30 08:11:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4bnf-0006Hx-DB; Sat, 30 Jun 2007 08:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rYS-0001F8-TX for mmusic@ietf.org; Thu, 28 Jun 2007 06:48:52 -0400 Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3rXi-0005TW-53 for mmusic@ietf.org; Thu, 28 Jun 2007 06:48:52 -0400 Received: from gauravk (unknown [221.134.154.130]) (Authenticated sender: gkheterpal@ismartpanache.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id B48471C802A; Thu, 28 Jun 2007 05:37:09 -0500 (CDT) From: "Gaurav Kheterpal" To: "'Manivannan S, TLS-Chennai'" , , Date: Thu, 28 Jun 2007 16:19:34 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace5ZNtq99cT7OLMTY2Pqd+TPdhAXQAC7NRw In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601ADD209@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Message-Id: <20070628103709.B48471C802A@smtpauth01.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Sat, 30 Jun 2007 08:11:37 -0400 Cc: Subject: [MMUSIC] RE: [Sip-implementors] SIP and FAX 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 You can refer to:- * RFC 4612 - Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration * http://www.iana.org/assignments/sdp-parameters * ITU-T T.38 Annexure D, Section 9 * draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00 - SDP Capability Negotiation: Requirements and Review of Existing Work Regards, Gaurav > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Manivannan S, > TLS-Chennai > Sent: Thursday, June 28, 2007 2:45 PM > To: sip-implementors@cs.columbia.edu; mmusic@ietf.org; Manivannan S, TLS- > Chennai > Subject: [Sip-implementors] SIP and FAX > > > Hi all, > > > > Could anybody tell me which latest RFC/draft is explaining FAX T.38 over > SIP and SDP? I have googled and found only expired drafts. > > > > Thanks, > > S. Manivannan > > > > DISCLAIMER: > -------------------------------------------------------------------------- > --------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect > the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this e- > mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > -------------------------------------------------------------------------- > --------------------------------------------- > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jun 30 08:11:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4bnf-0006Ml-Vo; Sat, 30 Jun 2007 08:11:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vDG-0005P4-W7 for mmusic@ietf.org; Thu, 28 Jun 2007 10:43:15 -0400 Received: from [212.25.80.121] (helo=VRZIL-MR.il.veraznetworks.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3vDG-0003pw-6Y for mmusic@ietf.org; Thu, 28 Jun 2007 10:43:14 -0400 Received: from VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by VRZIL-MR.il.veraznetworks.com with InterScan Message Security Suite; Thu, 28 Jun 2007 17:47:07 +0300 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, 28 Jun 2007 17:45:14 +0300 Message-ID: <30F0D7625E0DEC4E83A2A94596BC18B701D5E600@VRZIL-EX01.il.veraznetworks.com> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601B0AD0E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] SIP and FAX Thread-Index: Ace5ZNtq99cT7OLMTY2Pqd+TPdhAXQAC7NRwAAU04eAAA0NmAA== References: <20070628103709.B48471C802A@smtpauth01.csee.onr.siteprotect.com> <66E8AEE9980BB44CA5FCAD39EBA56AC601B0AD0E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> From: "Meir Leshem" To: "Manivannan S, TLS-Chennai" , "Gaurav Kheterpal" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-Mailman-Approved-At: Sat, 30 Jun 2007 08:11:37 -0400 Cc: Subject: [MMUSIC] RE: [Sip-implementors] SIP and FAX 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, As far as I know, draft-ietf-sipping-realtimefax-01 (which is expired of course) is the de-facto standard for negotiation of fax handling (T.38 and fallback to G.711) in SIP.=20 Regards Meir Leshem Veraz Networks -----Original Message----- From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of Manivannan S, TLS-Chennai Sent: Thursday, June 28, 2007 4:13 PM To: Gaurav Kheterpal; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: Re: [Sip-implementors] SIP and FAX Thanks Gaurav, I get some information from this RFC, but I need call flow involved in FAX over SIP. I have found a draft(draft-ietf-sipping-realtimefax-01.txt), but it is expired. Any latest RFC/draft explaining the call flow of FAX t.38 over SIP. Thanks, S. Manivannan -----Original Message----- From: Gaurav Kheterpal [mailto:gkheterpal@ismartpanache.com]=20 Sent: Thursday, June 28, 2007 4:20 PM To: Manivannan S, TLS-Chennai; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: RE: [Sip-implementors] SIP and FAX You can refer to:- * RFC 4612 - Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration * http://www.iana.org/assignments/sdp-parameters * ITU-T T.38 Annexure D, Section 9 * draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00 - SDP Capability Negotiation: Require___________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jun 30 08:11:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4bnf-0006Ml-Vo; Sat, 30 Jun 2007 08:11:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vDG-0005P4-W7 for mmusic@ietf.org; Thu, 28 Jun 2007 10:43:15 -0400 Received: from [212.25.80.121] (helo=VRZIL-MR.il.veraznetworks.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3vDG-0003pw-6Y for mmusic@ietf.org; Thu, 28 Jun 2007 10:43:14 -0400 Received: from VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by VRZIL-MR.il.veraznetworks.com with InterScan Message Security Suite; Thu, 28 Jun 2007 17:47:07 +0300 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, 28 Jun 2007 17:45:14 +0300 Message-ID: <30F0D7625E0DEC4E83A2A94596BC18B701D5E600@VRZIL-EX01.il.veraznetworks.com> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601B0AD0E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] SIP and FAX Thread-Index: Ace5ZNtq99cT7OLMTY2Pqd+TPdhAXQAC7NRwAAU04eAAA0NmAA== References: <20070628103709.B48471C802A@smtpauth01.csee.onr.siteprotect.com> <66E8AEE9980BB44CA5FCAD39EBA56AC601B0AD0E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> From: "Meir Leshem" To: "Manivannan S, TLS-Chennai" , "Gaurav Kheterpal" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-Mailman-Approved-At: Sat, 30 Jun 2007 08:11:37 -0400 Cc: Subject: [MMUSIC] RE: [Sip-implementors] SIP and FAX 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, As far as I know, draft-ietf-sipping-realtimefax-01 (which is expired of course) is the de-facto standard for negotiation of fax handling (T.38 and fallback to G.711) in SIP.=20 Regards Meir Leshem Veraz Networks -----Original Message----- From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of Manivannan S, TLS-Chennai Sent: Thursday, June 28, 2007 4:13 PM To: Gaurav Kheterpal; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: Re: [Sip-implementors] SIP and FAX Thanks Gaurav, I get some information from this RFC, but I need call flow involved in FAX over SIP. I have found a draft(draft-ietf-sipping-realtimefax-01.txt), but it is expired. Any latest RFC/draft explaining the call flow of FAX t.38 over SIP. Thanks, S. Manivannan -----Original Message----- From: Gaurav Kheterpal [mailto:gkheterpal@ismartpanache.com]=20 Sent: Thursday, June 28, 2007 4:20 PM To: Manivannan S, TLS-Chennai; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: RE: [Sip-implementors] SIP and FAX You can refer to:- * RFC 4612 - Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration * http://www.iana.org/assignments/sdp-parameters * ITU-T T.38 Annexure D, Section 9 * draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00 - SDP Capability Negotiation: Requirements and Review of Existing Work Regards, Gaurav > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-=20 > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Manivannan S, > TLS-Chennai > Sent: Thursday, June 28, 2007 2:45 PM > To: sip-implementors@cs.columbia.edu; mmusic@ietf.org; Manivannan S,=20 > TLS- Chennai > Subject: [Sip-implementors] SIP and FAX >=20 >=20 > Hi all, >=20 >=20 >=20 > Could anybody tell me which latest RFC/draft is explaining FAX T.38=20 > over SIP and SDP? I have googled and found only expired drafts. >=20 >=20 >=20 > Thanks, >=20 > S. Manivannan >=20 >=20 >=20 > DISCLAIMER: > ---------------------------------------------------------------------- > ---- > --------------------------------------------- >=20 > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its=20 > affiliates. Any views or opinions presented in this email are solely=20 > those of the author and may not necessarily reflect the opinions of=20 > HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure,=20 > modification, distribution and / or publication of this message=20 > without the prior written consent of the author of this e- mail is=20 > strictly prohibited. If you have received this email in error please=20 > delete it and notify the sender immediately. Before opening any mail=20 > and attachments please check them for viruses and defect. >=20 > ---------------------------------------------------------------------- > ---- > --------------------------------------------- > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ments and Review of Existing Work Regards, Gaurav > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-=20 > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Manivannan S, > TLS-Chennai > Sent: Thursday, June 28, 2007 2:45 PM > To: sip-implementors@cs.columbia.edu; mmusic@ietf.org; Manivannan S,=20 > TLS- Chennai > Subject: [Sip-implementors] SIP and FAX >=20 >=20 > Hi all, >=20 >=20 >=20 > Could anybody tell me which latest RFC/draft is explaining FAX T.38=20 > over SIP and SDP? I have googled and found only expired drafts. >=20 >=20 >=20 > Thanks, >=20 > S. Manivannan >=20 >=20 >=20 > DISCLAIMER: > ---------------------------------------------------------------------- > ---- > --------------------------------------------- >=20 > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its=20 > affiliates. Any views or opinions presented in this email are solely=20 > those of the author and may not necessarily reflect the opinions of=20 > HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure,=20 > modification, distribution and / or publication of this message=20 > without the prior written consent of the author of this e- mail is=20 > strictly prohibited. If you have received this email in error please=20 > delete it and notify the sender immediately. Before opening any mail=20 > and attachments please check them for viruses and defect. >=20 > ---------------------------------------------------------------------- > ---- > --------------------------------------------- > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic