From abegen@cisco.com Sun Jun 12 15:15:36 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A6D11E8132 for ; Sun, 12 Jun 2011 15:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSN6zy+IBmen for ; Sun, 12 Jun 2011 15:15:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id CA34811E812D for ; Sun, 12 Jun 2011 15:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=459; q=dns/txt; s=iport; t=1307916935; x=1309126535; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=hT51Jzw1K3XEdGGcUIzYOSBGyub051Z0hRKT9IZwHls=; b=WuB7cMY2kZPNTrGf+qr5j6NQAtzcwSi5hAIjJQsRZjnnhkQAsPYLVEOj MoDvBnwuLqXGYTeP7Rf6SYLnmHRzKAc3CX9L6nV+aYnhJo0Zb2mmPegJu Q4kR9dPDjw5v9/JucTw2X9EfhlLX0vy6SrfPnB6lo20U46vRyoiEK07Aw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE459U2rRDoH/2dsb2JhbABSpk93qGyBH5x8hiQEhw2Of4sl X-IronPort-AV: E=Sophos;i="4.65,356,1304294400"; d="scan'208";a="335439020" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 12 Jun 2011 22:15:35 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5CMFZT4004200 for ; Sun, 12 Jun 2011 22:15:35 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 15:15:35 -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 Date: Sun, 12 Jun 2011 15:15:30 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F38FC7D@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised redundancy grouping semantics drafts Thread-Index: AcwpTba3qvKFKsQnTnGOfBv6srn/AQ== From: "Ali C. Begen (abegen)" To: "mmusic" X-OriginalArrivalTime: 12 Jun 2011 22:15:35.0464 (UTC) FILETIME=[4095AA80:01CC294E] Subject: [MMUSIC] Revised redundancy grouping semantics drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 22:15:36 -0000 Hi everyone, We revised the following two drafts: https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving= /=20 Drafts are almost complete for your review. Problems regarding RTCP = reporting have been addressed. I will be forwarding this email to = AVTCORE as well as there was a request that AVTCORE also reviewed these = drafts. Thanks. -acbegen From pasi.sarolahti@iki.fi Wed Jun 15 00:42:10 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F8011E80C5; Wed, 15 Jun 2011 00:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhqwg2HgCqDS; Wed, 15 Jun 2011 00:42:10 -0700 (PDT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by ietfa.amsl.com (Postfix) with ESMTP id 04E1111E809B; Wed, 15 Jun 2011 00:42:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 312A61E01D; Wed, 15 Jun 2011 10:42:08 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ENo1MKi-uNEB; Wed, 15 Jun 2011 10:42:03 +0300 (EEST) Received: from pc82.netlab.hut.fi (pc82.netlab.hut.fi [130.233.154.82]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id B23F21E01B; Wed, 15 Jun 2011 10:42:03 +0300 (EEST) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jun 2011 10:42:03 +0300 Message-Id: To: mmusic@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 15 Jun 2011 05:53:07 -0700 Cc: Gorry Fairhurst , DCCP WG , Colin Perkins Subject: [MMUSIC] Reviewing draft-ietf-dccp-udpencap X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 07:42:11 -0000 Hi, In DCCP WG we are soon concluding draft-ietf-dccp-udpencap ("Datagram = Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal = (DCCP-UDP)"). This draft has parts related to the work done in MMUSIC = (especially Section 5), and it was presented in the MMUSIC meeting in = last IETF. The authors have modified the text based on the input = received, and we are now looking for volunteer(s) from MMUSIC to review = whether the new text (mostly in Section 5) looks ok, before moving = forward with the draft. The draft can be found at = http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08=20 - Pasi From miguel.a.garcia@ericsson.com Wed Jun 15 06:32:39 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E8011E812F; Wed, 15 Jun 2011 06:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfcoTlGdI8af; Wed, 15 Jun 2011 06:32:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AF82611E8126; Wed, 15 Jun 2011 06:32:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-87-4df8b4745c08 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 49.BB.20773.474B8FD4; Wed, 15 Jun 2011 15:32:36 +0200 (CEST) Received: from [159.107.24.230] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 15 Jun 2011 15:32:35 +0200 Message-ID: <4DF8B472.9090602@ericsson.com> Date: Wed, 15 Jun 2011 15:32:34 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pasi Sarolahti References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Gorry Fairhurst , DCCP WG , "mmusic@ietf.org" , Colin Perkins Subject: Re: [MMUSIC] Reviewing draft-ietf-dccp-udpencap X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:32:39 -0000 A quick review of Section 5 of this document: - I think it is a good idea to clearly indicate which SDP attributes are newly created and which ones are reused from other RFCs. I therefore recommend to add the following sentences somewhere to the corresponding sections: 5.3: RFC 4145 [RFC4145] defines the "setup" attribute whose purpose is to indcate which of the end points should initiate the connection establishment. This document reuses the "setup" attribute to similarly indicate which end point initiates the DCCP-UDP connection establishment. 5.4: RFC 5245 [RFC5245] defines the "candidate" attribute whose purpose is to provide one of many possible candidate addresses for communication. This document reuses the "candidate" attribute to indicate native or encapsulated candidate addresses - In 5.2 last paragraph, I am missing some normative statements, for example: If RTCP is multiplexed with RTP, endpoints MUST encode the DCCP port used for RTCP in the "rtcp" attribute specified in RFC 3605 [RFC3605]. An SDP offerer MAY indicate its willingnes to multiplex RTP and RTCP onto a single DCCP port by adding an "rtcp-mux" attribute as specified in RFC 5761 [RFC5761]. If the answer also includes the "rtcp-mux" attribute (as per RFC 5761 [RFC5761]), then RTP and RTCP are multiplexed onto a single DCCP port, otherwise separate DCCP ports are used for RTP and RTCP. In each case, only a single UDP port is used for the DCCP-UDP encapsulation. - I didn't find any description of the "dccp-service-code". However, it is written in the examples in Section 5.5. Is this a leftover from a previous version of the document? - I agree with your comment at the end of Section 5.5 indicating that an example using ICE would be beneficial. - Section 7.3. There are two references pointing to Section 5.1 in the document, but they should actually point to Section 5.2 - I think the following references should be made normative: ICE-TCP, RFC3264, RFC 4566, RFC5245, RFC5761 BR, Miguel On 15/06/2011 9:42, Pasi Sarolahti wrote: > Hi, > > In DCCP WG we are soon concluding draft-ietf-dccp-udpencap ("Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)"). This draft has parts related to the work done in MMUSIC (especially Section 5), and it was presented in the MMUSIC meeting in last IETF. The authors have modified the text based on the input received, and we are now looking for volunteer(s) from MMUSIC to review whether the new text (mostly in Section 5) looks ok, before moving forward with the draft. > > The draft can be found at http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08 > > - Pasi > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Jun 15 23:09:51 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149FD11E8184 for ; Wed, 15 Jun 2011 23:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOBch3LzWQaN for ; Wed, 15 Jun 2011 23:09:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F402F11E81A1 for ; Wed, 15 Jun 2011 23:09:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e2-4df99e2be802 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BD.E1.09774.B2E99FD4; Thu, 16 Jun 2011 08:09:48 +0200 (CEST) Received: from [159.107.24.192] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 16 Jun 2011 08:09:47 +0200 Message-ID: <4DF99E2B.6080202@ericsson.com> Date: Thu, 16 Jun 2011 08:09:47 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] Unofficial WGLC for draft-salgueiro-mmusic-image-iana-registration-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 06:09:51 -0000 This is to start a 4-week unofficial WGLC of the IANA registration of the image media type in SDP, http://datatracker.ietf.org/doc/draft-salgueiro-mmusic-image-iana-registration/ This document is going to proceed through the individually submitted, AD-sponsored track. However, the draft came as a requirements of the MMUSIC WG, has been substantially reviewed in MMUSIC, therefore the chairs want to have a last review in the format of an unofficial WGLC. Please review the draft, and send comments to the authors and the list. Even if you don't have comments because you are happy with the current document, please say so. The deadline for receiving comments is July 14th. /Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gorry@erg.abdn.ac.uk Thu Jun 16 00:42:43 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBBD11E80B8; Thu, 16 Jun 2011 00:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzggLhHJXYCb; Thu, 16 Jun 2011 00:42:43 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 9FECA11E8078; Thu, 16 Jun 2011 00:42:41 -0700 (PDT) Received: from don.erg.abdn.ac.uk (don.erg.abdn.ac.uk [139.133.204.83]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p5G7gC6n008013; Thu, 16 Jun 2011 08:42:13 +0100 (BST) Date: Thu, 16 Jun 2011 08:42:12 +0100 (BST) From: Gorry Fairhurst To: "Miguel A. Garcia" In-Reply-To: <4DF8B472.9090602@ericsson.com> Message-ID: References: <4DF8B472.9090602@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: Pasi Sarolahti , DCCP WG , "mmusic@ietf.org" , Colin Perkins Subject: Re: [MMUSIC] [dccp] Reviewing draft-ietf-dccp-udpencap X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 07:42:44 -0000 See in-line on dccp-service-code. Gorry On Wed, 15 Jun 2011, Miguel A. Garcia wrote: > A quick review of Section 5 of this document: > > - I think it is a good idea to clearly indicate which SDP attributes are > newly created and which ones are reused from other RFCs. I therefore > recommend to add the following sentences somewhere to the corresponding > sections: > > 5.3: > RFC 4145 [RFC4145] defines the "setup" attribute whose purpose is to indcate > which of the end points should initiate the connection establishment. This > document reuses the "setup" attribute to similarly indicate which end point > initiates the DCCP-UDP connection establishment. > > 5.4: > RFC 5245 [RFC5245] defines the "candidate" attribute whose purpose is to > provide one of many possible candidate addresses for communication. This > document reuses the "candidate" attribute to indicate native or encapsulated > candidate addresses > > [After re-reading this I note that this section speaks of "native" DCCP whereas there was an earlier suggestion that this should be called "DCCP-STD", Colin and I should ensure this is consistent in the next revision.] > - In 5.2 last paragraph, I am missing some normative statements, for example: > > If RTCP is multiplexed with RTP, endpoints MUST encode the DCCP port used for > RTCP in the "rtcp" attribute specified in RFC 3605 [RFC3605]. An SDP offerer > MAY indicate its willingnes to multiplex RTP and RTCP onto a single DCCP port > by adding an "rtcp-mux" attribute as specified in RFC 5761 [RFC5761]. If the > answer also includes the "rtcp-mux" attribute (as per RFC 5761 [RFC5761]), > then RTP and RTCP are multiplexed onto a single DCCP port, otherwise separate > DCCP ports are used for RTP and RTCP. In each case, only a single UDP port > is used for the DCCP-UDP encapsulation. > > - I didn't find any description of the "dccp-service-code". However, it is > written in the examples in Section 5.5. Is this a leftover from a previous > version of the document? > I suggest a couple of lines to be clear to anyone composing SDP: RFC 5762 [RFC5762] defines the "dccp-service-code" attribute whose purpose is to identify the intended service/application to process a DCCP connection request [RFC5595]. The "dccp-service-code" attribute is the same for both DCCP-STD and DCCP-UDP encapsulations. > - I agree with your comment at the end of Section 5.5 indicating that an > example using ICE would be beneficial. > So, as soon as we have this, I think we can then finalise the text! > - Section 7.3. There are two references pointing to Section 5.1 in the > document, but they should actually point to Section 5.2 > Noted, will fix. > - I think the following references should be made normative: ICE-TCP, > RFC3264, RFC 4566, RFC5245, RFC5761 > Seems OK to me, I'll see if Colin agrees. > BR, > > Miguel > > > On 15/06/2011 9:42, Pasi Sarolahti wrote: >> Hi, >> >> In DCCP WG we are soon concluding draft-ietf-dccp-udpencap ("Datagram >> Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal >> (DCCP-UDP)"). This draft has parts related to the work done in MMUSIC >> (especially Section 5), and it was presented in the MMUSIC meeting in last >> IETF. The authors have modified the text based on the input received, and >> we are now looking for volunteer(s) from MMUSIC to review whether the new >> text (mostly in Section 5) looks ok, before moving forward with the draft. >> >> The draft can be found at >> http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08 >> >> - Pasi >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > From miguel.a.garcia@ericsson.com Thu Jun 16 01:28:22 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A13911E807B; Thu, 16 Jun 2011 01:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT6xqGdjZLGA; Thu, 16 Jun 2011 01:28:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5D011E80C0; Thu, 16 Jun 2011 01:28:21 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a5-4df9bea4ddf6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BE.7C.20773.4AEB9FD4; Thu, 16 Jun 2011 10:28:20 +0200 (CEST) Received: from [159.107.24.192] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 16 Jun 2011 10:28:13 +0200 Message-ID: <4DF9BE9C.1060200@ericsson.com> Date: Thu, 16 Jun 2011 10:28:12 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gorry Fairhurst References: <4DF8B472.9090602@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Pasi Sarolahti , DCCP WG , "mmusic@ietf.org" , Colin Perkins Subject: Re: [MMUSIC] [dccp] Reviewing draft-ietf-dccp-udpencap X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 08:28:22 -0000 Hi Gorry: Your suggestions look ok to me. BR, Miguel On 16/06/2011 9:42, Gorry Fairhurst wrote: > > See in-line on dccp-service-code. > > Gorry > > On Wed, 15 Jun 2011, Miguel A. Garcia wrote: > >> A quick review of Section 5 of this document: >> >> - I think it is a good idea to clearly indicate which SDP attributes are >> newly created and which ones are reused from other RFCs. I therefore >> recommend to add the following sentences somewhere to the corresponding >> sections: >> >> 5.3: >> RFC 4145 [RFC4145] defines the "setup" attribute whose purpose is to indcate >> which of the end points should initiate the connection establishment. This >> document reuses the "setup" attribute to similarly indicate which end point >> initiates the DCCP-UDP connection establishment. >> >> 5.4: >> RFC 5245 [RFC5245] defines the "candidate" attribute whose purpose is to >> provide one of many possible candidate addresses for communication. This >> document reuses the "candidate" attribute to indicate native or encapsulated >> candidate addresses >> >> > [After re-reading this I note that this section speaks of "native" DCCP > whereas there was an earlier suggestion that this should be called > "DCCP-STD", Colin and I should ensure this is consistent in the next > revision.] > >> - In 5.2 last paragraph, I am missing some normative statements, for example: >> >> If RTCP is multiplexed with RTP, endpoints MUST encode the DCCP port used for >> RTCP in the "rtcp" attribute specified in RFC 3605 [RFC3605]. An SDP offerer >> MAY indicate its willingnes to multiplex RTP and RTCP onto a single DCCP port >> by adding an "rtcp-mux" attribute as specified in RFC 5761 [RFC5761]. If the >> answer also includes the "rtcp-mux" attribute (as per RFC 5761 [RFC5761]), >> then RTP and RTCP are multiplexed onto a single DCCP port, otherwise separate >> DCCP ports are used for RTP and RTCP. In each case, only a single UDP port >> is used for the DCCP-UDP encapsulation. >> >> - I didn't find any description of the "dccp-service-code". However, it is >> written in the examples in Section 5.5. Is this a leftover from a previous >> version of the document? >> > I suggest a couple of lines to be clear to anyone composing SDP: > > RFC 5762 [RFC5762] defines the "dccp-service-code" attribute whose purpose > is to identify the intended service/application to process a DCCP > connection request [RFC5595]. The "dccp-service-code" attribute is the > same for both DCCP-STD and DCCP-UDP encapsulations. > >> - I agree with your comment at the end of Section 5.5 indicating that an >> example using ICE would be beneficial. >> > > So, as soon as we have this, I think we can then finalise the text! > >> - Section 7.3. There are two references pointing to Section 5.1 in the >> document, but they should actually point to Section 5.2 >> > Noted, will fix. > >> - I think the following references should be made normative: ICE-TCP, >> RFC3264, RFC 4566, RFC5245, RFC5761 >> > Seems OK to me, I'll see if Colin agrees. > >> BR, >> >> Miguel >> >> >> On 15/06/2011 9:42, Pasi Sarolahti wrote: >>> Hi, >>> >>> In DCCP WG we are soon concluding draft-ietf-dccp-udpencap ("Datagram >>> Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal >>> (DCCP-UDP)"). This draft has parts related to the work done in MMUSIC >>> (especially Section 5), and it was presented in the MMUSIC meeting in last >>> IETF. The authors have modified the text based on the input received, and >>> we are now looking for volunteer(s) from MMUSIC to review whether the new >>> text (mostly in Section 5) looks ok, before moving forward with the draft. >>> >>> The draft can be found at >>> http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08 >>> >>> - Pasi >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From kpfleming@digium.com Thu Jun 16 08:10:54 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DAE9E802E for ; Thu, 16 Jun 2011 08:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpQtU0qR391g for ; Thu, 16 Jun 2011 08:10:44 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id BBF541F0C34 for ; Thu, 16 Jun 2011 08:10:43 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1QXEDS-00048G-UC for mmusic@ietf.org; Thu, 16 Jun 2011 10:10:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id E6658D82AC for ; Thu, 16 Jun 2011 10:10:42 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs-KuH+zQjzZ for ; Thu, 16 Jun 2011 10:10:42 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 5ABD7D82A3 for ; Thu, 16 Jun 2011 10:10:42 -0500 (CDT) Message-ID: <4DFA1CF2.7090404@digium.com> Date: Thu, 16 Jun 2011 10:10:42 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: mmusic@ietf.org References: <4DF99E2B.6080202@ericsson.com> In-Reply-To: <4DF99E2B.6080202@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Unofficial WGLC for draft-salgueiro-mmusic-image-iana-registration-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 15:10:54 -0000 On 06/16/2011 01:09 AM, Miguel A. Garcia wrote: > This is to start a 4-week unofficial WGLC of the IANA registration of > the image media type in SDP, > > http://datatracker.ietf.org/doc/draft-salgueiro-mmusic-image-iana-registration/ > > > This document is going to proceed through the individually submitted, > AD-sponsored track. However, the draft came as a requirements of the > MMUSIC WG, has been substantially reviewed in MMUSIC, therefore the > chairs want to have a last review in the format of an unofficial WGLC. > > Please review the draft, and send comments to the authors and the list. > Even if you don't have comments because you are happy with the current > document, please say so. I have already reviewed this document and am satisfied it should proceed through the process. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From Bert.Greevenbosch@huawei.com Thu Jun 16 18:58:32 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7813811E80F8 for ; Thu, 16 Jun 2011 18:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV+gtHtrFQJk for ; Thu, 16 Jun 2011 18:58:32 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DC1D211E80F7 for ; Thu, 16 Jun 2011 18:58:31 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMW00D8CW5JBT@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 17 Jun 2011 09:58:31 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMW001O3W5J28@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 17 Jun 2011 09:58:31 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 17 Jun 2011 09:58:19 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.140]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Fri, 17 Jun 2011 09:58:30 +0800 Date: Fri, 17 Jun 2011 01:58:29 +0000 From: Bert Greevenbosch In-reply-to: <4DF99E2B.6080202@ericsson.com> X-Originating-IP: [10.70.109.57] To: "Miguel A. Garcia" , mmusic Message-id: <46A1DF3F04371240B504290A071B4DB601300A97@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Unofficial WGLC for draft-salgueiro-mmusic-image-iana-registration-07.txt Thread-index: AQHMK+wo3ff+LyvLokW8WEpx72ZS2ZTAyZkA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DF99E2B.6080202@ericsson.com> Cc: Flemming Andreasen Subject: Re: [MMUSIC] Unofficial WGLC for draft-salgueiro-mmusic-image-iana-registration-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 01:58:32 -0000 I have reviewed the document and am happy with the current version. Best regards, Bert -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia Sent: 16 June 2011 14:10 To: mmusic Cc: Flemming Andreasen Subject: [MMUSIC] Unofficial WGLC for draft-salgueiro-mmusic-image-iana-registration-07.txt This is to start a 4-week unofficial WGLC of the IANA registration of the image media type in SDP, http://datatracker.ietf.org/doc/draft-salgueiro-mmusic-image-iana-registration/ This document is going to proceed through the individually submitted, AD-sponsored track. However, the draft came as a requirements of the MMUSIC WG, has been substantially reviewed in MMUSIC, therefore the chairs want to have a last review in the format of an unofficial WGLC. Please review the draft, and send comments to the authors and the list. Even if you don't have comments because you are happy with the current document, please say so. The deadline for receiving comments is July 14th. /Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From Bert.Greevenbosch@huawei.com Thu Jun 16 19:33:07 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C69821F84EE for ; Thu, 16 Jun 2011 19:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAOyZE5g9lVo for ; Thu, 16 Jun 2011 19:33:06 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 492A621F84ED for ; Thu, 16 Jun 2011 19:33:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMW003NSXP427@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 17 Jun 2011 10:31:52 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMW00MPSXP4M7@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 17 Jun 2011 10:31:52 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 17 Jun 2011 10:31:42 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.140]) by szxeml411-hub.china.huawei.com ([169.254.8.131]) with mapi id 14.01.0270.001; Fri, 17 Jun 2011 10:31:37 +0800 Date: Fri, 17 Jun 2011 02:31:35 +0000 From: Bert Greevenbosch X-Originating-IP: [10.70.109.57] To: mmusic Message-id: <46A1DF3F04371240B504290A071B4DB601300ABD@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8zh3vwfQ5jnH+XAo1w9oIQ)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: Intention of asking for WG adoption of the 3D drafts in Quebec Thread-index: Acwslq2KSAD2dhRKShm+VHi2FfP9Fw== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [MMUSIC] Intention of asking for WG adoption of the 3D drafts in Quebec X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 02:33:07 -0000 --Boundary_(ID_8zh3vwfQ5jnH+XAo1w9oIQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello all, Some time ago, I have uploaded two new versions of the 3D drafts: https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-parallax-attribute/ https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/ It is my intention to ask for WG adoption of the drafts in Quebec. A brief summary of the changes in the v01s: draft-greevenbosch-mmusic-parallax-attribute: The unit of the "ParallaxInfo" attribute value has been normalised to "pixels on a screen with a width of 11520 pixels". This allows adjusting the parallax for various screen sizes, often by dividing through an integer number. draft-greevenbosch-mmusic-signal-3d-format: Added two sections for the SDP offer/answer model. Section 7 considers behaviour for the compliant device, whereas section 8 considers backward compatibility with a legacy device. For backwards compatibility with legacy devices, generally the system will fall back to 2D streaming. This sometimes requires re-negotiation. I look forward to your comments and (continued) support! Best regards, Bert --Boundary_(ID_8zh3vwfQ5jnH+XAo1w9oIQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello all,

 

Some time ago, I have uploaded two new versions of the 3D drafts:

 

https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-parallax-attribute/

https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/

 

It is my intention to ask for WG adoption of the drafts in Quebec.

 

A brief summary of the changes in the v01s:

 

draft-greevenbosch-mmusic-parallax-attribute:

The unit of the "ParallaxInfo" attribute value has been normalised to "pixels on a screen with a width of 11520 pixels".

This allows adjusting the parallax for various screen sizes, often by dividing through an integer number.

 

draft-greevenbosch-mmusic-signal-3d-format:

Added two sections for the SDP offer/answer model. Section 7 considers behaviour for the compliant device, whereas section 8 considers backward compatibility with a legacy device.

For backwards compatibility with legacy devices, generally the system will fall back to 2D streaming. This sometimes requires re-negotiation.

 

I look forward to your comments and (continued) support!

 

Best regards,

Bert

--Boundary_(ID_8zh3vwfQ5jnH+XAo1w9oIQ)-- From miguel.a.garcia@ericsson.com Mon Jun 27 07:28:07 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA0E21F8629 for ; Mon, 27 Jun 2011 07:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbv+zZ9NPAwf for ; Mon, 27 Jun 2011 07:28:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BCCE021F860C for ; Mon, 27 Jun 2011 07:28:06 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ba-4e085c0da95f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BE.4E.20773.D0C580E4; Mon, 27 Jun 2011 12:31:41 +0200 (CEST) Received: from [159.107.24.212] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 27 Jun 2011 12:31:41 +0200 Message-ID: <4E085C0D.7070707@ericsson.com> Date: Mon, 27 Jun 2011 12:31:41 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] MMUSIC session at IETF 81 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:28:07 -0000 Hi: We just got an e-mail from the IETF secretariat indicating our schedule for IETF 81. There is something weird, because the chairs asked for a 2.5 hours time slot, but we've got a 1.5 hours (in spite the e-mail from the IETF secretariat says 2.5). We are trying to clarify this issue. The fact is that we are schedule for Tuesday 1520-1700: MMUSIC Session 1 (2.5 hours) Tuesday, Afternoon Session II 1520-1700 Room Name: 204 B Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Mon Jun 27 23:59:49 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070C821F86C7 for ; Mon, 27 Jun 2011 23:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Yh9o-AXU21H for ; Mon, 27 Jun 2011 23:59:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4221F86BF for ; Mon, 27 Jun 2011 23:59:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-77-4e097be26fe1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 84.D2.09774.2EB790E4; Tue, 28 Jun 2011 08:59:47 +0200 (CEST) Received: from [159.107.25.3] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 28 Jun 2011 08:59:46 +0200 Message-ID: <4E097BE1.30904@ericsson.com> Date: Tue, 28 Jun 2011 08:59:45 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] Agenda requests for IETF 81 Quebec city X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 06:59:49 -0000 All, We are getting close to IETF 81 in Quebec City, and we need to start drafting the agenda for MMUSIC. If you want to request a time slot for discussing an item, please send an e-mail to Flemming and myself, including: - Topic to be discussed - Amount of time requested - Reference to existing (or expected) draft. While the chairs will make the best to accommodate all requests, please bear in mind that the face to face meeting time is a scarce resource. As such, we will prioritize controversial issues that could not be solved in the mailing list and chartered work. We also encourage people to post issues on the mailing list in advance to stimulate the discussions, make the draft advertised, and solve as many issues as possible on the mailing list. Thanks, Flemming and Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Tue Jun 28 23:02:46 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1FF11E8089 for ; Tue, 28 Jun 2011 23:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0K7jinRQ+wqB for ; Tue, 28 Jun 2011 23:02:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3019E11E8074 for ; Tue, 28 Jun 2011 23:02:46 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1a-4e0ac005258f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9B.64.20773.500CA0E4; Wed, 29 Jun 2011 08:02:45 +0200 (CEST) Received: from [159.107.24.242] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 29 Jun 2011 08:02:44 +0200 Message-ID: <4E0AC004.6010705@ericsson.com> Date: Wed, 29 Jun 2011 08:02:44 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mmusic References: <4E085C0D.7070707@ericsson.com> In-Reply-To: <4E085C0D.7070707@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: Re: [MMUSIC] MMUSIC session at IETF 81 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 06:02:47 -0000 Just to let you know that MMUSIC have been successfully rescheduled to Friday 0900-1130 (same time slot as in Prague). So we have 2.5 hours for our meeting. /Miguel On 27/06/2011 12:31, Miguel A. Garcia wrote: > Hi: > > We just got an e-mail from the IETF secretariat indicating our schedule > for IETF 81. There is something weird, because the chairs asked for a 2.5 > hours time slot, but we've got a 1.5 hours (in spite the e-mail from the > IETF secretariat says 2.5). We are trying to clarify this issue. > > The fact is that we are schedule for Tuesday 1520-1700: > > > MMUSIC Session 1 (2.5 hours) > Tuesday, Afternoon Session II 1520-1700 > Room Name: 204 B > > > Miguel > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Jun 29 23:50:49 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5BD11E8131 for ; Wed, 29 Jun 2011 23:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhU30VMi15LP for ; Wed, 29 Jun 2011 23:50:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C746B11E80E1 for ; Wed, 29 Jun 2011 23:50:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e7-4e0c1cc6a82e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 91.95.09774.6CC1C0E4; Thu, 30 Jun 2011 08:50:47 +0200 (CEST) Received: from [159.107.24.245] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 30 Jun 2011 08:50:46 +0200 Message-ID: <4E0C1CC5.1010508@ericsson.com> Date: Thu, 30 Jun 2011 08:50:45 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mmusic References: <4DF99E2B.6080202@ericsson.com> In-Reply-To: <4DF99E2B.6080202@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: Re: [MMUSIC] Unofficial WGLC for draft-salgueiro-mmusic-image-iana-registration-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 06:50:49 -0000 A reminder to all of us that we are under a 4-week unofficial WGLC of the draft mentioned in the title. There are 2 weeks left. We would like to here comments, even those are merely indicating that you agree with the draft. /Miguel On 16/06/2011 8:09, Miguel A. Garcia wrote: > This is to start a 4-week unofficial WGLC of the IANA registration of the > image media type in SDP, > > http://datatracker.ietf.org/doc/draft-salgueiro-mmusic-image-iana-registration/ > > This document is going to proceed through the individually submitted, > AD-sponsored track. However, the draft came as a requirements of the > MMUSIC WG, has been substantially reviewed in MMUSIC, therefore the > chairs want to have a last review in the format of an unofficial WGLC. > > Please review the draft, and send comments to the authors and the list. > Even if you don't have comments because you are happy with the current > document, please say so. > > The deadline for receiving comments is July 14th. > > /Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From john.elwell@siemens-enterprise.com Thu Jun 30 00:51:53 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5DA21F86E8 for ; Thu, 30 Jun 2011 00:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.359 X-Spam-Level: X-Spam-Status: No, score=-106.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0pnC6mALoQi for ; Thu, 30 Jun 2011 00:51:53 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id B0ED021F8779 for ; Thu, 30 Jun 2011 00:51:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1309420311!23186586!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 15837 invoked from network); 30 Jun 2011 07:51:51 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-174.messagelabs.com with SMTP; 30 Jun 2011 07:51:51 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 5967D1EB83EF for ; Thu, 30 Jun 2011 09:51:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 30 Jun 2011 09:51:51 +0200 From: "Elwell, John" To: mmusic Date: Thu, 30 Jun 2011 09:51:50 +0200 Thread-Topic: Revised ice-updated-offer draft Thread-Index: Acwa7j+1tLPewP+cRFGXOIbZmer2LQcC1w+A Message-ID: Keywords: MMUSIC Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Revised ice-updated-offer draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 07:51:53 -0000 I received no comments on -01. To prepare for a meaningful discussion in Qu= ebec, it would be good to start that discussion now, on the list. In partic= ular, the Conclusions section ends with the statement: " According to discussions in section Section 4, it seems to be the case that the updated offer is needed, in practice, in very few environments, and therefore consideration should be given to relaxing the requirement in [RFC5245]." What would be people's reactions to updating RFC 5245 to relax this require= ment? John =20 > -----Original Message----- > From: Elwell, John=20 > Sent: 25 May 2011 16:13 > To: mmusic > Cc: Stach, Thomas; Hutton, Andrew > Subject: Revised ice-updated-offer draft >=20 > Version 01 has been posted: > https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updat ed-offer/ >=20 > Compared with 00, this attempts to reflect the discussions in=20 > Prague, including: > - avoidance of the term "middlebox"; > - discussion of 100rel and pre-conditions as possible=20 > solution to fax problem; > - noted that the 3PCC issue exists anyway without ICE, but is=20 > more likely to arise with ICE; > - new section 4 on whether we really need the updated offer; > - revised conclusion section, suggesting relaxing the=20 > requirement for the ICE updated offer. >=20 > Comments welcome. >=20 > John > = From petithug@acm.org Thu Jun 30 11:26:47 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE44B9E8019 for ; Thu, 30 Jun 2011 11:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3TKXfHsI3yn for ; Thu, 30 Jun 2011 11:26:47 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF5A9E8014 for ; Thu, 30 Jun 2011 11:26:47 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 8A312226E9 for ; Thu, 30 Jun 2011 20:26:08 +0200 (CEST) Message-ID: <4E0CBFE3.7000704@acm.org> Date: Thu, 30 Jun 2011 11:26:43 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: "mmusic@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Fwd: I-D Action: draft-petithuguenin-mmusic-ice-attributes-level-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:26:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There was some interest in this draft during the meeting in Prague but unfortunately no comment since. Changelog: o Changed the rtp+ecn aggregation rule so that non-ICE media are not used when aggregating. o Filled Security and IANA sections. o Added examples of aggregation. o Added a design note about using different attribute name at media level. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-mmusic-ice-attributes-level-01.txt Date: Thu, 30 Jun 2011 11:23:04 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Media level ice-options SDP attribute Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-mmusic-ice-attributes-level-01.txt Pages : 11 Date : 2011-06-30 This document redefines the ice-options SDP attribute as a session- level and media-level attribute. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-mmusic-ice-attributes-level-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-mmusic-ice-attributes-level-01.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4Mv9AACgkQ9RoMZyVa61eB+QCeMkFy2J0ujN9ph8PGbRbVBy26 hdIAnAwmAU2IkRWCdz25wO3IE31NHF88 =Rx3/ -----END PGP SIGNATURE----- From D.Hancock@CableLabs.com Thu Jun 30 19:19:18 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF27911E80C7 for ; Thu, 30 Jun 2011 19:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.838 X-Spam-Level: X-Spam-Status: No, score=0.838 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31+xPCWZ5Ngm for ; Thu, 30 Jun 2011 19:19:17 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id D9BD911E809C for ; Thu, 30 Jun 2011 19:19:16 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p612JFmD003423 for ; Thu, 30 Jun 2011 20:19:15 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 30 Jun 2011 20:19:15 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 30 Jun 2011 20:19:16 -0600 From: David Hancock To: "mmusic@ietf.org" Date: Thu, 30 Jun 2011 20:19:15 -0600 Thread-Topic: Questions on ICE-lite procedure Thread-Index: AQHMN5VGpAOGAC0EnUqZ3LuVkphy+A== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81899340FD@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F81899340FDsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [MMUSIC] Questions on ICE-lite procedure X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 02:19:18 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F81899340FDsrvxchg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have a question on the RFC5245 ICE-lite procedures (three questions actua= lly, inline below). Consider the case where two SIP endpoints, UA-1 and UA-2, are both dual sta= ck. The endpoints support ICE-lite to negotiate media IP version during ses= sion establishment. UA-1 and UA-2 have the following locally configured ICE= -lite policies=85 UA-1: - Default candidate is IPv4 - Preferred IP version when selecting valid candidate pair is IPv6 UA-2 - Default candidate is IPv6 - Preferred IP version when selecting valid candidate pair is IPv4 Here=92s the call establishment message flow (for simplicity, shows candida= tes only for RTP component). UA-1 UA-2 ----- ----- [1]INVITE SDP-offer ---> c=3D IPv4 addr-1 m =3D IPv4 port-1 a=3Dice-lite a=3Dcandidate-1 IPv4 addr1 a=3Dcandidate-2 IPv6 addr1 (all IP addresses in [1] are host addresses on UA-1) [2] 183-Progress SDP-preview <--- c=3DIPv6 addr-2 m =3D IPv6 port-2 a=3Dice-lite a=3Dcandidate-1 IPv6 addr-2 a=3Dcandidate-2 IPv4 addr-2 (all IP addresses in [2] are host addresses on UA-2) UA-1 and UA 2 now pair the local and remote candidates, and come up with tw= o candidate pairs; an IPv4 pair and an IPv6 pair. Once the candidate pairs have been created, UA-1 and UA-2 then independentl= y select a valid candidate pair. Based on their locally configured policy s= ettings, UA-1 selects the IPv6 pair, while UA-2 selects the IPv4 pair. Both= UAs listen for media on both candidate pairs, but send media only on their= selected/valid candidate pairs. Therefore, the early-media media stream is= asymmetrical w.r.t. IP version. ------ early media via IPv6 -------> <----- early media via IPv4 ------- Question-1: ICE-lite doesn=92t explicitly describe this early-media behavio= r, but should it be expected to work as shown above? Eventually, the call is answered. SDP is same as in [2]. [3] 200OK SDP-answer <--- c=3DIPv6 addr-2 m =3D IPv6 port-2 a=3Dice-lite a=3Dcandidate-1 IPv6 addr-2 a=3Dcandidate-2 IPv4 addr-2 [4]ACK ---> UA-1, in its ICE-lite role as controlling agent, sends updated offer to UA-= 2, based on the following text in section 8.2.2. * To reconcile this, the controlling agent MUST send an updated offer as described in Section 9.1.3, which will include the remote-candidates attribute. * The agent MUST NOT update the state of ICE processing when the offer is sent. If this subsequent offer completes, the controlling agent MUST change the state of ICE processing to Completed for all media streams, and the state of ICE processing overall to Completed. The states for the controlled agent are set based on the logic in Section 9.2.3. Section 9.1.3 has two subsections; 9.1.3.1 when ICE is running, and 9.1.3.2= when ICE is completed. The 2nd bullet above indicates that at this stage I= CE is still running, which means do 9.1.3.1. However, 9.1.3.1 sends the exa= ct same SDP-offer that was sent back in message [1], with no remote-candida= te attribute. I think the correct procedure at this point is 9.1.3.2, since= it updates the default candidate in the SDP offer to indicate what candida= te pair was selected by UA-1, and includes the remote-candidate attribute. Question-2: Is this an error in the RFC? If not, how does this subsequent o= ffer/answer tell the controlled agent to start using the candidate pair sel= ected by the controlling agent? Or is it the intention of this procedure to= simply let the controlled and controlling agents use different candidates = for the established session (as they were during early media)? I *think* the offer/answer should look like this (i.e., should follow proce= dure in section 9.1.3.2)=85 [5] INVITE SDP offer ---> c=3D IPv6 addr-1 m =3D IPv6 port-1 a=3Dice-lite a=3Dcandidate-1 IPv4 addr1 a=3Dcandidate-2 IPv6 addr1 a=3Dremote-candidate IPv6 addr-2 Per RFC5245 section 9.2.3, UA-2 sets its remote candidate to the default de= stination (c=3D line) received in the SDP offer, and its local candidate eq= ual to the remote candidate received in the SDP offer. It then adds this ca= ndidate pair to its valid candidate list, and generates an SDP answer based= on this valid candidate. [6] 200OK SDP answer <--- c=3D IPv6 addr-2 m =3D IPv6 port-2 a=3Dice-lite a=3Dcandidate-1 IPv6 addr-2 a=3Dcandidate-2 IPv4 addr-2 a=3Dremote-candidate IPv6 addr-1 [7]ACK ---> If the above is correct (i.e., compliant with RFC5245) then I think ICE-lit= e procedure ensures that the established media stream is symmetrical in sen= d/receive direction w.r.t. IP version. Question-3: Does the ICE-lite procedure in fact guarantee IP version symmet= ry in the established (not early) media streams? Thanks David --_000_76AC5FEF83F1E64491446437EA81A61F81899340FDsrvxchg_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I = have a question on the RFC5245 ICE-lite procedures (three questions actuall= y, inline below).
 
Co= nsider the case where two SIP endpoints, UA-1 and UA-2, are both dual stack= . The endpoints support ICE-lite to negotiate media IP version during sessi= on establishment. UA-1 and UA-2 have the following locally configured ICE-lite policies=85
 
UA= -1:
- Default candidate is IPv4
- Preferred IP version when selecting valid candidate pair is IPv6
 
UA= -2
- Default candidate is IPv6
- Preferred IP version when selecting valid candidate pair is IPv4
 
He= re=92s the call establishment message flow (for simplicity, shows candidate= s only for RTP component).
 
UA= -1            &= nbsp;           &nbs= p;    UA-2
-----           &nbs= p;            &= nbsp;   -----
   [1]INVITE  SDP-offer --->
         c=3D IPv4 addr-1
         m =3D IPv4 port-1
         a=3Dice-lite
         a=3Dcandidate-1 IPv4 addr1=
         a=3Dcandidate-2 IPv6 addr1=

(all IP addresses in [1] are host addresses on UA-1)
 
&n= bsp;  [2] 183-Progress SDP-preview <---
         c=3DIPv6 addr-2
         m =3D IPv6 port-2
         a=3Dice-lite
         a=3Dcandidate-1 IPv6 addr-= 2
         a=3Dcandidate-2 IPv4 addr-= 2
(a= ll IP addresses in [2] are host addresses on UA-2)
 
UA= -1 and UA 2 now pair the local and remote candidates, and come up with two = candidate pairs; an IPv4 pair and an IPv6 pair.
 
On= ce the candidate pairs have been created, UA-1 and UA-2 then independently = select a valid candidate pair. Based on their locally configured polic= y settings, UA-1 selects the IPv6 pair, while UA-2 selects the IPv4 pair. Both UAs listen for media on both candidate pa= irs, but send media only on their selected/valid candidate pairs. Therefore= , the early-media media stream is asymmetrical w.r.t. IP version.
 
--= ---- early media via IPv6 ------->
<----- early media via IPv4 -------
 
Question-1: ICE-lite doesn=92t explicitly describe this earl= y-media behavior, but should it be expected to work as shown above?<= /div>
 
Ev= entually, the call is answered. SDP is same as in [2].
 
&n= bsp;  [3] 200OK SDP-answer <---
         c=3DIPv6 addr-2
         m =3D IPv6 port-2
         a=3Dice-lite
         a=3Dcandidate-1 IPv6 addr-= 2
         a=3Dcandidate-2 IPv4 addr-= 2
 
&n= bsp;  [4]ACK --->
 
UA= -1, in its ICE-lite role as controlling agent, sends updated offer to UA-2,= based on the following text in section 8.2.2.
 
 &= nbsp;    *  To reconcile this, the controlling agent MU= ST send an updated
         offer as described in Sect= ion 9.1.3, which will include the
         remote-candidates attribut= e.
 
 &= nbsp;    *  The agent MUST NOT update the state of ICE = processing when the
         offer is sent.  If th= is subsequent offer completes, the
         controlling agent MUST cha= nge the state of ICE processing to
         Completed for all media st= reams, and the state of ICE
         processing overall to Comp= leted.  The states for the controlled
         agent are set based on the= logic in Section 9.2.3.
 
Se= ction 9.1.3 has two subsections; 9.1.3.1 when ICE is running, and 9.1.3.2 w= hen ICE is completed. The 2nd bullet above indicates that at this stage ICE= is still running, which means do 9.1.3.1. However, 9.1.3.1 sends the exact same SDP-offer that was sent back in mess= age [1], with no remote-candidate attribute. I think the correct procedure = at this point is 9.1.3.2, since it updates the default candidate in the SDP= offer to indicate what candidate pair was selected by UA-1, and includes the remote-candidate attribute.
 
Question-2: Is this an error in the RFC? If not, how = does this subsequent offer/answer tell the controlled agent to start u= sing the candidate pair selected by the controlling agent? Or is it the intention of this procedure to simply let th= e controlled and controlling agents use different candidates for the establ= ished session (as they were during early media)?
 
I = *think* the offer/answer should look like this (i.e., should follow procedu= re in section 9.1.3.2)=85
 
&n= bsp;  [5] INVITE SDP offer --->
         c=3D IPv6 addr-1
         m =3D IPv6 port-1
         a=3Dice-lite
         a=3Dcandidate-1 IPv4 addr1=
         a=3Dcandidate-2 IPv6 addr1=
         a=3Dremote-candidate IPv6 = addr-2
 
Pe= r RFC5245 section 9.2.3, UA-2 sets its remote candidate to the default= destination (c=3D line) received in the SDP offer, and its local candidate= equal to the remote candidate received in the SDP offer. It then adds this candidate pair to its valid candidate list, a= nd generates an SDP answer based on this valid candidate.
 
&n= bsp;  [6] 200OK SDP answer <---
         c=3D IPv6 addr-2
         m =3D IPv6 port-2
         a=3Dice-lite
         a=3Dcandidate-1 IPv6 addr-= 2
         a=3Dcandidate-2 IPv4 addr-= 2
         a=3Dremote-candidate IPv6 = addr-1
   
   [7]ACK --->
 
If= the above is correct (i.e., compliant with RFC5245) then I think ICE-lite = procedure ensures that the established media stream is symmetrical in send/= receive direction w.r.t. IP version.
 
Question-3: Does the ICE-lite procedure in fact guara= ntee IP version symmetry in the established (not early) media streams?
 
Th= anks
David
 
--_000_76AC5FEF83F1E64491446437EA81A61F81899340FDsrvxchg_--