From miguel.a.garcia@ericsson.com Sun Oct 2 09:52:55 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 6419821F84D2 for ; Sun, 2 Oct 2011 09:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzqZi9oNWXcd for ; Sun, 2 Oct 2011 09:52:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3614521F84CB for ; Sun, 2 Oct 2011 09:52:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7b1aae000001146-39-4e88b3b6f832 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E4.52.04422.6B3B88E4; Sun, 2 Oct 2011 20:55:50 +0200 (CEST) Received: from [159.107.51.35] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Sun, 2 Oct 2011 18:55:52 +0200 Message-ID: <4E889797.9010204@ericsson.com> Date: Sun, 2 Oct 2011 18:55:51 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mmusic , Christer Holmberg , Staffan Blau , Eric Burger Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Ben Campbell Subject: [MMUSIC] SDP comments to draft-ietf-simple-msrp-cema-02.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: Sun, 02 Oct 2011 16:52:55 -0000 Here are some comments related to the new "msrp-cema" attribute defined in draft-ietf-simple-msrp-cema-02.txt - I am missing a section that has the syntax of the new extension. While it's true that the syntax is fairly simple, any extension should clearly specify the syntax (in this case, ABNF). This formal syntax could be: attribute /= msrp-cema-attr ; attribute defined in RFC 4566 msrp-cema-attr = "msrp-cema" I also suggest to add a section titled "The SDP 'msrp-cema' attribute" where you first give an overview of what the attribute does at a very high level (in this case, it indicates support for the CEMA mechanism), and then you include the formal syntax. - General. When you mention an SDP attribute, the "a=" is nor part of the attribute itself. So, it is not correct to say: the a=path attribute The correct one is: the 'path' attribute - The title of sections 4.2 and 4.3 could be improved. There is not such things as "MSRP offer" or "MSRP answer". We have the notion of "SDP offer" and "SDP answer", as well as "SDP offerer" and "SDP answerer", in which case, the sections should be titled "SDP offerer procedures" and "SDP answerer procedures". Furthermore, it is quite confusing to follow these sections because they refer to the "MSRP endpoint" and the "remote MSRP endpoint". Obviously, what is the "MSRP endpoint" in Section 4.2, becomes the "remote MSRP endpoint" in Section 4.3, and vice versa. I suggest to re-write these sections in terms of "the SDP offerer" and "the SDP answerer". This will make the text much clearer, and the terms will not reverse when we change sections. - Section 4.1. I think those three bullet points are the real "Applicability Statement" rather than something general to the mechanism. To me, they should be moved to Section 3. - Sections 4.1 to 4.3, the text says that an "MSRP endpoint becomes 'active'" or 'passive'. I was confused with what the text was meaning. I guess it means from the point of view of the TCP connection used for MSRP. I think this should be clarified. - Section 4.2, 2nd bullet point. I am missing that this bullet point says how to populate the c/m lines in SDP. Perhaps it is covered by the first paragraph of this Section 4.2, which basically refers to RFC 4975 and 4976. But then, the third bullet point describes the m/c line, so, at this point in time, I had my doubts whether bullet point forgets to say something of the c/m line or it is populated as per RFC 4975/4976. - In order to add a bit of clarity and separate the generation of the SDP offer from receiving the SDP answer, I would suggest to add the following text at the beginning of the paragraph that introduces the SDP answer in Section 4.2: "When receiving an SDP answer," and then continue with the current text "if the MSRP media description of the SDP answer ..." - Section 4.2, 1st bullet point of the SDP answer (and in other parts of 4.2 and 4.3), the text says: "... does not match the information ...". I have a problem with the word "match". Most likely, "match" implies "equality". So we are talking of the equality of the c/m lines with a URI. These two can never be equal. In particular, a URI can eve be a domain name or host name, in which case, will never be equal to an IP address and a port number. Most likely you want to say "resolve", but I am not sure. - I was trying to analyze if all the different cases are described in Section 4.2. Here is one that I believe is not covered: "if the SDP answer does not contain an 'msrp-cema' attribute and none of the 3 conditions are met". - Section 4.3, first paragraph. The text says "MUST reject". I think it would be nice to have a motivation to have such a strong action. - Section 5.4. The text says: "Middleboxes cannot be deployed in environments that require end-to-end SDP protection using SIP identity [RFC4916]." I am trying to see the connection between "end-to-end SDP protection" and "SIP identity". I would have removed one of them from the text, depending on what you want to say. Perhaps you want to say that the CEMA extension does not work if "end-to-end integrity protection of SDP is used". - Section 7.1 does not mention the registry where IANA has to operate. Start the section saying: "This document instructs IANA to add a attribute to the 'att-field (media level only)' registry of the SDP parameters registry, according to the following data" - Section 7.1, "Purpose". I will not speak of the "sending UA" in an SDP registry, but of the "SDP creator". Nits: - First paragraph in Section 6.3: " ... manipulating message content is CEMA provides ..." Most likely s/is/in - I would add formal references whenever an RFC is mentioned, especially if they are part of a normative sentence. For example, "... according to the procedures of RFC 4975 [RFC4975]". - I believe the text should say "a Message Session ..." rather than "an Message Session". But "an MSRP message", rather than "a MSRP message" - Section 4.1, first paragraph. Replace "... and what SDP information" with "... and which SDP information" - Section 4.1, first paragraph, at the end. Replace "TLS connection for the MSRP messages" with "TLS connection for sending and receiving MSRP messages". /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Oct 5 06:41:31 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 42E4C21F8CFE for ; Wed, 5 Oct 2011 06:41:31 -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.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V74AA8W+R8vS for ; Wed, 5 Oct 2011 06:41:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7A32021F8CF8 for ; Wed, 5 Oct 2011 06:41:30 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4d-4e8c5f31d4d1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.69.20773.13F5C8E4; Wed, 5 Oct 2011 15:44:18 +0200 (CEST) Received: from [159.107.24.252] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 5 Oct 2011 15:44:09 +0200 Message-ID: <4E8C5F28.7030800@ericsson.com> Date: Wed, 5 Oct 2011 15:44:08 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "James M. Polk" , "sdhesika@cisco.com" , "Paul E. Jones" , mmusic References: <4E84D5D6.9090305@ericsson.com> <18CF912C-5B91-49B6-BBCA-5AE1D2AF70ED@cisco.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: Re: [MMUSIC] Poll for consensus on WG item: SDP extension to classify traffic 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, 05 Oct 2011 13:41:31 -0000 I believe we have support to adopt the traffic-class draft as WG item. Please, authors, submit the next version as a WG item. /Miguel On 30/09/2011 21:21, Ali C. Begen (abegen) wrote: > +1 > > -acbegen > > On Sep 29, 2011, at 11:35 PM, "Gonzalo Salgueiro" > wrote: > >> Fully support it. >> >> Gonzalo >> >> On Sep 29, 2011, at 4:32 PM, Miguel A. Garcia wrote: >> >>> We have a milestone to submit an "SDP extension to classify traffic" >>> in August 2012. >>> >>> We have a draft that can be used as a design base to meet this goal, >>> this is the "trafficlass" attribute: >>> >>> http://datatracker.ietf.org/doc/draft-polk-mmusic-traffic-class-for-sdp/ >>> >>> We would like to poll the WG for consensus to adopt such draft as a WG >>> item in order to meet the mentioned milestone. >>> >>> Please indicate whether you support it or if not. >>> >>> 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 >> >> _______________________________________________ >> 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 Oct 5 06:49:58 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 371A021F8D29 for ; Wed, 5 Oct 2011 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6XyISUEWGr0 for ; Wed, 5 Oct 2011 06:49:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 725FA21F8D0B for ; Wed, 5 Oct 2011 06:49:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-8e-4e8c6140cf46 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.1C.20773.0416C8E4; Wed, 5 Oct 2011 15:53:04 +0200 (CEST) Received: from [159.107.24.252] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 5 Oct 2011 15:52:21 +0200 Message-ID: <4E8C6114.4000402@ericsson.com> Date: Wed, 5 Oct 2011 15:52:20 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 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 , draft-ietf-mmusic-media-loopback@tools.ietf.org Subject: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 05 Oct 2011 13:49:58 -0000 This is to announce a 2 week Working Group Last Call for draft-ietf-mmusic-media-loopback-16 as Proposed Standard. Please review and provide any comments you may have on the document before Thursday, October 20th, 2011. Comments should be sent to the document authors and the MMUSIC WG list. Thanks Miguel & Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From HKaplan@acmepacket.com Wed Oct 5 13:07:56 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 C2F2421F8B84 for ; Wed, 5 Oct 2011 13:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8HD6Vlp9Drp for ; Wed, 5 Oct 2011 13:07:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E787121F8B26 for ; Wed, 5 Oct 2011 13:07:51 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 5 Oct 2011 16:10:59 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 5 Oct 2011 16:10:59 -0400 From: Hadriel Kaplan To: "Miguel A. Garcia" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMg5rlap0KEDNZfkerRVZknUO4Xg== Date: Wed, 5 Oct 2011 20:10:58 +0000 Message-ID: <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> References: <4E8C6114.4000402@ericsson.com> In-Reply-To: <4E8C6114.4000402@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <49EA83A2D31A4942AB3B317E7801C527@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Flemming Andreasen , mmusic , "" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 05 Oct 2011 20:07:56 -0000 When looking at the diff between this version of the draft and the previous= , I note the majority of the changes are around removing the "priming" mech= anism in its entirety. And there is only one small paragraph about making = this work behind NATs, which basically says "SHOULD use" ICE/STUN/TURN. What surprises me about this is I don't recall any WG consensus to make the= change to pull out the priming mechanism entirely this way. I only recall= discussion around saying one SHOULD use ICE but MAY use the priming mechan= ism if ICE isn't supported; and keeping the priming mechanism defined in th= e loopback draft to explain how it works. So... (1) why was this significant change made without apparent WG consensu= s, and (2) how do we expect the priming mechanism to interoperate if we don= 't define how it works? Or have we decided making loopback calls to SIP UA= 's behind NATs is no longer important/relevant? -hadriel On Oct 5, 2011, at 9:52 AM, Miguel A. Garcia wrote: > This is to announce a 2 week Working Group Last Call for >=20 > draft-ietf-mmusic-media-loopback-16 >=20 > as Proposed Standard. Please review and provide any comments you may have= on the document before Thursday, October 20th, 2011. Comments should be se= nt to the document authors and the MMUSIC WG list. >=20 > Thanks >=20 > Miguel & Flemming > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Thu Oct 6 08:59:09 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 68EAA21F8DFF for ; Thu, 6 Oct 2011 08:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfoPT0a3rhGG for ; Thu, 6 Oct 2011 08:59:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDFC21F8DFA for ; Thu, 6 Oct 2011 08:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=1029; q=dns/txt; s=iport; t=1317916940; x=1319126540; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NW4XBWky0wkDWtTR3UR2yx4+QW9+CH5pMg2C07dnj94=; b=SWoTcMPFR8ciw11uU/tM9PD8PazaAZkpKHbuRPKa2h5VcGeVsdc+yjdd Sp2lH6s/qtqbY7yqOYJpGdSMz+l03CeTfwXeEfR1RW0idtWPVBXqEJHxa lJtP0oNKmmUeIM+EzjYnjTry/nEoV1sVVn9nDHbqUsPEcjK0omJqgAOQ+ w=; X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208";a="26534342" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 06 Oct 2011 16:02:19 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p96G2Igq011993; Thu, 6 Oct 2011 16:02:19 GMT Message-ID: <4E8DD10F.9030709@cisco.com> Date: Thu, 06 Oct 2011 12:02:23 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic References: <4E7A1982.8090608@cisco.com> In-Reply-To: <4E7A1982.8090608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , draft-ietf-simple-chat@tools.ietf.org Subject: Re: [MMUSIC] SDP Reviewers Needed for draft-ietf-simple-chat-10 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, 06 Oct 2011 15:59:09 -0000 Hi I have reviewed draft-ietf-simple-chat-10 for SDP extension issues, and I have two comments: 1) Need to consider extensibility rules for the new SDP attribute and any IANA registry needed for that 2) Security considerations (privacy concerns) seem to be missing for the SDP attribute. I also have a few editorial nit fixes that I have forwarded to the authors separately. Thanks -- Flemming On 9/21/11 1:06 PM, Flemming Andreasen wrote: > Folks > > The SIMPLE WG has completed WGLC on > > "Multi-party Chat Using the Message Session Relay Protocol (MSRP)" > (http://tools.ietf.org/html/draft-ietf-simple-chat-10). > > The draft extends SDP and requires review by the experts of MMUSIC. > The extension is listed in Section 8 with some examples in Section 9. > > If you would like to volunteer as a reviewer, please let the chairs > now. Also, please note that we have been asked to complete the review > relatively quickly. > > Thanks > > Flemming & Miguel > > > From pkyzivat@alum.mit.edu Thu Oct 6 14:00: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 F32F611E80A4 for ; Thu, 6 Oct 2011 14:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-7T15Q+m9Jx for ; Thu, 6 Oct 2011 14:00:39 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 0F85A11E8073 for ; Thu, 6 Oct 2011 14:00:38 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA11.westchester.pa.mail.comcast.net with comcast id hWTS1h00A1ap0As5BZ3rl5; Thu, 06 Oct 2011 21:03:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta22.westchester.pa.mail.comcast.net with comcast id hZ3q1h00z0tdiYw3iZ3qWn; Thu, 06 Oct 2011 21:03:51 +0000 Message-ID: <4E8E17B4.8080302@alum.mit.edu> Date: Thu, 06 Oct 2011 17:03:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB288@ESESSCMS0356.eemea.ericsson.se><4E70F5D7.6000809@alvestrand.no><46A1DF3F04371240B504290A071B4DB60BF34120@szxeml509-mbx.china.huawei.com><4E72024F.20605@alvestrand.no><46A1DF3F04371240B504290A071B4DB60BF345C3@szxeml509-mbx.china.huawei.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E424@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C6538049202066491F0@XMB-BGL-414.cisco.com> <4E730A54.8040006@ericsson.com> In-Reply-To: <4E730A54.8040006@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Draft submission: draft-holmberg-mmusic-sdp-multiplex-negotiation 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, 06 Oct 2011 21:00:40 -0000 On 9/16/11 4:35 AM, Miguel A. Garcia wrote: > I think there are two major points of difference between the TOGETHER > and the MULTIPLEX approach: > > 1) Usage of port numbers in the SDP offer > > 2) Combination of additional parameters from the SDP offer > > Let me analyze 1) in more detail. I believe a stream of media is > identified by the transport addresses of both endpoints and the protocol > (RTP/RTCP in this case). So, if we take the MULTIPLEX approach, the > offerer will include the same port number in all its multiplexed > streams. Now, if the answerer decides to multiplex, then we will have a > single stream, because the transport addresses of all the RTP flows are > equal. > > In this MULTIPLEX approach, if the answerer does not support the > extension or does not want to use it, it will create an SDP answer that > contains different port numbers. Therefore, each RTP flow will be send > over a different 5-tuple, and each RTP flow will constitute a different > media stream, even when all the transport addresses at one endpoint are > equal. So I don't see this creating a problem with any existing endpoint > that does not support the extension. IIUC, o/a results in an exchange of addresses/ports at which media will be *received*. It does *not* define a 5-tuple. You learn the 5-tuple from the o/a only if you assume media is sent from the same addr/port at which it is received. Of course its fairly common to assume this symmetric usage. In retrospect it should probably have been mandated. But it wasn't. If symmetric RTP is a fundamental requirement of the multiplexing, then it should be called out as such. Thanks, Paul From miguel.a.garcia@ericsson.com Fri Oct 7 03:29: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 28D5A21F8B87 for ; Fri, 7 Oct 2011 03:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG09o-xII1je for ; Fri, 7 Oct 2011 03:29:53 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 619C521F8B6C for ; Fri, 7 Oct 2011 03:29:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-03-4e8ed5619cf9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EB.55.20773.165DE8E4; Fri, 7 Oct 2011 12:33:05 +0200 (CEST) Received: from [159.107.48.251] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 7 Oct 2011 12:33:05 +0200 Message-ID: <4E8ED560.2030402@ericsson.com> Date: Fri, 7 Oct 2011 12:33:04 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 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] Poll for consensus on 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, 07 Oct 2011 10:29:54 -0000 We have two related milestones to submit SDP extensions to signal parallax information and to signal stereoscopic 3D video. This milestones are currently due on September 2012. We have two drafts that are believed to serve as a design base to meet these milestones: http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-parallax-attribute/ http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/ We would like to poll the WG for consensus to adopt those drafts as a WG items in order to meet these milestones. Please indicate whether you support the adoption of one, the other, or both. Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Fri Oct 7 03:31:44 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 005C221F8B92 for ; Fri, 7 Oct 2011 03:31:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9TLRsM5XahH for ; Fri, 7 Oct 2011 03:31:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 39C1721F8B8A for ; Fri, 7 Oct 2011 03:31:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-18-4e8ed5cf443b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 42.2B.13753.FC5DE8E4; Fri, 7 Oct 2011 12:34:55 +0200 (CEST) Received: from [159.107.48.251] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 7 Oct 2011 12:34:55 +0200 Message-ID: <4E8ED5CE.4010303@ericsson.com> Date: Fri, 7 Oct 2011 12:34:54 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mmusic References: <4E8ED560.2030402@ericsson.com> In-Reply-To: <4E8ED560.2030402@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] Poll for consensus on parallax and 3D format 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: Fri, 07 Oct 2011 10:31:44 -0000 Now with the name of the draft in the title of this e-mail. /Miguel On 07/10/2011 12:33, Miguel A. Garcia wrote: > We have two related milestones to submit SDP extensions to signal > parallax information and to signal stereoscopic 3D video. This milestones > are currently due on September 2012. > > We have two drafts that are believed to serve as a design base to meet > these milestones: > > http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-parallax-attribute/ > http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/ > > We would like to poll the WG for consensus to adopt those drafts as a WG > items in order to meet these milestones. > > Please indicate whether you support the adoption of one, the other, or both. > > Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From fandreas@cisco.com Sat Oct 8 05:51:00 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 D2BEC21F8B36 for ; Sat, 8 Oct 2011 05:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KVnGawWehKn for ; Sat, 8 Oct 2011 05:51:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0380921F8B16 for ; Sat, 8 Oct 2011 05:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=3401; q=dns/txt; s=iport; t=1318078456; x=1319288056; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lwEVjnsEcPxUpqID3l01AOc5xGSTPCSL6pOXLbAKMjM=; b=dc/x8aR7NdaVm/Y4J6WiOxXwdZZ82R1pIwkLjQkhGpfmrZJz1zWIMUug KcDOfGYIJuhaIyLFlx67ClZGaFzjEN65zR2MzbXwCWdLfVO5v2kSl31Nv vqtifCVKKKJYIENdFHLYwAqVt3eTTOgrf0jEl4MobEwC3HSwI6LeksHa7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANBGkE6tJV2Y/2dsb2JhbABEqB6BBYFTAQEBAQMBAQEPAQobNgoBEAsOCgkWDwkDAgECARUwBg0BBQIBAQUZh2OYWQGdZYcwBI5SAQGFHpFk X-IronPort-AV: E=Sophos;i="4.68,507,1312156800"; d="scan'208";a="26961110" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 08 Oct 2011 12:54:16 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p98CsFvP027646; Sat, 8 Oct 2011 12:54:15 GMT Message-ID: <4E9047F7.9000204@cisco.com> Date: Sat, 08 Oct 2011 08:54:15 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> In-Reply-To: <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic , draft-ietf-mmusic-media-loopback@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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: Sat, 08 Oct 2011 12:51:01 -0000 Hi Hadriel The issue was discussed on the mailing list in August, where the authors suggested it as a path forward and the chairs asked the WG for feedback on this approach, see e.g. http://www.ietf.org/mail-archive/web/mmusic/current/msg08857.html The issue was also discussed in the last IETF MMUSIC meeting (see http://www.ietf.org/proceedings/81/minutes/mmusic.txt) To date, we have only seen opposition to this proposal from you (on both the mailing list and in the meeting), and we are lacking an alternative path forward that can satisfy all involved parties, including the general AD and WG chair concerns around definining an alternative NAT traversal mechanism in this draft without proper discussion and general considerations around the need for an alternative to ICE (per the above thread). To recap, the proposal we made was: To summarize, the current latching mechanism and the associated payload type definitions for it will be removed, and ICE will be the only NAT traversal mechanism specified for loopback in this draft. The loopback payload types that are needed in general (i.e. without latching) will remain in the draft and the PAYLOAD WG will review them as part of this draft. If the authors and/or the WG believe that we should continue working on the latching (or other) NAT traversal mechanisms different from ICE, then that is something that will be discussed and/or developed outside of the media loopback work. If you do not find this path forward acceptable, can you please suggest an alternative that satisfies the general concerns around defining an alternative NAT traversal mechanism in this draft ? Thanks -- Flemming & Miguel On 10/5/11 4:10 PM, Hadriel Kaplan wrote: > When looking at the diff between this version of the draft and the previous, I note the majority of the changes are around removing the "priming" mechanism in its entirety. And there is only one small paragraph about making this work behind NATs, which basically says "SHOULD use" ICE/STUN/TURN. > > What surprises me about this is I don't recall any WG consensus to make the change to pull out the priming mechanism entirely this way. I only recall discussion around saying one SHOULD use ICE but MAY use the priming mechanism if ICE isn't supported; and keeping the priming mechanism defined in the loopback draft to explain how it works. > > So... (1) why was this significant change made without apparent WG consensus, and (2) how do we expect the priming mechanism to interoperate if we don't define how it works? Or have we decided making loopback calls to SIP UA's behind NATs is no longer important/relevant? > > -hadriel > > > On Oct 5, 2011, at 9:52 AM, Miguel A. Garcia wrote: > > >> This is to announce a 2 week Working Group Last Call for >> >> draft-ietf-mmusic-media-loopback-16 >> >> as Proposed Standard. Please review and provide any comments you may have on the document before Thursday, October 20th, 2011. Comments should be sent to the document authors and the MMUSIC WG list. >> >> Thanks >> >> Miguel& Flemming >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > From abegen@cisco.com Mon Oct 10 11:17:40 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 498E421F8BBF; Mon, 10 Oct 2011 11:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpPUP29G9wbv; Mon, 10 Oct 2011 11:17:39 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7B54A21F8BB9; Mon, 10 Oct 2011 11:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=632; q=dns/txt; s=iport; t=1318270659; x=1319480259; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=rAa8Lcbj+6H4MAbinfiVMLPbrLnkpT0hm3mZqV97ai0=; b=QdtQI56t3WHRA4RGW1KCRV69SFs9aICGIFpV4s1k3GwINYE/fA3dAL8J j41iFxmuv09EYyuMGxo0FYklWIGX9cQOF2RjSW0XOIlaOltmcAaiOiHle f8yFok4jrxy/C8qIQizDEfi6CQzUuhcsfHaZMz6IkorROTlq3OFAIBcw9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL41k06rRDoG/2dsb2JhbABDqB6BBYFVAQEDEgEdSRIBKgYYB1cBBBsah2OaMAGeJwOGYmEEh00wjG+EPYxA X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="7004189" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 Oct 2011 18:17:39 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9AIHddQ001464; Mon, 10 Oct 2011 18:17:39 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 11:17: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 Date: Mon, 10 Oct 2011 11:17:20 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Duplication semantics drafts Thread-Index: AcyHeEjl/8RP3G7tSZC9DV9gLHt2UQ== From: "Ali C. Begen (abegen)" To: "mmusic (E-mail)" X-OriginalArrivalTime: 10 Oct 2011 18:17:38.0970 (UTC) FILETIME=[E4B38FA0:01CC8778] Cc: avt@ietf.org Subject: [MMUSIC] Duplication 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: Mon, 10 Oct 2011 18:17:40 -0000 I revised the two drafts per the feedback in Quebec. If there are further comments, we would like to hear about them. As of = now, there are no open issues from our standpoint except possibly = defining a new RTCP XR report, which can be done later. Thus, we would = like these two drafts to be considered and adopted by the MMUSIC wg. https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving= /=20 CC'ing AVT(core) since the topic is relevant but please post your = comments to mmusic where the drafts belong to. -acbegen From magnus.westerlund@ericsson.com Tue Oct 11 02:41:42 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 2B97221F8C00; Tue, 11 Oct 2011 02:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUPwVKYFhbX6; Tue, 11 Oct 2011 02:41:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA7521F8BFE; Tue, 11 Oct 2011 02:41:40 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-8e-4e940f54b3f4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F9.83.13753.45F049E4; Tue, 11 Oct 2011 11:41:40 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 11 Oct 2011 11:41:39 +0200 Message-ID: <4E940F52.4030007@ericsson.com> Date: Tue, 11 Oct 2011 11:41:38 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" , "avt@ietf.org" Subject: Re: [MMUSIC] [AVTCORE] Duplication 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: Tue, 11 Oct 2011 09:41:42 -0000 On 2011-10-10 20:17, Ali C. Begen (abegen) wrote: > I revised the two drafts per the feedback in Quebec. > > If there are further comments, we would like to hear about them. As > of now, there are no open issues from our standpoint except possibly > defining a new RTCP XR report, which can be done later. Thus, we > would like these two drafts to be considered and adopted by the > MMUSIC wg. > > https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ > > https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ > > CC'ing AVT(core) since the topic is relevant but please post your > comments to mmusic where the drafts belong to. > Hi, (as individual) I have looked at the redundancy-grouping draft and still think it fails as RTP specifications for how duplication should be done in RTP, either using SSRC multiplexing with two different SSRCs in the same RTP session or for the alternative how having two different RTP sessions. This first appears to be sufficiently specified, where my only comment is the dependency on signalling to determine that this grouping is in place. I do propose that an RTP/RTCP based complement is derived. I would personally suggest that my own proposal for a new SDES item SRCNAME is used but that should clearly be discussed. For the case where multiple RTP sessions are used, it is still not clear how a receiver determine which SSRC in each RTP session that are related. And I would like to point out that CNAME is not sufficient. I still think we should consider splitting this into one AVTCORE document discussing the RTP aspects of duplication, and another MMUSIC document defining the grouping semantics. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Tue Oct 11 03:46:37 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 E724B21F8C0B; Tue, 11 Oct 2011 03:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv8r0vjgCB1T; Tue, 11 Oct 2011 03:46:37 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4C08621F8C09; Tue, 11 Oct 2011 03:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3147; q=dns/txt; s=iport; t=1318329997; x=1319539597; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zCz1hrINf8nwE6Eri1bPhRqOv88+01AfxvTgSIg28V0=; b=jBMSQ9JHc6v3BOSqWYedcRmuBfrRkPAgHEIm1Gtm+GZsUILlGt4feymt 6lRCWIJHnhM+9qIdufNJ3DbiFukXhozG9OravHLJdQT7VKKq8UwT9LDJq IzUDtkx50Fk9Ht5D6gwsafmJyGZMMXFGrbqIB+wjY3So+G0mqubYZpsXz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0AAKwdlE6rRDoH/2dsb2JhbABDmQSPI4EFgVMBAQEDAQwGAR1CBwUHAgICAQgRBAEBAQoGFwEGARorCQgBAQQTCBqHXAebMgGeUwMChmlhBId+kSeMQQ X-IronPort-AV: E=Sophos;i="4.68,522,1312156800"; d="scan'208";a="7144579" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 11 Oct 2011 10:46:36 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9BAkaV4012931; Tue, 11 Oct 2011 10:46:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 03:46:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2011 03:46:24 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54100980DB@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E940F52.4030007@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Duplication semantics drafts Thread-Index: AcyH+fti2yzOq66+SYqeCQGHBALQzgACFZnw References: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> <4E940F52.4030007@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 11 Oct 2011 10:46:36.0553 (UTC) FILETIME=[0CA82F90:01CC8803] Cc: "mmusic \(E-mail\)" , avt@ietf.org Subject: Re: [MMUSIC] [AVTCORE] Duplication 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: Tue, 11 Oct 2011 10:46:38 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, October 11, 2011 5:42 AM > To: Ali C. Begen (abegen) > Cc: mmusic (E-mail); avt@ietf.org > Subject: Re: [AVTCORE] Duplication semantics drafts >=20 > On 2011-10-10 20:17, Ali C. Begen (abegen) wrote: > > I revised the two drafts per the feedback in Quebec. > > > > If there are further comments, we would like to hear about them. As > > of now, there are no open issues from our standpoint except possibly > > defining a new RTCP XR report, which can be done later. Thus, we > > would like these two drafts to be considered and adopted by the > > MMUSIC wg. > > > > = https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ > > > > = https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving= / > > > > CC'ing AVT(core) since the topic is relevant but please post your > > comments to mmusic where the drafts belong to. > > >=20 > Hi, >=20 > (as individual) >=20 > I have looked at the redundancy-grouping draft and still think it = fails > as RTP specifications for how duplication should be done in RTP, = either > using SSRC multiplexing with two different SSRCs in the same RTP = session > or for the alternative how having two different RTP sessions. This = first > appears to be sufficiently specified, where my only comment is the > dependency on signalling to determine that this grouping is in place. = I > do propose that an RTP/RTCP based complement is derived. I would > personally suggest that my own proposal for a new SDES item SRCNAME is > used but that should clearly be discussed. Right, the ssrc muxing case is straightforward and easy to implement. = Everything works fine without the need for defining new stuff except the = grouping semantics. I am not sure why you think there is a problem in = the signaling. If duplication will be done across sessions (your second case), then it = gets complicated. And as I understand your claim is regular CNAME falls = short to define this relation. Is that correct? And your proposal is = SRCNAME, right? =20 > For the case where multiple RTP sessions are used, it is still not = clear > how a receiver determine which SSRC in each RTP session that are > related. And I would like to point out that CNAME is not sufficient. >=20 > I still think we should consider splitting this into one AVTCORE > document discussing the RTP aspects of duplication, and another MMUSIC > document defining the grouping semantics. This sounds like a good plan to me. -acbegen =20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Oct 11 05:31:04 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 6B2D621F8C0B; Tue, 11 Oct 2011 05:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDJScPvZwhIm; Tue, 11 Oct 2011 05:31:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 677BD21F8BB9; Tue, 11 Oct 2011 05:31:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-0d-4e943706bac2 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 57.93.13753.607349E4; Tue, 11 Oct 2011 14:31:02 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 11 Oct 2011 14:31:01 +0200 Message-ID: <4E943705.8080409@ericsson.com> Date: Tue, 11 Oct 2011 14:31:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> <4E940F52.4030007@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D54100980DB@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54100980DB@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" , "avt@ietf.org" Subject: Re: [MMUSIC] [AVTCORE] Duplication 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: Tue, 11 Oct 2011 12:31:04 -0000 On 2011-10-11 12:46, Ali C. Begen (abegen) wrote: >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> (as Individual) >> I have looked at the redundancy-grouping draft and still think it fails >> as RTP specifications for how duplication should be done in RTP, either >> using SSRC multiplexing with two different SSRCs in the same RTP session >> or for the alternative how having two different RTP sessions. This first >> appears to be sufficiently specified, where my only comment is the >> dependency on signalling to determine that this grouping is in place. I >> do propose that an RTP/RTCP based complement is derived. I would >> personally suggest that my own proposal for a new SDES item SRCNAME is >> used but that should clearly be discussed. > > Right, the ssrc muxing case is straightforward and easy to implement. > Everything works fine without the need for defining new stuff except > the grouping semantics. I am not sure why you think there is a problem > in the signaling. Yes, it works as long as the application can accept to rely on the signalling protocol. However, if one would like to to this in session where one has a dynamic set of participants and it is large enough that it isn't feasible to updated the signalling for each new participant that joins the session and is a potential sender. Then it would be good to have something that works on the RTP/RTCP level. > > If duplication will be done across sessions (your second case), then it gets complicated. And as I understand your claim is regular CNAME falls short to define this relation. Is that correct? And your proposal is SRCNAME, right? Yes, the show case when CNAME falls short is for any case where an end-point will have multiple media flows in the same session. So in this case you have 2 SSRC in one session carrying the source (original) stream and 2 SSRCs in the second carrying the duplicated data. As the two source SSRC come from the same synchronization context they do carry the same CNAME. Thus a receiver will have two sets of SSRCs that both carry the same CNAME. Thus that can't be used to bind the correct set of SSRCs together. Using the sequence numbers are prone to errors and can easily fail. I don't like overriding the SSRC randomization and require the duplicated streams to have the same SSRC as the original. It also creates separate solutions for the two cases. I therefore prefer to see a solution that can handle both cases and targeted at this particular problem. There will be a dedicated version of the SRCNAME draft submitted before the deadline. > >> For the case where multiple RTP sessions are used, it is still not clear >> how a receiver determine which SSRC in each RTP session that are >> related. And I would like to point out that CNAME is not sufficient. >> >> I still think we should consider splitting this into one AVTCORE >> document discussing the RTP aspects of duplication, and another MMUSIC >> document defining the grouping semantics. > > This sounds like a good plan to me. Good Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From HKaplan@acmepacket.com Wed Oct 12 07:59:20 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 7053421F8BEC for ; Wed, 12 Oct 2011 07:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V++F5-4indxm for ; Wed, 12 Oct 2011 07:59:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id CE6BA21F8BEB for ; Wed, 12 Oct 2011 07:59:19 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 12 Oct 2011 10:59:18 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 12 Oct 2011 10:59:18 -0400 From: Hadriel Kaplan To: Flemming Andreasen Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMiO+DjSC5obMZt0mryTxFVkl6MA== Date: Wed, 12 Oct 2011 14:59:17 +0000 Message-ID: <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> In-Reply-To: <4E9047F7.9000204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <06B0CBAEC752AA47B41DCEA9799A213B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: mmusic , "" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 12 Oct 2011 14:59:20 -0000 On Oct 8, 2011, at 8:54 AM, Flemming Andreasen wrote: > The issue was discussed on the mailing list in August, where the authors = suggested it as a path forward and the chairs asked the WG for feedback on = this approach, see e.g. >=20 > http://www.ietf.org/mail-archive/web/mmusic/current/msg08857.html >=20 > The issue was also discussed in the last IETF MMUSIC meeting (see http://= www.ietf.org/proceedings/81/minutes/mmusic.txt) >=20 > To date, we have only seen opposition to this proposal from you (on both = the mailing list and in the meeting), and we are lacking an alternative pat= h forward that can satisfy all involved parties, including the general AD a= nd WG chair concerns around definining an alternative NAT traversal mechani= sm in this draft without proper discussion and general considerations aroun= d the need for an alternative to ICE (per the above thread). In the email thread you referenced above there was in fact someone else who= was for keeping the priming mechanism, and it wasn't me. In fact, in that whole thread there was only one other person than yourself= who was in favor of only having ICE in the draft. Of course there was onl= y one other person than myself who was in favor of keeping the primer mecha= nism. My point is that there has been no consensus either way. The authors only = changed the draft due to your objections, afaict, not due to some large con= sensus to do so. > If you do not find this path forward acceptable, can you please suggest a= n alternative that satisfies the general concerns around defining an altern= ative NAT traversal mechanism in this draft ? There have been no "general concerns" as far as I can tell, other than "we = have ICE defined so why not use it". My concerns with mandating *only* IC= E as opposed to having a SHOULD use ICE but MAY use primer are detailed her= e:=20 http://www.ietf.org/mail-archive/web/mmusic/current/msg08611.html There was no feedback/response to that, afaict. -hadriel From internet-drafts@ietf.org Thu Oct 13 05:19:02 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 8B78F21F8C11; Thu, 13 Oct 2011 05:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJwzoQnpPaWb; Thu, 13 Oct 2011 05:19:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269CB21F8BB3; Thu, 13 Oct 2011 05:19:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2011 05:19:02 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-08.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, 13 Oct 2011 12:19:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-08.txt Pages : 30 Date : 2011-10-13 This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.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-ietf-mmusic-sdp-cs-08.txt From Simo.Veikkolainen@nokia.com Thu Oct 13 05:21:12 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 D67D421F8801 for ; Thu, 13 Oct 2011 05:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEcNE43hkaOz for ; Thu, 13 Oct 2011 05:21:12 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id C958F21F863E for ; Thu, 13 Oct 2011 05:21:11 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9DCLAHR010970 for ; Thu, 13 Oct 2011 15:21:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Oct 2011 15:21:10 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 13 Oct 2011 14:21:09 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.117]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Thu, 13 Oct 2011 14:21:09 +0200 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-08.txt Thread-Index: AQHMiaJTxos3wJPXwUywFVH4h/lU/5V6MYbg Date: Thu, 13 Oct 2011 12:21:09 +0000 Message-ID: References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> In-Reply-To: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: NgLgUAGhIMVcmkVcu9QCA++pacJLza70eKLlXGeFvL9wKhXSy8cPmB1O7f+1g131u+p7XQQSY5M0SND5LfihhJFwDxl4CviyKxJQzpq1G/PuDxR2Im/lyWWkOLi7Q6tCMvbUAPph4gLbWcPDnpGDV+zUp+rFhHDtDT5qB49v0/l3bdAfXxbvfphIBlOK/8c+r58Vvx/HXkqlEmavPTswzKce9rqp/COdWT7QqLp9+ofcFKhPFU574h2nfvoLiQMhD1r//W+Agl3XnFHKhR9R+Q== x-originating-ip: [88.114.28.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2011 12:21:10.0070 (UTC) FILETIME=[9729AD60:01CC89A2] X-Nokia-AV: Clean Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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, 13 Oct 2011 12:21:13 -0000 Hello all, We just submitted a new version of draft-ietf-mmusic-sdp-cs. Changes in the -08 version include: Added a new section "Offer/Answer extensions" detailing the process of hand= ling the O/A exchange.=20 Clarified that multiple extensions for cs-correlation are allowed. Added a request for IANA to create a sub-registry for "cs-correlation" attr= ibute values, with "Specification Required" policy.=20 Clarified how dynamic payloads are handled. Basically we stick to normal SD= P processing here, i.e. if dynamic payload types are used, a=3Drtpmap attri= bute(s) are required. This may need more thought still. Changed a lot of SHOULDs into MUSTs. Extended the example in Section 6. Flemming had a comment on mandating E.164 numbers in the international form= at. After some thinking, we still say that the enpoints SHOULD include the = number in international format. The network may anyway mangle the number pr= esentation, so we thought mandating the intl format is not absolutely neces= sary. TODO: Security considerations needs more work based on Flemming's earlier c= omments (including caller's E164 number in SDP). TODO: Clarification on the mechanism works with 3PCC. TODO:Change the UUIE syntax to allow for a discriminator byte. We hope to address the remaning issues still before the IETF submission dea= dline. Regards, Simo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 13 October, 2011 15:19 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-08.txt Pages : 30 Date : 2011-10-13 This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.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-ietf-mmusic-sdp-cs-08.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Fri Oct 14 06:19: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 5A5E521F8C08 for ; Fri, 14 Oct 2011 06:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur+i+vp7mt0l for ; Fri, 14 Oct 2011 06:19:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EECE921F8C04 for ; Fri, 14 Oct 2011 06:19:34 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-24-4e9836e59552 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5D.C8.20773.5E6389E4; Fri, 14 Oct 2011 15:19:34 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 14 Oct 2011 15:19:33 +0200 Message-ID: <4E9836E5.5020701@ericsson.com> Date: Fri, 14 Oct 2011 15:19:33 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20111014123417.23644.32150.idtracker@ietfa.amsl.com> In-Reply-To: <20111014123417.23644.32150.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.2 X-Forwarded-Message-Id: <20111014123417.23644.32150.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------080100080401020906080804" X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Fwd: I-D Action: draft-westerlund-avtcore-transport-multiplexing-00.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, 14 Oct 2011 13:19:36 -0000 --------------080100080401020906080804 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MMUSIC, I have submitted a draft that looks as multiplexing multiple RTP sessions on the same lower layer transport. It is also extending draft-holmberg-mmusic-sdp-multiplex-negotiation-00 to achieve negotiation of the multiplexing taking place and which session IDs to use for each media description. Feedback appreciated Magnus Westerlund --------------080100080401020906080804 Content-Type: message/rfc822; name="I-D Action: draft-westerlund-avtcore-transport-multiplexing-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="I-D Action: draft-westerlund-avtcore-transport-multiplexing-"; filename*1="00_txt.eml" Received: from mailgw2.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.95) with Microsoft SMTP Server id 8.3.137.0; Fri, 14 Oct 2011 14:34:28 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AD.E1.09133.35C289E4; Fri, 14 Oct 2011 14:34:28 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE25921F8B98; Fri, 14 Oct 2011 05:34:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7045621F8BA2 for ; Fri, 14 Oct 2011 05:34:17 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSHIgwqcOEk5 for ; Fri, 14 Oct 2011 05:34:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071C921F8B2A for ; Fri, 14 Oct 2011 05:34:17 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Sender: "i-d-announce-bounces@ietf.org" Date: Fri, 14 Oct 2011 14:34:17 +0200 Subject: I-D Action: draft-westerlund-avtcore-transport-multiplexing-00.txt Thread-Topic: I-D Action: draft-westerlund-avtcore-transport-multiplexing-00.txt Thread-Index: AcyKbZ1gCn9nnCY/QgS6MPD0rUb8vg== Message-ID: <20111014123417.23644.32150.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0247.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb25-b7cb3ae0000023ad-bc-4e982c53a8fd x-brightmail-tracker: AAAAAA== dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1318595660; bh=qPRsXQoVXKWliHVO2sAWGnTzXfG604RqNO7yyfRz11g=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ydhiHMWvYIPxd4/koO1BEIIKfT8t09FagJ/75qGZTjGVEs6fALdsvm3nMVYGV0+U0 tIvBZTzysUxfdfYMJGE1F60YVenbQfSRvDTzzOxLStrb1E9n29nGLY4CMDx9uK7st3 IXpmuFw4XdGP4ywCPp28+faVhq5HS1orbx7bklro= errors-to: i-d-announce-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-mailman-version: 2.1.12 list-post: list-archive: list-id: Internet Draft Announcements only x-beenthere: i-d-announce@ietf.org x-spam-level: x-spam-status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] x-spam-score: -102.574 x-spam-flag: NO delivered-to: i-d-announce@ietfa.amsl.com x-original-to: i-d-announce@ietfa.amsl.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Multiple RTP Session on a Single Lower-Layer Transport Author(s) : Magnus Westerlund Filename : draft-westerlund-avtcore-transport-multiplexing-00.txt Pages : 23 Date : 2011-10-14 This document specifies how multiple RTP sessions are to be multiplexed on the same lower-layer transport, e.g. a UDP flow. It discusses various requirements that have been raised and their feasibility, which results in a solution with a certain applicability. A solution is recommended and that solution is provided in more detail, including signalling and examples. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westerlund-avtcore-transport-mult= iplexing-00.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-westerlund-avtcore-transport-multi= plexing-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------080100080401020906080804-- From pkyzivat@alum.mit.edu Fri Oct 14 11:46:37 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 05D3D21F84DD for ; Fri, 14 Oct 2011 11:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITGX2XTeX74y for ; Fri, 14 Oct 2011 11:46:36 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2389F21F84D5 for ; Fri, 14 Oct 2011 11:46:36 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta05.westchester.pa.mail.comcast.net with comcast id kilz1h00C17dt5G55imcNh; Fri, 14 Oct 2011 18:46:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta13.westchester.pa.mail.comcast.net with comcast id kimc1h0060tdiYw3ZimcDn; Fri, 14 Oct 2011 18:46:36 +0000 Message-ID: <4E98838A.7040206@alum.mit.edu> Date: Fri, 14 Oct 2011 14:46:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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, 14 Oct 2011 18:46:37 -0000 I reviewed draft-ietf-mmusic-sdp-cs-08 and have a number of comments: 5.2.1 This says addresses for the E164 address type are represented according to ITU-T E.164. If I have followed the reference correctly, it only specifies the country codes, not the encoding of numbers including country codes. I think it would be better to define this by reference to RFC 3966 (TEL) and to either telephone-subscriber, or global-number, or global-number-digits defined there. (I'm not sure which of those is most appropriate for your use.) Also, you give the example c=PSTN - - That requires that "-" be a defined address type. AFAIK it is not. Did you mean it to be c=PSTN E164 - 5.2.3.1 The syntax given for a=cs-correlation is inconsistent with the syntax in 5.6 and with usage throughout the document. 5.2.3.3 You specify that the UUIE has a max size of 35 or 131 octets. AFAIK the actual max information content is actually either 32 or 128 octets plus a leading protocol discriminator byte. Its unclear what you intend to be included in the specified uuie element in the sdp - does it include the protocol discriminator or not? Also, the content and protocol discriminator contain octets, not just alphanumerics, but the syntax in 5.6 only permits alphanumerics. Is it your *intent* to limit the protocol discriminator and the value to that subset described by alphanumerics? And is that a reasonable thing to do? (For this use, it *might* be sufficient to prescribe a specific value for the protocol discriminator.) 5.5.1 / 5.5.4 The description of a=connection here is more appropriate to section 5.5.4. Here, for the initial offer, a=connection:new is the only thing that makes sense. In 5.5.4 it would be helpful to explain in more detail how a=connection is used to control whether an existing call is retained, dropped, or dropped and reestablished. (In some cases it will be desired to do another o/a while leaving the pstn call undisturbed. In other cases it may the explicit intent to cause the call to be reestablished.) 5.6 Is there a reason why you don't use the definition of an E.164 number from RFC 3966, rather than using your own? What is the significance of making the "+" optional? And why is caller-id-value defined differently than e164-address? Figure 4, and others: The E.164 number used (+15551234) isn't a valid one for country code 1. General Comment: Everything is described, and examples show, only a single m= line, and all the cs-correlation and setup things used within that one media section. There is no explanation of what to do if there is more than one pstn m= line, as might arise if the intent is to have an audio/video call. Without any explanation, it would seem that everything should be specified separately for each m= line, which might result in *two* pstn calls. Presumably that isn't want is desired. More definition is needed if the same pstn call is to be used for two media streams. Thanks, Paul On 10/13/11 8:21 AM, Simo.Veikkolainen@nokia.com wrote: > Hello all, > > We just submitted a new version of draft-ietf-mmusic-sdp-cs. > > Changes in the -08 version include: > > Added a new section "Offer/Answer extensions" detailing the process of handling the O/A exchange. > > Clarified that multiple extensions for cs-correlation are allowed. > > Added a request for IANA to create a sub-registry for "cs-correlation" attribute values, with "Specification Required" policy. > > Clarified how dynamic payloads are handled. Basically we stick to normal SDP processing here, i.e. if dynamic payload types are used, a=rtpmap attribute(s) are required. This may need more thought still. > > Changed a lot of SHOULDs into MUSTs. > > Extended the example in Section 6. > > Flemming had a comment on mandating E.164 numbers in the international format. After some thinking, we still say that the enpoints SHOULD include the number in international format. The network may anyway mangle the number presentation, so we thought mandating the intl format is not absolutely necessary. > > TODO: Security considerations needs more work based on Flemming's earlier comments (including caller's E164 number in SDP). > TODO: Clarification on the mechanism works with 3PCC. > TODO:Change the UUIE syntax to allow for a discriminator byte. > > We hope to address the remaning issues still before the IETF submission deadline. > > Regards, > Simo > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org > Sent: 13 October, 2011 15:19 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-08.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 : Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) > Author(s) : Miguel A. Garcia-Martin > Simo Veikkolainen > Filename : draft-ietf-mmusic-sdp-cs-08.txt > Pages : 30 > Date : 2011-10-13 > > This memo describes use cases, requirements, and protocol extensions > for using the Session Description Protocol (SDP) Offer/Answer model > for establishing audio and video media streams over circuit-switched > bearers in the Public Switched Telephone Network (PSTN). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.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-ietf-mmusic-sdp-cs-08.txt > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From keith.drage@alcatel-lucent.com Sat Oct 15 05:52:57 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 B1B8921F8B42 for ; Sat, 15 Oct 2011 05:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.049 X-Spam-Level: X-Spam-Status: No, score=-105.049 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxlktwb5ZwOU for ; Sat, 15 Oct 2011 05:52:56 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA7A21F8B1A for ; Sat, 15 Oct 2011 05:52:56 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9FCqooG029066 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 15 Oct 2011 14:52:50 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 15 Oct 2011 14:52:50 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "mmusic@ietf.org" Date: Sat, 15 Oct 2011 14:52:49 +0200 Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.txt Thread-Index: AcyKoZ4KXPu3uF1/QZuZsUetauNRpgAUMeOA Message-ID: References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> <4E98838A.7040206@alum.mit.edu> In-Reply-To: <4E98838A.7040206@alum.mit.edu> 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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: Sat, 15 Oct 2011 12:52:57 -0000 Paul wrote > 5.2.1 >=20 > This says addresses for the E164 address type are represented according > to ITU-T E.164. If I have followed the reference correctly, it only > specifies the country codes, not the encoding of numbers including > country codes. I think it would be better to define this by reference to > RFC 3966 (TEL) and to either telephone-subscriber, or global-number, or > global-number-digits defined there. (I'm not sure which of those is most > appropriate for your use.) > E.164 defines the country codes in an annex. The main body of the recommend= ation defines the structure of a number consisting of country code and nati= onal significant number for international number. And national and subscrib= er prefix and appropriate part of the number for national number and subscr= iber number usage. The definition also includes various length limitations,= and identifies local service numbers. However I suspect that the reference here needs to explicitly limit it to i= nternational numbers defined by E.164. I see no need to go via RFC 3966 which becomes only significant in terms of= referencing if you want to define local numbers. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: 14 October 2011 19:47 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.txt >=20 > I reviewed draft-ietf-mmusic-sdp-cs-08 and have a number of comments: >=20 > 5.2.1 >=20 > This says addresses for the E164 address type are represented according > to ITU-T E.164. If I have followed the reference correctly, it only > specifies the country codes, not the encoding of numbers including > country codes. I think it would be better to define this by reference to > RFC 3966 (TEL) and to either telephone-subscriber, or global-number, or > global-number-digits defined there. (I'm not sure which of those is most > appropriate for your use.) >=20 > Also, you give the example >=20 > c=3DPSTN - - >=20 > That requires that "-" be a defined address type. AFAIK it is not. > Did you mean it to be >=20 > c=3DPSTN E164 - >=20 > 5.2.3.1 >=20 > The syntax given for a=3Dcs-correlation is inconsistent with the syntax i= n > 5.6 and with usage throughout the document. >=20 > 5.2.3.3 >=20 > You specify that the UUIE has a max size of 35 or 131 octets. AFAIK the > actual max information content is actually either 32 or 128 octets plus > a leading protocol discriminator byte. >=20 > Its unclear what you intend to be included in the specified uuie element > in the sdp - does it include the protocol discriminator or not? >=20 > Also, the content and protocol discriminator contain octets, not just > alphanumerics, but the syntax in 5.6 only permits alphanumerics. Is it > your *intent* to limit the protocol discriminator and the value to that > subset described by alphanumerics? And is that a reasonable thing to do? > (For this use, it *might* be sufficient to prescribe a specific value > for the protocol discriminator.) >=20 > 5.5.1 / 5.5.4 >=20 > The description of a=3Dconnection here is more appropriate to section > 5.5.4. Here, for the initial offer, a=3Dconnection:new is the only thing > that makes sense. >=20 > In 5.5.4 it would be helpful to explain in more detail how a=3Dconnection > is used to control whether an existing call is retained, dropped, or > dropped and reestablished. >=20 > (In some cases it will be desired to do another o/a while leaving the > pstn call undisturbed. In other cases it may the explicit intent to > cause the call to be reestablished.) >=20 > 5.6 >=20 > Is there a reason why you don't use the definition of an E.164 number > from RFC 3966, rather than using your own? What is the significance of > making the "+" optional? And why is caller-id-value defined differently > than e164-address? >=20 > Figure 4, and others: >=20 > The E.164 number used (+15551234) isn't a valid one for country code 1. >=20 > General Comment: >=20 > Everything is described, and examples show, only a single m=3D line, and > all the cs-correlation and setup things used within that one media > section. There is no explanation of what to do if there is more than one > pstn m=3D line, as might arise if the intent is to have an audio/video > call. Without any explanation, it would seem that everything should be > specified separately for each m=3D line, which might result in *two* pstn > calls. Presumably that isn't want is desired. >=20 > More definition is needed if the same pstn call is to be used for two > media streams. >=20 > Thanks, > Paul >=20 > On 10/13/11 8:21 AM, Simo.Veikkolainen@nokia.com wrote: > > Hello all, > > > > We just submitted a new version of draft-ietf-mmusic-sdp-cs. > > > > Changes in the -08 version include: > > > > Added a new section "Offer/Answer extensions" detailing the process of > handling the O/A exchange. > > > > Clarified that multiple extensions for cs-correlation are allowed. > > > > Added a request for IANA to create a sub-registry for "cs-correlation" > attribute values, with "Specification Required" policy. > > > > Clarified how dynamic payloads are handled. Basically we stick to norma= l > SDP processing here, i.e. if dynamic payload types are used, a=3Drtpmap > attribute(s) are required. This may need more thought still. > > > > Changed a lot of SHOULDs into MUSTs. > > > > Extended the example in Section 6. > > > > Flemming had a comment on mandating E.164 numbers in the international > format. After some thinking, we still say that the enpoints SHOULD includ= e > the number in international format. The network may anyway mangle the > number presentation, so we thought mandating the intl format is not > absolutely necessary. > > > > TODO: Security considerations needs more work based on Flemming's > earlier comments (including caller's E164 number in SDP). > > TODO: Clarification on the mechanism works with 3PCC. > > TODO:Change the UUIE syntax to allow for a discriminator byte. > > > > We hope to address the remaning issues still before the IETF submission > deadline. > > > > Regards, > > Simo > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f > Of ext internet-drafts@ietf.org > > Sent: 13 October, 2011 15:19 > > To: i-d-announce@ietf.org > > Cc: mmusic@ietf.org > > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-08.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 : Session Description Protocol (SDP) Extension For > Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In > The Public Switched Telephone Network (PSTN) > > Author(s) : Miguel A. Garcia-Martin > > Simo Veikkolainen > > Filename : draft-ietf-mmusic-sdp-cs-08.txt > > Pages : 30 > > Date : 2011-10-13 > > > > This memo describes use cases, requirements, and protocol extension= s > > for using the Session Description Protocol (SDP) Offer/Answer model > > for establishing audio and video media streams over circuit-switche= d > > bearers in the Public Switched Telephone Network (PSTN). > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.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-ietf-mmusic-sdp-cs-08.txt > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From capelastegui@dit.upm.es Sat Oct 15 06:49:08 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 25BE021F8B54 for ; Sat, 15 Oct 2011 06:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esT+-UeEAwPD for ; Sat, 15 Oct 2011 06:49:07 -0700 (PDT) Received: from mail.dit.upm.es (mail.dit.upm.es [138.4.2.7]) by ietfa.amsl.com (Postfix) with ESMTP id 537D521F8B48 for ; Sat, 15 Oct 2011 06:49:05 -0700 (PDT) Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:1a03]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id p9EGI7U5007989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2011 18:18:07 +0200 Received: from delta (delta.dit.upm.es [138.4.7.204]) (authenticated bits=0) by correo.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9EGHr9w002491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Oct 2011 18:17:55 +0200 From: "Pedro Capelastegui" To: "'IETF - MMUSIC'" , "'Bert Greevenbosch'" Date: Fri, 14 Oct 2011 18:18:10 +0200 Message-ID: <000f01cc8a8c$dfb1fca0$9f15f5e0$@dit.upm.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CC8A9D.A33CC870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyKijb4TtB/B1/kTfyPYAoYdFul1g== Content-Language: es Subject: [MMUSIC] Comments on draft-greevenbosch-mmusic-signal-3d-format-01 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: Sat, 15 Oct 2011 13:49:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0010_01CC8A9D.A33CC870 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I have reviewed draft-greevenbosch-mmusic-signal-3d-format-01, and I = have the following comments. =20 - Backwards compatibility =20 When a 3D-enabled device using this specification calls a legacy device, = it is very likely that the answerer will accept the session and end up = receiving media that it can=E2=80=99t display properly, such as = frame-packed video or a depth map. I think the default behaviour here = should be that whenever the SDP answer omits the 3dFormat attribute, the = offerer only sends 2D video (if available), avoiding further offers if = possible. This speeds up session setup with legacy agents, and prevents = transmitting useless media. =20 To implement this change, I would modify a few paragraphs in section 8. =20 In 8.1 (Frame Packing), replace: =20 =E2=80=9Cthe offerer MAY update the offer with a 2D stream. If the = offerer is the streaming server, it MAY choose to stream the frame = packed video as it is.=E2=80=9C =20 with =20 =E2=80=9Cthe offerer SHOULD treat that media stream as a 2D = stream.=E2=80=9D =20 In 8.2 (2D and auxiliary as a single stream), replace: =20 =E2=80=9C the offerer MAY update its offer by offering only a 2D video = stream.=E2=80=9D =20 with =20 =E2=80=9CSHOULD treat that media stream as a 2D stream.=E2=80=9D =20 In 8.3 (2D and auxiliary as two separate streams), replace: =20 " If the answerer selects only the auxiliary video, the offerer SHOULD = update its offer without the auxiliary video." =20 with =20 "If the answerer selects only the auxiliary video, the offerer MAY = treat that stream as a 2D video stream. If it does not, the offerer = SHOULD update its offer without the auxiliary video." =E2=80=83 =20 - H.264/MVC =20 I think that compatibility with the MVC format is a must for this = specification. This will probably require defining new types of 3D = formats and components. Unfortunately, the payload format for MVC = (draft-ietf-payload-rtp-mvc-0) is still unfinished, with most of the SDP = section missing=E2=80=A6 =20 =20 - Depth Maps in auxiliary streams. =20 Some transmission options use a single stream containing one view = (centre or left) and its associated depth map (or parallax map). = However, there is no mention as to how the view and map are packed in = that stream. I suppose the specification assumes the use of the = auxiliary data format defined in MPEG-C part 3, but this should probably = be indicated explicitly. =20 Also, perhaps the =E2=80=9C2DA=E2=80=9D format should leave the door = open to alternate packing mechanisms other than MPEG-C part 3. I = don=E2=80=99t know of any currently existing alternatives, but it is not = unreasonable to expect them at some point in the future. =20 =20 - Parallax Maps =20 The draft provides no reference for the use of parallax maps, so = it=E2=80=99s probably worth mentioning that they are defined, like depth = maps, in [ISO/IEC 23002-3]. Also, I have not found any examples of 3D = video applications based on parallax maps in the literature. How likely = is it that this scenario will see actual use? =20 =20 - Frame Sequential packing =20 I think that the mechanism for identifying L- and R- streams in a frame = sequential stream should be clearly explained. =20 =20 - Multiple 3D streams =20 On page 14, it says that =E2=80=9CThe answerer SHOULD select only one 3D = format=E2=80=9D. This means that, for any given session, only one 3D = video stream can be used. I think this is too limiting, since it = prevents describing sessions where one agent has multiple 3D displays, = among others.=20 =20 =20 - Multiple Depth Maps. =20 The document assumes that depth maps will only be used in 2D+depth = streams. However, I think that the combination of multiple views and = depth maps (e.g. L/R views and 2 depth maps) is an interesting scenario = that may deserve consideration. =20 =20 Regards, Pedro =20 =20 -------------------------------------------------------------------------= -- =20 Pedro Capelastegui Researcher Universidad Polit=C3=A9cnica de Madrid ------=_NextPart_000_0010_01CC8A9D.A33CC870 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have = reviewed draft-greevenbosch-mmusic-signal-3d-format-01, and I have the = following comments.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Backwards = compatibility

 

When a = 3D-enabled device using this specification calls a legacy device, it is = very likely that the answerer will accept the session and end up = receiving media that it can=E2=80=99t display properly, such as = frame-packed video or a depth map. I think the default behaviour here = should be that whenever the SDP answer omits the 3dFormat attribute, the = offerer only sends 2D video (if available), avoiding further offers if = possible. This speeds up session setup with legacy agents, and prevents = transmitting useless media.

 

To = implement this change, I would modify a few paragraphs in section = 8.

 

In 8.1 (Frame Packing), replace:

 

=E2=80=9Cthe offerer MAY update the offer with a = 2D stream.=C2=A0 If the offerer is the streaming server, it=C2=A0 MAY = choose to stream the frame packed video as it = is.=E2=80=9C

 

with

 

=E2=80=9Cthe offerer SHOULD treat that media = stream as a 2D stream.=E2=80=9D

 

In 8.2 = (2D and auxiliary as a single stream), replace:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=E2=80=9C the offerer MAY update its offer by = offering only a 2D=C2=A0 video stream.=E2=80=9D

 

with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=E2=80=9CSHOULD treat that media stream as a 2D = stream.=E2=80=9D

 

In 8.3 = (2D and auxiliary as two separate streams), replace:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

" If the answerer selects only the = auxiliary video, the offerer=C2=A0 SHOULD update its offer without the = auxiliary video."

 

with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

"If the answerer selects only the auxiliary = video, the offerer=C2=A0 MAY treat that stream as a 2D video stream. If = it does not, the offerer SHOULD update its offer without the auxiliary = video."

=E2=80=83

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - H.264/MVC

 

I = think that compatibility with the MVC format is a must for this = specification. This will probably require defining new types of 3D = formats and components. Unfortunately, the payload format for MVC = (draft-ietf-payload-rtp-mvc-0) is still unfinished, with most of the SDP = section missing=E2=80=A6

 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Depth Maps in auxiliary = streams.

 

Some = transmission options use a single stream containing one view (centre or = left) and its associated depth map (or parallax map). However, there is = no mention as to how the view and map are packed in that stream. I = suppose the specification assumes the use of the auxiliary data format = defined in MPEG-C part 3, but this should probably be indicated = explicitly.

 

Also, = perhaps the =E2=80=9C2DA=E2=80=9D format should leave the door open to = alternate packing mechanisms other than MPEG-C part 3. I don=E2=80=99t = know of any currently existing alternatives, but it is not unreasonable = to expect them at some point in the future.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Parallax = Maps

 

The draft provides no reference for the use of = parallax maps, so it=E2=80=99s probably worth mentioning that they are = defined, like depth maps, in [ISO/IEC 23002-3]. Also, I have not found = any examples of 3D video applications based on parallax maps in the = literature.=C2=A0 How likely is it that this scenario will see actual = use?

 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Frame Sequential = packing

 

I = think that the mechanism for identifying L- and R- streams in a frame = sequential stream should be clearly explained.

 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Multiple 3D = streams

 

On = page 14, it says that =E2=80=9CThe answerer SHOULD select only one 3D = format=E2=80=9D. This means that, for any given session, only one 3D = video stream can be used. I think this is too limiting, since it = prevents describing sessions where one agent has multiple 3D displays, = among others.

 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Multiple Depth = Maps.

 

The document assumes that depth maps will only be = used in 2D+depth streams. However, I think that the combination of = multiple views and depth maps (e.g. L/R views and 2 depth maps) is an = interesting scenario that may deserve consideration.

 

 

Regards,

Pedro

 

 

----------------------------------------------------= -----------------------

 

Pedro = Capelastegui

Researcher

Universidad Polit=C3=A9cnica de = Madrid

------=_NextPart_000_0010_01CC8A9D.A33CC870-- From miguel.a.garcia@ericsson.com Sun Oct 16 01:25:17 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 A1DF221F8726 for ; Sun, 16 Oct 2011 01:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9rvcDfjWFTv for ; Sun, 16 Oct 2011 01:25:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3772D21F85F1 for ; Sun, 16 Oct 2011 01:25:15 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-56-4e9a94ea60cd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4B.2F.20773.AE49A9E4; Sun, 16 Oct 2011 10:25:14 +0200 (CEST) Received: from [159.107.48.85] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Sun, 16 Oct 2011 10:25:14 +0200 Message-ID: <4E9A94E8.3040804@ericsson.com> Date: Sun, 16 Oct 2011 10:25:12 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> <4E98838A.7040206@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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: Sun, 16 Oct 2011 08:25:17 -0000 Hi Keith. I am a bit confused with your comment indicated that the reference should be limited to international numbers defined by E.164. I think E.164 is all about international numbers. As a matter of fact, the title of E.164 is "The international public telecommunication numbering plan", and the scope clearly indicates that it is about international numbers. However, I think we need to elaborate a bit more the '+' sign, which is not part of the E.164 specification, but a common trick to represent a full international E.164 number. /Miguel On 15/10/2011 14:52, DRAGE, (Keith) wrote: > Paul wrote > >> 5.2.1 >> >> This says addresses for the E164 address type are represented >> according to ITU-T E.164. If I have followed the reference >> correctly, it only specifies the country codes, not the encoding of >> numbers including country codes. I think it would be better to >> define this by reference to RFC 3966 (TEL) and to either >> telephone-subscriber, or global-number, or global-number-digits >> defined there. (I'm not sure which of those is most appropriate for >> your use.) >> > > E.164 defines the country codes in an annex. The main body of the > recommendation defines the structure of a number consisting of country > code and national significant number for international number. And > national and subscriber prefix and appropriate part of the number for > national number and subscriber number usage. The definition also > includes various length limitations, and identifies local service > numbers. > > However I suspect that the reference here needs to explicitly limit it > to international numbers defined by E.164. > > I see no need to go via RFC 3966 which becomes only significant in > terms of referencing if you want to define local numbers. > > Regards > > Keith > >> -----Original Message----- From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 14 >> October 2011 19:47 To: mmusic@ietf.org Subject: Re: [MMUSIC] FW: I-D >> Action: draft-ietf-mmusic-sdp-cs-08.txt >> >> I reviewed draft-ietf-mmusic-sdp-cs-08 and have a number of >> comments: >> >> 5.2.1 >> >> This says addresses for the E164 address type are represented >> according to ITU-T E.164. If I have followed the reference >> correctly, it only specifies the country codes, not the encoding of >> numbers including country codes. I think it would be better to >> define this by reference to RFC 3966 (TEL) and to either >> telephone-subscriber, or global-number, or global-number-digits >> defined there. (I'm not sure which of those is most appropriate for >> your use.) >> >> Also, you give the example >> >> c=PSTN - - >> >> That requires that "-" be a defined address type. AFAIK it is not. >> Did you mean it to be >> >> c=PSTN E164 - >> >> 5.2.3.1 >> >> The syntax given for a=cs-correlation is inconsistent with the >> syntax in 5.6 and with usage throughout the document. >> >> 5.2.3.3 >> >> You specify that the UUIE has a max size of 35 or 131 octets. AFAIK >> the actual max information content is actually either 32 or 128 >> octets plus a leading protocol discriminator byte. >> >> Its unclear what you intend to be included in the specified uuie >> element in the sdp - does it include the protocol discriminator or >> not? >> >> Also, the content and protocol discriminator contain octets, not >> just alphanumerics, but the syntax in 5.6 only permits >> alphanumerics. Is it your *intent* to limit the protocol >> discriminator and the value to that subset described by >> alphanumerics? And is that a reasonable thing to do? (For this use, >> it *might* be sufficient to prescribe a specific value for the >> protocol discriminator.) >> >> 5.5.1 / 5.5.4 >> >> The description of a=connection here is more appropriate to section >> 5.5.4. Here, for the initial offer, a=connection:new is the only >> thing that makes sense. >> >> In 5.5.4 it would be helpful to explain in more detail how >> a=connection is used to control whether an existing call is >> retained, dropped, or dropped and reestablished. >> >> (In some cases it will be desired to do another o/a while leaving >> the pstn call undisturbed. In other cases it may the explicit intent >> to cause the call to be reestablished.) >> >> 5.6 >> >> Is there a reason why you don't use the definition of an E.164 >> number from RFC 3966, rather than using your own? What is the >> significance of making the "+" optional? And why is caller-id-value >> defined differently than e164-address? >> >> Figure 4, and others: >> >> The E.164 number used (+15551234) isn't a valid one for country code >> 1. >> >> General Comment: >> >> Everything is described, and examples show, only a single m= line, >> and all the cs-correlation and setup things used within that one >> media section. There is no explanation of what to do if there is >> more than one pstn m= line, as might arise if the intent is to have >> an audio/video call. Without any explanation, it would seem that >> everything should be specified separately for each m= line, which >> might result in *two* pstn calls. Presumably that isn't want is >> desired. >> >> More definition is needed if the same pstn call is to be used for >> two media streams. >> >> Thanks, Paul >> >> On 10/13/11 8:21 AM, Simo.Veikkolainen@nokia.com wrote: >>> Hello all, >>> >>> We just submitted a new version of draft-ietf-mmusic-sdp-cs. >>> >>> Changes in the -08 version include: >>> >>> Added a new section "Offer/Answer extensions" detailing the >>> process of >> handling the O/A exchange. >>> >>> Clarified that multiple extensions for cs-correlation are >>> allowed. >>> >>> Added a request for IANA to create a sub-registry for >>> "cs-correlation" >> attribute values, with "Specification Required" policy. >>> >>> Clarified how dynamic payloads are handled. Basically we stick to >>> normal >> SDP processing here, i.e. if dynamic payload types are used, >> a=rtpmap attribute(s) are required. This may need more thought >> still. >>> >>> Changed a lot of SHOULDs into MUSTs. >>> >>> Extended the example in Section 6. >>> >>> Flemming had a comment on mandating E.164 numbers in the >>> international >> format. After some thinking, we still say that the enpoints SHOULD >> include the number in international format. The network may anyway >> mangle the number presentation, so we thought mandating the intl >> format is not absolutely necessary. >>> >>> TODO: Security considerations needs more work based on Flemming's >> earlier comments (including caller's E164 number in SDP). >>> TODO: Clarification on the mechanism works with 3PCC. TODO:Change >>> the UUIE syntax to allow for a discriminator byte. >>> >>> We hope to address the remaning issues still before the IETF >>> submission >> deadline. >>> >>> Regards, Simo >>> >>> >>> -----Original Message----- From: mmusic-bounces@ietf.org >>> [mailto:mmusic-bounces@ietf.org] On Behalf >> Of ext internet-drafts@ietf.org >>> Sent: 13 October, 2011 15:19 To: i-d-announce@ietf.org Cc: >>> mmusic@ietf.org Subject: [MMUSIC] I-D Action: >>> draft-ietf-mmusic-sdp-cs-08.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 : Session Description Protocol (SDP) Extension >>> For >> Setting Up Audio and Video Media Streams Over Circuit-Switched >> Bearers In The Public Switched Telephone Network (PSTN) >>> Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen >>> Filename : draft-ietf-mmusic-sdp-cs-08.txt Pages >>> : 30 Date : 2011-10-13 >>> >>> This memo describes use cases, requirements, and protocol >>> extensions for using the Session Description Protocol (SDP) >>> Offer/Answer model for establishing audio and video media streams >>> over circuit-switched bearers in the Public Switched Telephone >>> Network (PSTN). >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.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-ietf-mmusic-sdp-cs-08.txt >>> >>> _______________________________________________ >>> mmusic mailing list mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ mmusic mailing >>> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ mmusic mailing list >> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list > mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Sun Oct 16 03:16:34 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 65E9F21F8678 for ; Sun, 16 Oct 2011 03:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZl7VAILDykJ for ; Sun, 16 Oct 2011 03:16:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 98B7B21F84DB for ; Sun, 16 Oct 2011 03:16:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-08-4e9aaef0cc40 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 65.62.13753.0FEAA9E4; Sun, 16 Oct 2011 12:16:16 +0200 (CEST) Received: from [159.107.48.85] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Sun, 16 Oct 2011 12:16:15 +0200 Message-ID: <4E9AAEEF.70001@ericsson.com> Date: Sun, 16 Oct 2011 12:16:15 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> <4E98838A.7040206@alum.mit.edu> In-Reply-To: <4E98838A.7040206@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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: Sun, 16 Oct 2011 10:16:34 -0000 Hi Paul. You can find my comments inline, except for one that we are discussing with Keith in a separate e-mail. On 14/10/2011 20:46, Paul Kyzivat wrote: > I reviewed draft-ietf-mmusic-sdp-cs-08 and have a number of comments: > > 5.2.1 > > This says addresses for the E164 address type are represented according > to ITU-T E.164. If I have followed the reference correctly, it only > specifies the country codes, not the encoding of numbers including > country codes. I think it would be better to define this by reference to > RFC 3966 (TEL) and to either telephone-subscriber, or global-number, or > global-number-digits defined there. (I'm not sure which of those is most > appropriate for your use.) > > Also, you give the example > > c=PSTN - - > > That requires that "-" be a defined address type. AFAIK it is not. > Did you mean it to be > > c=PSTN E164 - No, we meant: c=PSTN - - The idea is frequently a device will know that is Circuit-Switched capable, but it wouldn't know its own E.164 number, or even it is allocated an E.164 number. It could be possible that the device is aware of a different numbering plan (for example, E.212). So, in summary: we want to express that the device has a PSTN Circuit-Switched connection, but it is not aware of its address in any numbering plan. In Section 8.3, we register with IANA both the E.164 and the dash "-" tokens. > > 5.2.3.1 > > The syntax given for a=cs-correlation is inconsistent with the syntax in > 5.6 and with usage throughout the document. I am comparing Sections 5.2.3.1 and 5.6, and the usage throughout the document and I don't find this inconsistency. Can you elaborate a bit more what this inconsistency is? > > 5.2.3.3 > > You specify that the UUIE has a max size of 35 or 131 octets. AFAIK the > actual max information content is actually either 32 or 128 octets plus > a leading protocol discriminator byte. Right. The terminology in Q.931 helps to mislead. The User-User Information Element contains three parts: - 1-octet User-user information element identifier - 1-octet "Length of user-user contents" - 1-octet "Protocol discriminator" - "User Information". The "User Information can be up to 32 or 128 octets, depending on networks. Together with the other 3 octets, it makes a maximum of 35 or 131 octets. I guess the draft should elaborate the composition of this information element and clarify that it includes the 3 initial octets. > > Its unclear what you intend to be included in the specified uuie element > in the sdp - does it include the protocol discriminator or not? Yes, as I described above. > > Also, the content and protocol discriminator contain octets, not just > alphanumerics, but the syntax in 5.6 only permits alphanumerics. Is it > your *intent* to limit the protocol discriminator and the value to that > subset described by alphanumerics? And is that a reasonable thing to do? > (For this use, it *might* be sufficient to prescribe a specific value > for the protocol discriminator.) This is an error that we should fix. It is not the intention of this draft to limit the protocol discriminator, so, we need to address this issue and allow any possible value. We will fix it in the next version of the draft. > > 5.5.1 / 5.5.4 > > The description of a=connection here is more appropriate to section > 5.5.4. Here, for the initial offer, a=connection:new is the only thing > that makes sense. Ok, we can move the a=connection:existing to 5.5.4. > > In 5.5.4 it would be helpful to explain in more detail how a=connection > is used to control whether an existing call is retained, dropped, or > dropped and reestablished. > > > (In some cases it will be desired to do another o/a while leaving the > pstn call undisturbed. In other cases it may the explicit intent to > cause the call to be reestablished.) ok, will do. > > 5.6 > > Is there a reason why you don't use the definition of an E.164 number > from RFC 3966, rather than using your own? RFC 3966 defines how to represent an E.164 number as a URL. Here, we do not intent to use URLs. Additionally, the tel: URL provide representation of either global and local numbers, ISDN subaddresses, extensions, and phone context, which are not intended to be used here. > What is the significance of > making the "+" optional? The only reason I can think, is that the draft has a "SHOULD" strength for using the international format of E.164. If someone really knows what he is doing and can use a national format, it wouldn't use the "+" sign. I recognize that this is not a very strong reason, but it is the only justification I can find. > And why is caller-id-value defined differently > than e164-address? Yes, I think they should be equal. Probably we should get rid of "caller-id-value" and use "e164-address" instead. > Figure 4, and others: > > The E.164 number used (+15551234) isn't a valid one for country code 1. Is it because there are not enough number of digits for the subscriber number? > > General Comment: > > Everything is described, and examples show, only a single m= line, and > all the cs-correlation and setup things used within that one media > section. There is no explanation of what to do if there is more than one > pstn m= line, as might arise if the intent is to have an audio/video > call. Without any explanation, it would seem that everything should be > specified separately for each m= line, which might result in *two* pstn > calls. Presumably that isn't want is desired. > > More definition is needed if the same pstn call is to be used for two > media streams. Yes, I agree with you. I think we should add a section describing how to setup an circuit-switched audio/video call. > > Thanks, > Paul Thanks for your comments, Miguel > > On 10/13/11 8:21 AM, Simo.Veikkolainen@nokia.com wrote: >> Hello all, >> >> We just submitted a new version of draft-ietf-mmusic-sdp-cs. >> >> Changes in the -08 version include: >> >> Added a new section "Offer/Answer extensions" detailing the process of handling the O/A exchange. >> >> Clarified that multiple extensions for cs-correlation are allowed. >> >> Added a request for IANA to create a sub-registry for "cs-correlation" attribute values, with "Specification Required" policy. >> >> Clarified how dynamic payloads are handled. Basically we stick to normal SDP processing here, i.e. if dynamic payload types are used, a=rtpmap attribute(s) are required. This may need more thought still. >> >> Changed a lot of SHOULDs into MUSTs. >> >> Extended the example in Section 6. >> >> Flemming had a comment on mandating E.164 numbers in the international format. After some thinking, we still say that the enpoints SHOULD include the number in international format. The network may anyway mangle the number presentation, so we thought mandating the intl format is not absolutely necessary. >> >> TODO: Security considerations needs more work based on Flemming's earlier comments (including caller's E164 number in SDP). >> TODO: Clarification on the mechanism works with 3PCC. >> TODO:Change the UUIE syntax to allow for a discriminator byte. >> >> We hope to address the remaning issues still before the IETF submission deadline. >> >> Regards, >> Simo >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org >> Sent: 13 October, 2011 15:19 >> To: i-d-announce@ietf.org >> Cc: mmusic@ietf.org >> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-08.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 : Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) >> Author(s) : Miguel A. Garcia-Martin >> Simo Veikkolainen >> Filename : draft-ietf-mmusic-sdp-cs-08.txt >> Pages : 30 >> Date : 2011-10-13 >> >> This memo describes use cases, requirements, and protocol extensions >> for using the Session Description Protocol (SDP) Offer/Answer model >> for establishing audio and video media streams over circuit-switched >> bearers in the Public Switched Telephone Network (PSTN). >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.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-ietf-mmusic-sdp-cs-08.txt >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Sun Oct 16 13:42:35 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 48D3521F8A80 for ; Sun, 16 Oct 2011 13:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCe3rV5AQTcK for ; Sun, 16 Oct 2011 13:42:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D6B4921F85DB for ; Sun, 16 Oct 2011 13:42:33 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-23-4e9b41b85817 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5D.49.20773.8B14B9E4; Sun, 16 Oct 2011 22:42:32 +0200 (CEST) Received: from [159.107.48.85] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Sun, 16 Oct 2011 22:42:31 +0200 Message-ID: <4E9B41B6.9070506@ericsson.com> Date: Sun, 16 Oct 2011 22:42:30 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: kaynam.hedayat@exfo.com, vnagarjuna@saperix.com, paulej@packetizer.com, arjun@hsc.com, chelliah@cisco.com, nathan@robotics.net, mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Comments to draft-ietf-mmusic-media-loopback-16 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, 16 Oct 2011 20:42:35 -0000 Hi, Here are my comments to version 16 of the media loopback draft. - Since this draft defines both an SDP extension and an RTP payload extension, I wonder whether this draft has been reviewed by the AVTEXT working group. Can the authors comment? - Continuing with the comment above, I noticed that the title of the draft reflects the SDP extension, but is mute towards the RTP extension. I recommend to become "An extension to SDP and RTP for media loopback". This clearly reflects the actual contents of the draft. - Terminology. I don't find any justification for this draft to depend on RFC 3261 and for making references to SIP INVITEs and alike. Instead, the draft should be based on the SDP offer/answer model (RFC 3264). As part of this, I will add a paragraph in Section 2 saying that ... "The following terms are borrowed from RFC 3264: offer, offerer, answer, answerer". I will rename section 3 to "SDP offerer behavior", Section 4 to "SDP answerer behavior". An in general, I will not talk of the "offering entity" (section 3), but the "offerer", or the "answering entity" (section 4), but the "answerer". - I will add a new paragraph at the end of Section 3 indicating where the "loopback" attribute is defined. - Section 4, the last paragraph is not correct, because it puts a normative requirement (MAY) for answerers that are not compliant with this specification. So, if an answerer is not compliant with this specification, how can it comply with the normative MAY? I suggest to replace the "MAY" with "is expected". - I would rename Section 5 to "New SDP attributes" - I would start Section 5.1 with a sentence that says: "This specification defines a new 'loopback' attribute which indicates the type of loopback that the entity is able to do". - The syntax of the loopback attribute in Section 5.1 can be enhanced. I believe this one is more according to what we are used in SDP (only the first three lines differ with the draft): attribute /= loopback-attr ; attribute defined in RFC 4566 loopback-attr = "loopback:" loopback-type loopback-type = loopback-choice [1*SP loopback-choice] loopback-choice = loopback-type-pkt / loopback-type-media loopback-type-pkt = "rtp-pkt-loopback" loopback-type-media = "rtp-media-loopback" - The last two paragraphs in Section 5.1 describe the packet loopback and the media loopback. However, in Section 1.1, there are three modes defined. I would like to have a matching between the two values and the three modes. For example, you could add a sentence indicating in each of these two values "this value is used when the loopback is of type xxx (see Section 1.X)." - Section 5.2 actually defines two attributes (loopback-source and loopback-mirror). First, I would like to ask if the authors have considered to have a single attribute, that you could cal "loopback-mode", with two values "source" and "mirror". If this is not desirable, then you need to split section 5.2 into two sections, each one devoted to a single attribute. Make sure that the name of the attribute is listed in the title of the section, so that it is also visible in the table of contents. - If you continue with the two attributes approach, then the syntax for one of then would be: attribute /= loopback-src-attr ; attribute defined in RFC 4566 loopback-src-attr = "loopback-source:" fmt *(SP fmt) ; fmt defined in RFC 4566 - Section 5.3, after the example. There is a note that contains a normative statement (MUST NOT). In principle, notes should be informative by nature, so just remove the word "Note:" from the beginning of the paragraph. - Section 5.3, the paragraph after the Note refers to the "m= line" when the draft says "The port number and the address in the offer (m= line)..." However, the address in SDP goes in the c= line, therefore, whenever you refer to port number and address, you should refer to the "m/c= lines". - Still talking of the same sentence as before. The sentence reads: The port number and the address in the offer (m= line) indicate where the offerer would like to send and receive the media stream. I disagree with the "send" in the above sentence. According to RFC 3264, the port number and the address in either the offer or the answer represents where the offerer or answerer would like to receive the media stream, respectively. Note that if you really want to keep the "send" in the above sentence, you need to mandate the usage of symmetric RTP and RTCP, RFC 4961. I haven't seen that dependency so far, so I believe that the "send" is incorrect in the sentence. Also note that the resolution of this issue applies to Section 5.4, first paragraph as well. - Examples at the end of Section 5.3 It would be nice to elaborate these examples, describing what they are showing. Also, at this point in the draft, the "encaprtp" and "rtploopback" tokens have not been introduced, so it would be nice to point to the sections where it will later be defined. - Section 5.4, first paragraph, first sentence, replace "a loopback answer" with "an SDP answer". Later in this same paragraph replace "offerere" with "offerer". - There is some missing words in the second sentence of the first paragraph in Section 5.4. The sentence is incomplete. - Section 5.4, second paragraph, write "attributes" in plural in the first sentence. - Section 5.5, first and second sentences, read: The answer to a loopback-source MUST be loopback-mirror. The answer to a loopback-mirror MUST be loopback-source. First, the sentences should be expressed in terms of "SDP offer" and "SDP answer" "containing a loopback-source" or "loopback-mirror". For example: An offer containing a "loopback-source" attribute must be answered with an SDP answer containing a "loopback-mirror attribute in the same media description. An offer containing... But, having said that... I wonder whether the above sentence makes sense in this section. This section is titled "Offerer processing of the answer". Therefore, I expect to find there what the offerer should do when it receives an SDP answer, not what the answerer should do to process the offer and generate the answer. So, move these two sentences to the Section 5.4. - The third and fourth sentences in Section 5.5 read: The loopback-mode line MUST contain at least one codec the answerer is willing to send or receive depending on whether it is the loopback- source or the loopback-mirror. In addition, the "m=" line MUST contain at least one codec that the answerer is willing to send or receive depending on whether it is the loopback-mirror or the loopback-source. Well, it seems that these sentencse also describe how the answerer generates the answer, so it should be moved to Section 5.4. - Second paragraph in Section 5.5. Replace "target UA" with "answerer". But most important, this paragraph needs to say what happens if the offer receives an answer that does not include the loopback-mirror/loopback-source attribute. I believe it should say that a session is still established, but loopback packets are not expected. It is up to the offerer to close down the session by regular means (high level protocol such as a SIP BYE or sending a new offer with the port number set to zero). - Section 5.6, I wonder way the "may" in the first sentence is not a MAY. - Section 5.6, replace the reference to SIP. You just need the reference to Section 8 of RFC 3264. - Section 7.1.2. The paragraph under "Receive Timestamp: 32 bits". The sentence reads: The Receive timestamp MUST be based on the same clock used by the loopback-source. I wonder if there are mechanisms in place to implement the MUST, i.e., to make sure that exactly the same clock is used by both endpoints. Is there such mechanism? The resolution of this issue also applies to Section 7.2.1. - I don't understand the only normative sentence in Section 7.2 (Direct loopback). It reads: This payload format MUST NOT be used in cases where the MTU on the loopback path will cause fragmentation of looped back RTP packets. So, if direct loopback does not increment the size of the payload, why is there a "MUST NOT". I would understand if the sentence were written in Section 7.1, so that it would be applicable to the Encapsulated Payload Format". But I don't see how this sentence applies to Direct loopback. - Section 10. All the examples, replace "client", "server" and "INVITE request", and "response" with: An [offerer|answerer] sends an SDP [offer|answer] which looks like: - Section 10. In all the examples, replace "s=Example" with "s=" (source, RFC 3264). And you can omit the i= and e= lines as well, they do not really add anything, nor they are mandated. - Section 10.3. Re-title this section to "SDP answer rejecting loopback media". - The note at the end of Section 10.3 reads: NOTE: Loopback request may be rejected by either not including the loopback mode attribute (for backward compatibility) or setting the media port number to zero, or both, in the response. First, I don't like this note here, because it may induce to double specification, specially since you have Section 5.4 that describes how to reject a loopback request. And actually, here you have double incongruent specification. Section 5.4.1 only offers one mechanism for rejecting a session: setting the port to zero like in regular SDP. Nothing is written about rejecting a session by not including the loopback mode attribute. Not including a loopback mode attribute in the answer is not a rejection, it is merely a session with no support for the loopback feature, but the session is established. I recommend to delete this note. - Section 11. I disagree with the dependency on RFC 3261. Please remove. Also, I am surprised of not seen any dependency of the security considerations of RTP/RTCP. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From keith.drage@alcatel-lucent.com Sun Oct 16 14:43:00 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 B5ACB21F8997 for ; Sun, 16 Oct 2011 14:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.809 X-Spam-Level: X-Spam-Status: No, score=-104.809 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+5mXllvKZ9W for ; Sun, 16 Oct 2011 14:42:59 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB2721F886A for ; Sun, 16 Oct 2011 14:42:58 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9GLgqIw002220 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 16 Oct 2011 23:42:52 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 16 Oct 2011 23:42:52 +0200 From: "DRAGE, Keith (Keith)" To: "Miguel A. Garcia" Date: Sun, 16 Oct 2011 23:42:48 +0200 Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.txt Thread-Index: AcyL3SPkLlVrK6xiRzCf1ZNZ0Rnt7wAa0hRQ Message-ID: References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> <4E98838A.7040206@alum.mit.edu> <4E9A94E8.3040804@ericsson.com> In-Reply-To: <4E9A94E8.3040804@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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: Sun, 16 Oct 2011 21:43:00 -0000 I think the issue is that you are variously using all sorts of terminology.= I see in the document: E.164 number in E.164 format E.164 address Your main definition is: For the address type, we initially consider the possibility of describing E.164 telephone numbers. We define a new "E164" address type. When used, the "E164" address type indicates that the connection address contains a telephone number represented according to the ITU-T E.164 [ITU.E164.1991] recommendation. Even if the prime purpose of E.164 is to define international numbers there= are multiple types of number defined in E.164, e.g.=20 4.10 global subscriber number (GSN) 4.18 national (significant) number [N(S)N] 4.24 subscriber number (SN) The definition you are looking for is: 4.16 international public telecommunication number F: num=E9ro de t=E9l=E9communications publiques internationales S: n=FAmero de telecomunicaciones p=FAblicas internacionales A string of decimal digits that, for a geographic country code, uniquely id= entifies a subscriber or a point where a service is provided. For the case = of a global service code, it identifies the subscriber of the service. For = Networks, it identifies a subscriber of the Network. An international public telecommunication number (hereafter referred to as = "international E.164 numbers") can act in the "role" of both a name and an = address. Portability is reducing a number's role as an address. Numbers are= increasingly acting in the role of a name only. The number, which includes the country code and subsequent digits, but not = the international prefix, contains the information necessary to route the c= all to this termination point on a public network (it may also contain the = supplementary information necessary to forward it on a private network). It= is sometimes referred to as an "E.164 number" or "international number". So my view is that your main definition can be construed as referring to an= y of the numbers defined in E.164 which I have listed. The term "telephone = number" refers to both national and international numbers.=20 For the remainder of the document, while E.164 number is permissible as an = indication of your required term, I think you would be better using one of = the preferred terms either "international E.164 numbers" or "international = public telecommunication number". Whichever you use, use it consistently th= roughout the document. If you are specifically indicating the address type, I suggest you consiste= ntly put the E.164 in quotation marks, followed by the words "address type"= in full. The "+" is actually part of ITU-T Recommendation E.123: "Notation for natio= nal and international telephone numbers, e-mail addresses and Web addresses= ". However you cannot use E.123 as a blanket reference as it also includes = space characters and parentheses, unless you wish these to also be valid. Regards Keith > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 16 October 2011 09:25 > To: DRAGE, Keith (Keith) > Cc: Paul Kyzivat; mmusic@ietf.org > Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.txt >=20 > Hi Keith. >=20 > I am a bit confused with your comment indicated that the reference should > be limited to international numbers defined by E.164. I think E.164 is > all about international numbers. As a matter of fact, the title of E.164 > is "The international public telecommunication numbering plan", and the > scope clearly indicates that it is about international numbers. >=20 > However, I think we need to elaborate a bit more the '+' sign, which is > not part of the E.164 specification, but a common trick to represent a > full international E.164 number. >=20 > /Miguel >=20 > On 15/10/2011 14:52, DRAGE, (Keith) wrote: > > Paul wrote > > > >> 5.2.1 > >> > >> This says addresses for the E164 address type are represented > >> according to ITU-T E.164. If I have followed the reference > >> correctly, it only specifies the country codes, not the encoding of > >> numbers including country codes. I think it would be better to > >> define this by reference to RFC 3966 (TEL) and to either > >> telephone-subscriber, or global-number, or global-number-digits > >> defined there. (I'm not sure which of those is most appropriate for > >> your use.) > >> > > > > E.164 defines the country codes in an annex. The main body of the > > recommendation defines the structure of a number consisting of country > > code and national significant number for international number. And > > national and subscriber prefix and appropriate part of the number for > > national number and subscriber number usage. The definition also > > includes various length limitations, and identifies local service > > numbers. > > > > However I suspect that the reference here needs to explicitly limit it > > to international numbers defined by E.164. > > > > I see no need to go via RFC 3966 which becomes only significant in > > terms of referencing if you want to define local numbers. > > > > Regards > > > > Keith > > > >> -----Original Message----- From: mmusic-bounces@ietf.org > >> [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 14 > >> October 2011 19:47 To: mmusic@ietf.org Subject: Re: [MMUSIC] FW: I-D > >> Action: draft-ietf-mmusic-sdp-cs-08.txt > >> > >> I reviewed draft-ietf-mmusic-sdp-cs-08 and have a number of > >> comments: > >> > >> 5.2.1 > >> > >> This says addresses for the E164 address type are represented > >> according to ITU-T E.164. If I have followed the reference > >> correctly, it only specifies the country codes, not the encoding of > >> numbers including country codes. I think it would be better to > >> define this by reference to RFC 3966 (TEL) and to either > >> telephone-subscriber, or global-number, or global-number-digits > >> defined there. (I'm not sure which of those is most appropriate for > >> your use.) > >> > >> Also, you give the example > >> > >> c=3DPSTN - - > >> > >> That requires that "-" be a defined address type. AFAIK it is not. > >> Did you mean it to be > >> > >> c=3DPSTN E164 - > >> > >> 5.2.3.1 > >> > >> The syntax given for a=3Dcs-correlation is inconsistent with the > >> syntax in 5.6 and with usage throughout the document. > >> > >> 5.2.3.3 > >> > >> You specify that the UUIE has a max size of 35 or 131 octets. AFAIK > >> the actual max information content is actually either 32 or 128 > >> octets plus a leading protocol discriminator byte. > >> > >> Its unclear what you intend to be included in the specified uuie > >> element in the sdp - does it include the protocol discriminator or > >> not? > >> > >> Also, the content and protocol discriminator contain octets, not > >> just alphanumerics, but the syntax in 5.6 only permits > >> alphanumerics. Is it your *intent* to limit the protocol > >> discriminator and the value to that subset described by > >> alphanumerics? And is that a reasonable thing to do? (For this use, > >> it *might* be sufficient to prescribe a specific value for the > >> protocol discriminator.) > >> > >> 5.5.1 / 5.5.4 > >> > >> The description of a=3Dconnection here is more appropriate to section > >> 5.5.4. Here, for the initial offer, a=3Dconnection:new is the only > >> thing that makes sense. > >> > >> In 5.5.4 it would be helpful to explain in more detail how > >> a=3Dconnection is used to control whether an existing call is > >> retained, dropped, or dropped and reestablished. > >> > >> (In some cases it will be desired to do another o/a while leaving > >> the pstn call undisturbed. In other cases it may the explicit intent > >> to cause the call to be reestablished.) > >> > >> 5.6 > >> > >> Is there a reason why you don't use the definition of an E.164 > >> number from RFC 3966, rather than using your own? What is the > >> significance of making the "+" optional? And why is caller-id-value > >> defined differently than e164-address? > >> > >> Figure 4, and others: > >> > >> The E.164 number used (+15551234) isn't a valid one for country code > >> 1. > >> > >> General Comment: > >> > >> Everything is described, and examples show, only a single m=3D line, > >> and all the cs-correlation and setup things used within that one > >> media section. There is no explanation of what to do if there is > >> more than one pstn m=3D line, as might arise if the intent is to have > >> an audio/video call. Without any explanation, it would seem that > >> everything should be specified separately for each m=3D line, which > >> might result in *two* pstn calls. Presumably that isn't want is > >> desired. > >> > >> More definition is needed if the same pstn call is to be used for > >> two media streams. > >> > >> Thanks, Paul > >> > >> On 10/13/11 8:21 AM, Simo.Veikkolainen@nokia.com wrote: > >>> Hello all, > >>> > >>> We just submitted a new version of draft-ietf-mmusic-sdp-cs. > >>> > >>> Changes in the -08 version include: > >>> > >>> Added a new section "Offer/Answer extensions" detailing the > >>> process of > >> handling the O/A exchange. > >>> > >>> Clarified that multiple extensions for cs-correlation are > >>> allowed. > >>> > >>> Added a request for IANA to create a sub-registry for > >>> "cs-correlation" > >> attribute values, with "Specification Required" policy. > >>> > >>> Clarified how dynamic payloads are handled. Basically we stick to > >>> normal > >> SDP processing here, i.e. if dynamic payload types are used, > >> a=3Drtpmap attribute(s) are required. This may need more thought > >> still. > >>> > >>> Changed a lot of SHOULDs into MUSTs. > >>> > >>> Extended the example in Section 6. > >>> > >>> Flemming had a comment on mandating E.164 numbers in the > >>> international > >> format. After some thinking, we still say that the enpoints SHOULD > >> include the number in international format. The network may anyway > >> mangle the number presentation, so we thought mandating the intl > >> format is not absolutely necessary. > >>> > >>> TODO: Security considerations needs more work based on Flemming's > >> earlier comments (including caller's E164 number in SDP). > >>> TODO: Clarification on the mechanism works with 3PCC. TODO:Change > >>> the UUIE syntax to allow for a discriminator byte. > >>> > >>> We hope to address the remaning issues still before the IETF > >>> submission > >> deadline. > >>> > >>> Regards, Simo > >>> > >>> > >>> -----Original Message----- From: mmusic-bounces@ietf.org > >>> [mailto:mmusic-bounces@ietf.org] On Behalf > >> Of ext internet-drafts@ietf.org > >>> Sent: 13 October, 2011 15:19 To: i-d-announce@ietf.org Cc: > >>> mmusic@ietf.org Subject: [MMUSIC] I-D Action: > >>> draft-ietf-mmusic-sdp-cs-08.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 : Session Description Protocol (SDP) Extension > >>> For > >> Setting Up Audio and Video Media Streams Over Circuit-Switched > >> Bearers In The Public Switched Telephone Network (PSTN) > >>> Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen > >>> Filename : draft-ietf-mmusic-sdp-cs-08.txt Pages > >>> : 30 Date : 2011-10-13 > >>> > >>> This memo describes use cases, requirements, and protocol > >>> extensions for using the Session Description Protocol (SDP) > >>> Offer/Answer model for establishing audio and video media streams > >>> over circuit-switched bearers in the Public Switched Telephone > >>> Network (PSTN). > >>> > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.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-ietf-mmusic-sdp-cs-08.txt > >>> > >>> > _______________________________________________ > >>> mmusic mailing list mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >>> _______________________________________________ mmusic mailing > >>> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > >>> > >> > >> _______________________________________________ mmusic mailing list > >> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list > > mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain From miguel.a.garcia@ericsson.com Sun Oct 16 23:56:02 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 240EC21F8713 for ; Sun, 16 Oct 2011 23:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dS74v3Wh8kJC for ; Sun, 16 Oct 2011 23:56:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7044C21F85A1 for ; Sun, 16 Oct 2011 23:56:00 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-eb-4e9bd17f087e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D3.03.20773.F71DB9E4; Mon, 17 Oct 2011 08:55:59 +0200 (CEST) Received: from [159.107.48.85] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 17 Oct 2011 08:55:58 +0200 Message-ID: <4E9BD17E.8090100@ericsson.com> Date: Mon, 17 Oct 2011 08:55:58 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> <4E98838A.7040206@alum.mit.edu> <4E9A94E8.3040804@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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: Mon, 17 Oct 2011 06:56:02 -0000 Very good comments Keith, thanks. We will have to do a pass throughout the document trying to make it consistent. I think we should be using the term "international E.164 number". And I believe we shouldn't make a reference to E.123, but explain the usage of the plus sign. BR, Miguel On 16/10/2011 23:42, DRAGE, Keith (Keith) wrote: > I think the issue is that you are variously using all sorts of terminology. I see in the document: > > E.164 number > in E.164 format > E.164 address > > Your main definition is: > > For the address type, we initially consider the possibility of > describing E.164 telephone numbers. We define a new "E164" address > type. When used, the "E164" address type indicates that the > connection address contains a telephone number represented according > to the ITU-T E.164 [ITU.E164.1991] recommendation. > > Even if the prime purpose of E.164 is to define international numbers there are multiple types of number defined in E.164, e.g. > > 4.10 global subscriber number (GSN) > 4.18 national (significant) number [N(S)N] > 4.24 subscriber number (SN) > > The definition you are looking for is: > > 4.16 international public telecommunication number > F: numéro de télécommunications publiques internationales > S: número de telecomunicaciones públicas internacionales > A string of decimal digits that, for a geographic country code, uniquely identifies a subscriber or a point where a service is provided. For the case of a global service code, it identifies the subscriber of the service. For Networks, it identifies a subscriber of the Network. > An international public telecommunication number (hereafter referred to as "international E.164 numbers") can act in the "role" of both a name and an address. Portability is reducing a number's role as an address. Numbers are increasingly acting in the role of a name only. > The number, which includes the country code and subsequent digits, but not the international prefix, contains the information necessary to route the call to this termination point on a public network (it may also contain the supplementary information necessary to forward it on a private network). It is sometimes referred to as an "E.164 number" or "international number". > > So my view is that your main definition can be construed as referring to any of the numbers defined in E.164 which I have listed. The term "telephone number" refers to both national and international numbers. > > For the remainder of the document, while E.164 number is permissible as an indication of your required term, I think you would be better using one of the preferred terms either "international E.164 numbers" or "international public telecommunication number". Whichever you use, use it consistently throughout the document. > > If you are specifically indicating the address type, I suggest you consistently put the E.164 in quotation marks, followed by the words "address type" in full. > > The "+" is actually part of ITU-T Recommendation E.123: "Notation for national and international telephone numbers, e-mail addresses and Web addresses". However you cannot use E.123 as a blanket reference as it also includes space characters and parentheses, unless you wish these to also be valid. > > Regards > > Keith > >> -----Original Message----- >> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >> Sent: 16 October 2011 09:25 >> To: DRAGE, Keith (Keith) >> Cc: Paul Kyzivat; mmusic@ietf.org >> Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.txt >> >> Hi Keith. >> >> I am a bit confused with your comment indicated that the reference should >> be limited to international numbers defined by E.164. I think E.164 is >> all about international numbers. As a matter of fact, the title of E.164 >> is "The international public telecommunication numbering plan", and the >> scope clearly indicates that it is about international numbers. >> >> However, I think we need to elaborate a bit more the '+' sign, which is >> not part of the E.164 specification, but a common trick to represent a >> full international E.164 number. >> >> /Miguel >> >> On 15/10/2011 14:52, DRAGE, (Keith) wrote: >>> Paul wrote >>> >>>> 5.2.1 >>>> >>>> This says addresses for the E164 address type are represented >>>> according to ITU-T E.164. If I have followed the reference >>>> correctly, it only specifies the country codes, not the encoding of >>>> numbers including country codes. I think it would be better to >>>> define this by reference to RFC 3966 (TEL) and to either >>>> telephone-subscriber, or global-number, or global-number-digits >>>> defined there. (I'm not sure which of those is most appropriate for >>>> your use.) >>>> >>> >>> E.164 defines the country codes in an annex. The main body of the >>> recommendation defines the structure of a number consisting of country >>> code and national significant number for international number. And >>> national and subscriber prefix and appropriate part of the number for >>> national number and subscriber number usage. The definition also >>> includes various length limitations, and identifies local service >>> numbers. >>> >>> However I suspect that the reference here needs to explicitly limit it >>> to international numbers defined by E.164. >>> >>> I see no need to go via RFC 3966 which becomes only significant in >>> terms of referencing if you want to define local numbers. >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- From: mmusic-bounces@ietf.org >>>> [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 14 >>>> October 2011 19:47 To: mmusic@ietf.org Subject: Re: [MMUSIC] FW: I-D >>>> Action: draft-ietf-mmusic-sdp-cs-08.txt >>>> >>>> I reviewed draft-ietf-mmusic-sdp-cs-08 and have a number of >>>> comments: >>>> >>>> 5.2.1 >>>> >>>> This says addresses for the E164 address type are represented >>>> according to ITU-T E.164. If I have followed the reference >>>> correctly, it only specifies the country codes, not the encoding of >>>> numbers including country codes. I think it would be better to >>>> define this by reference to RFC 3966 (TEL) and to either >>>> telephone-subscriber, or global-number, or global-number-digits >>>> defined there. (I'm not sure which of those is most appropriate for >>>> your use.) >>>> >>>> Also, you give the example >>>> >>>> c=PSTN - - >>>> >>>> That requires that "-" be a defined address type. AFAIK it is not. >>>> Did you mean it to be >>>> >>>> c=PSTN E164 - >>>> >>>> 5.2.3.1 >>>> >>>> The syntax given for a=cs-correlation is inconsistent with the >>>> syntax in 5.6 and with usage throughout the document. >>>> >>>> 5.2.3.3 >>>> >>>> You specify that the UUIE has a max size of 35 or 131 octets. AFAIK >>>> the actual max information content is actually either 32 or 128 >>>> octets plus a leading protocol discriminator byte. >>>> >>>> Its unclear what you intend to be included in the specified uuie >>>> element in the sdp - does it include the protocol discriminator or >>>> not? >>>> >>>> Also, the content and protocol discriminator contain octets, not >>>> just alphanumerics, but the syntax in 5.6 only permits >>>> alphanumerics. Is it your *intent* to limit the protocol >>>> discriminator and the value to that subset described by >>>> alphanumerics? And is that a reasonable thing to do? (For this use, >>>> it *might* be sufficient to prescribe a specific value for the >>>> protocol discriminator.) >>>> >>>> 5.5.1 / 5.5.4 >>>> >>>> The description of a=connection here is more appropriate to section >>>> 5.5.4. Here, for the initial offer, a=connection:new is the only >>>> thing that makes sense. >>>> >>>> In 5.5.4 it would be helpful to explain in more detail how >>>> a=connection is used to control whether an existing call is >>>> retained, dropped, or dropped and reestablished. >>>> >>>> (In some cases it will be desired to do another o/a while leaving >>>> the pstn call undisturbed. In other cases it may the explicit intent >>>> to cause the call to be reestablished.) >>>> >>>> 5.6 >>>> >>>> Is there a reason why you don't use the definition of an E.164 >>>> number from RFC 3966, rather than using your own? What is the >>>> significance of making the "+" optional? And why is caller-id-value >>>> defined differently than e164-address? >>>> >>>> Figure 4, and others: >>>> >>>> The E.164 number used (+15551234) isn't a valid one for country code >>>> 1. >>>> >>>> General Comment: >>>> >>>> Everything is described, and examples show, only a single m= line, >>>> and all the cs-correlation and setup things used within that one >>>> media section. There is no explanation of what to do if there is >>>> more than one pstn m= line, as might arise if the intent is to have >>>> an audio/video call. Without any explanation, it would seem that >>>> everything should be specified separately for each m= line, which >>>> might result in *two* pstn calls. Presumably that isn't want is >>>> desired. >>>> >>>> More definition is needed if the same pstn call is to be used for >>>> two media streams. >>>> >>>> Thanks, Paul >>>> >>>> On 10/13/11 8:21 AM, Simo.Veikkolainen@nokia.com wrote: >>>>> Hello all, >>>>> >>>>> We just submitted a new version of draft-ietf-mmusic-sdp-cs. >>>>> >>>>> Changes in the -08 version include: >>>>> >>>>> Added a new section "Offer/Answer extensions" detailing the >>>>> process of >>>> handling the O/A exchange. >>>>> >>>>> Clarified that multiple extensions for cs-correlation are >>>>> allowed. >>>>> >>>>> Added a request for IANA to create a sub-registry for >>>>> "cs-correlation" >>>> attribute values, with "Specification Required" policy. >>>>> >>>>> Clarified how dynamic payloads are handled. Basically we stick to >>>>> normal >>>> SDP processing here, i.e. if dynamic payload types are used, >>>> a=rtpmap attribute(s) are required. This may need more thought >>>> still. >>>>> >>>>> Changed a lot of SHOULDs into MUSTs. >>>>> >>>>> Extended the example in Section 6. >>>>> >>>>> Flemming had a comment on mandating E.164 numbers in the >>>>> international >>>> format. After some thinking, we still say that the enpoints SHOULD >>>> include the number in international format. The network may anyway >>>> mangle the number presentation, so we thought mandating the intl >>>> format is not absolutely necessary. >>>>> >>>>> TODO: Security considerations needs more work based on Flemming's >>>> earlier comments (including caller's E164 number in SDP). >>>>> TODO: Clarification on the mechanism works with 3PCC. TODO:Change >>>>> the UUIE syntax to allow for a discriminator byte. >>>>> >>>>> We hope to address the remaning issues still before the IETF >>>>> submission >>>> deadline. >>>>> >>>>> Regards, Simo >>>>> >>>>> >>>>> -----Original Message----- From: mmusic-bounces@ietf.org >>>>> [mailto:mmusic-bounces@ietf.org] On Behalf >>>> Of ext internet-drafts@ietf.org >>>>> Sent: 13 October, 2011 15:19 To: i-d-announce@ietf.org Cc: >>>>> mmusic@ietf.org Subject: [MMUSIC] I-D Action: >>>>> draft-ietf-mmusic-sdp-cs-08.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 : Session Description Protocol (SDP) Extension >>>>> For >>>> Setting Up Audio and Video Media Streams Over Circuit-Switched >>>> Bearers In The Public Switched Telephone Network (PSTN) >>>>> Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen >>>>> Filename : draft-ietf-mmusic-sdp-cs-08.txt Pages >>>>> : 30 Date : 2011-10-13 >>>>> >>>>> This memo describes use cases, requirements, and protocol >>>>> extensions for using the Session Description Protocol (SDP) >>>>> Offer/Answer model for establishing audio and video media streams >>>>> over circuit-switched bearers in the Public Switched Telephone >>>>> Network (PSTN). >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.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-ietf-mmusic-sdp-cs-08.txt >>>>> >>>>> >> _______________________________________________ >>>>> mmusic mailing list mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> _______________________________________________ mmusic mailing >>>>> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>>> _______________________________________________ mmusic mailing list >>>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ mmusic mailing list >>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From pkyzivat@alum.mit.edu Mon Oct 17 15:27:33 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 3286A1F0C43 for ; Mon, 17 Oct 2011 15:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En2Rpbet1wsl for ; Mon, 17 Oct 2011 15:27:32 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2A1F0C42 for ; Mon, 17 Oct 2011 15:27:31 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta04.westchester.pa.mail.comcast.net with comcast id lwKD1h0011vXlb854yTY0m; Mon, 17 Oct 2011 22:27:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id lyTX1h02P0tdiYw3dyTXgH; Mon, 17 Oct 2011 22:27:32 +0000 Message-ID: <4E9CABD2.9020200@alum.mit.edu> Date: Mon, 17 Oct 2011 18:27:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> <4E98838A.7040206@alum.mit.edu> <4E9AAEEF.70001@ericsson.com> In-Reply-To: <4E9AAEEF.70001@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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: Mon, 17 Oct 2011 22:27:33 -0000 Miguel - comments inline. Thanks, Paul On 10/16/11 6:16 AM, Miguel A. Garcia wrote: > Hi Paul. > > You can find my comments inline, except for one that we are discussing > with Keith in a separate e-mail. > > On 14/10/2011 20:46, Paul Kyzivat wrote: >> I reviewed draft-ietf-mmusic-sdp-cs-08 and have a number of comments: >> >> 5.2.1 >> >> This says addresses for the E164 address type are represented according >> to ITU-T E.164. If I have followed the reference correctly, it only >> specifies the country codes, not the encoding of numbers including >> country codes. I think it would be better to define this by reference to >> RFC 3966 (TEL) and to either telephone-subscriber, or global-number, or >> global-number-digits defined there. (I'm not sure which of those is most >> appropriate for your use.) >> >> Also, you give the example >> >> c=PSTN - - >> >> That requires that "-" be a defined address type. AFAIK it is not. >> Did you mean it to be >> >> c=PSTN E164 - > > > No, we meant: > > c=PSTN - - > > The idea is frequently a device will know that is Circuit-Switched > capable, but it wouldn't know its own E.164 number, or even it is > allocated an E.164 number. It could be possible that the device is aware > of a different numbering plan (for example, E.212). > > So, in summary: we want to express that the device has a PSTN > Circuit-Switched connection, but it is not aware of its address in any > numbering plan. > > In Section 8.3, we register with IANA both the E.164 and the dash "-" > tokens. OK, I see its registered. And I found it mentioned in passing. But I don't find a specification for what the connection-address may/must be when the addrtype is "-". In 4566 there is: When the is IP4 and IP6, the connection address is defined as follows: o ... It would be helpful if this doc had a similar thing: When the is PSTN, the connection address is defined as follows: o an e164-address When the is "-", the connection address is defined as follows: o the value "-", signifying that the address is unknown. OR o any syntactically valid value, which is to be ignored.. >> 5.2.3.1 >> >> The syntax given for a=cs-correlation is inconsistent with the syntax in >> 5.6 and with usage throughout the document. > > I am comparing Sections 5.2.3.1 and 5.6, and the usage throughout the > document and I don't find this inconsistency. Can you elaborate a bit > more what this inconsistency is? 5.2.3.1 has: a=cs-correlation: callerid: | uuie: | dtmf: | *[extension-name:] This requires callerid, uuid, and dtmf to be mutually exclusive, rather than permitting one of each as 5.6 allows. Also, the ":" and value are required rather than being optional. >> 5.2.3.3 >> >> You specify that the UUIE has a max size of 35 or 131 octets. AFAIK the >> actual max information content is actually either 32 or 128 octets plus >> a leading protocol discriminator byte. > > Right. The terminology in Q.931 helps to mislead. The User-User > Information Element contains three parts: > > - 1-octet User-user information element identifier > - 1-octet "Length of user-user contents" > - 1-octet "Protocol discriminator" > - "User Information". > > The "User Information can be up to 32 or 128 octets, depending on > networks. Together with the other 3 octets, it makes a maximum of 35 or > 131 octets. > > I guess the draft should elaborate the composition of this information > element and clarify that it includes the 3 initial octets. Based on the examples, and some common sense, I think you don't want to specify the first two of the above in the SDP. AFAIK the first has a well defined value, and the second is well defined by counting the bytes in the uuie-value. >> Its unclear what you intend to be included in the specified uuie element >> in the sdp - does it include the protocol discriminator or not? > > Yes, as I described above. > >> >> Also, the content and protocol discriminator contain octets, not just >> alphanumerics, but the syntax in 5.6 only permits alphanumerics. Is it >> your *intent* to limit the protocol discriminator and the value to that >> subset described by alphanumerics? And is that a reasonable thing to do? >> (For this use, it *might* be sufficient to prescribe a specific value >> for the protocol discriminator.) > > This is an error that we should fix. It is not the intention of this > draft to limit the protocol discriminator, so, we need to address this > issue and allow any possible value. We will fix it in the next version > of the draft. > > > >> >> 5.5.1 / 5.5.4 >> >> The description of a=connection here is more appropriate to section >> 5.5.4. Here, for the initial offer, a=connection:new is the only thing >> that makes sense. > > Ok, we can move the a=connection:existing to 5.5.4. > >> >> In 5.5.4 it would be helpful to explain in more detail how a=connection >> is used to control whether an existing call is retained, dropped, or >> dropped and reestablished. > > >> >> (In some cases it will be desired to do another o/a while leaving the >> pstn call undisturbed. In other cases it may the explicit intent to >> cause the call to be reestablished.) > > ok, will do. > > >> >> 5.6 >> >> Is there a reason why you don't use the definition of an E.164 number >> from RFC 3966, rather than using your own? > > RFC 3966 defines how to represent an E.164 number as a URL. Here, we do > not intent to use URLs. Additionally, the tel: URL provide > representation of either global and local numbers, ISDN subaddresses, > extensions, and phone context, which are not intended to be used here. I meant not the entire tel syntax, but by reference to one of the ABNF symbols defined in 3966. That has the benefit of being more accessible to those reading ietf drafts, and to give the syntax in ABNF that can be readily incorporated with the rest of the syntax. Of course that would allowing visual-separator. I don't know if that is a big deal or not. > > What is the significance of >> making the "+" optional? > > The only reason I can think, is that the draft has a "SHOULD" strength > for using the international format of E.164. If someone really knows > what he is doing and can use a national format, it wouldn't use the "+" > sign. I recognize that this is not a very strong reason, but it is the > only justification I can find. Well, if the intent is to allow a national format, then it should be made clear that lack of the "+" means that. (And then how on how one is supposed to know *which* national format.) I realize there is text that says the actual callerid received may not be in E.164 format and so the comparison should take that into account. But I didn't think that applied to the number specified in SDP. > > And why is caller-id-value defined differently >> than e164-address? > > Yes, I think they should be equal. Probably we should get rid of > "caller-id-value" and use "e164-address" instead. > > > >> Figure 4, and others: >> >> The E.164 number used (+15551234) isn't a valid one for country code 1. > > Is it because there are not enough number of digits for the subscriber > number? Right. Its just a nit. There is no area code in it. >> General Comment: >> >> Everything is described, and examples show, only a single m= line, and >> all the cs-correlation and setup things used within that one media >> section. There is no explanation of what to do if there is more than one >> pstn m= line, as might arise if the intent is to have an audio/video >> call. Without any explanation, it would seem that everything should be >> specified separately for each m= line, which might result in *two* pstn >> calls. Presumably that isn't want is desired. >> >> More definition is needed if the same pstn call is to be used for two >> media streams. > > Yes, I agree with you. I think we should add a section describing how to > setup an circuit-switched audio/video call. > >> >> Thanks, >> Paul > > Thanks for your comments, > > Miguel > > >> >> On 10/13/11 8:21 AM, Simo.Veikkolainen@nokia.com wrote: >>> Hello all, >>> >>> We just submitted a new version of draft-ietf-mmusic-sdp-cs. >>> >>> Changes in the -08 version include: >>> >>> Added a new section "Offer/Answer extensions" detailing the process >>> of handling the O/A exchange. >>> >>> Clarified that multiple extensions for cs-correlation are allowed. >>> >>> Added a request for IANA to create a sub-registry for >>> "cs-correlation" attribute values, with "Specification Required" policy. >>> >>> Clarified how dynamic payloads are handled. Basically we stick to >>> normal SDP processing here, i.e. if dynamic payload types are used, >>> a=rtpmap attribute(s) are required. This may need more thought still. >>> >>> Changed a lot of SHOULDs into MUSTs. >>> >>> Extended the example in Section 6. >>> >>> Flemming had a comment on mandating E.164 numbers in the >>> international format. After some thinking, we still say that the >>> enpoints SHOULD include the number in international format. The >>> network may anyway mangle the number presentation, so we thought >>> mandating the intl format is not absolutely necessary. >>> >>> TODO: Security considerations needs more work based on Flemming's >>> earlier comments (including caller's E164 number in SDP). >>> TODO: Clarification on the mechanism works with 3PCC. >>> TODO:Change the UUIE syntax to allow for a discriminator byte. >>> >>> We hope to address the remaning issues still before the IETF >>> submission deadline. >>> >>> Regards, >>> Simo >>> >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of ext internet-drafts@ietf.org >>> Sent: 13 October, 2011 15:19 >>> To: i-d-announce@ietf.org >>> Cc: mmusic@ietf.org >>> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-08.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 : Session Description Protocol (SDP) Extension For Setting Up >>> Audio and Video Media Streams Over Circuit-Switched Bearers In The >>> Public Switched Telephone Network (PSTN) >>> Author(s) : Miguel A. Garcia-Martin >>> Simo Veikkolainen >>> Filename : draft-ietf-mmusic-sdp-cs-08.txt >>> Pages : 30 >>> Date : 2011-10-13 >>> >>> This memo describes use cases, requirements, and protocol extensions >>> for using the Session Description Protocol (SDP) Offer/Answer model >>> for establishing audio and video media streams over circuit-switched >>> bearers in the Public Switched Telephone Network (PSTN). >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.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-ietf-mmusic-sdp-cs-08.txt >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > From fandreas@cisco.com Mon Oct 17 18:58:16 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 F34BD1F0C4B for ; Mon, 17 Oct 2011 18:58:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaw9OKxCw69Q for ; Mon, 17 Oct 2011 18:58:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 43A681F0C43 for ; Mon, 17 Oct 2011 18:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=3851; q=dns/txt; s=iport; t=1318903095; x=1320112695; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+EP9q2GwHlZxsgB30eYGo8cmhTsq++QcBcLKCN/f8D8=; b=cI11yWDcdiXrVmFrTPGyCe31isIbMcR79wz0qOf9x3Yv3C43zOt1oTiY ue4jaJDvpnF1KRKXu464nnrKcmOJeEEqk1Z6+Vh5IgHq7Pm2AZa/WNMG9 PYD0Cu/6ZDX+bjSYhQsPmaXqolvaAJxFqBNAmWrZGtaAYsFInJ2HcDpUH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALDcnE6tJXG+/2dsb2JhbABDqFmBBYFuAQEBAQIBEgElNgoBBQsLDgoJFg8JAwIBAgFFBg0BBwEBBRIHh10Il2EBnwiICASTfZFx X-IronPort-AV: E=Sophos;i="4.69,362,1315180800"; d="scan'208";a="29092197" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 18 Oct 2011 01:58:14 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9I1wD5u007685; Tue, 18 Oct 2011 01:58:14 GMT Message-ID: <4E9CDD35.6020304@cisco.com> Date: Mon, 17 Oct 2011 21:58:13 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> In-Reply-To: <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic , "" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 18 Oct 2011 01:58:16 -0000 On 10/12/11 10:59 AM, Hadriel Kaplan wrote: > On Oct 8, 2011, at 8:54 AM, Flemming Andreasen wrote: > > >> The issue was discussed on the mailing list in August, where the authors suggested it as a path forward and the chairs asked the WG for feedback on this approach, see e.g. >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg08857.html >> >> The issue was also discussed in the last IETF MMUSIC meeting (see http://www.ietf.org/proceedings/81/minutes/mmusic.txt) >> >> To date, we have only seen opposition to this proposal from you (on both the mailing list and in the meeting), and we are lacking an alternative path forward that can satisfy all involved parties, including the general AD and WG chair concerns around definining an alternative NAT traversal mechanism in this draft without proper discussion and general considerations around the need for an alternative to ICE (per the above thread). >> > In the email thread you referenced above there was in fact someone else who was for keeping the priming mechanism, and it wasn't me. > > In fact, in that whole thread there was only one other person than yourself who was in favor of only having ICE in the draft. Of course there was only one other person than myself who was in favor of keeping the primer mechanism. > > My point is that there has been no consensus either way. The authors only changed the draft due to your objections, afaict, not due to some large consensus to do so. > To be clear, the author(s), myself, and our responsible AD did send a note to the list suggesting this as a path forward. I asked the WG members to speak up if they disagreed with the suggested path forward, and you are the only person to argue against subsequently. While I'll agree there is not unanimous agreement in the group with the direction, I think we need to hear from more than 1 person to declare a lack of (rough) concensus. Having said that, it would be better if we could reach an agreement that is satisfactory to all. >> If you do not find this path forward acceptable, can you please suggest an alternative that satisfies the general concerns around defining an alternative NAT traversal mechanism in this draft ? >> > There have been no "general concerns" as far as I can tell, other than "we have ICE defined so why not use it". Yes - we have a Standards Track and general solution available, so we should use it. > My concerns with mandating *only* ICE as opposed to having a SHOULD use ICE but MAY use primer are detailed here: > http://www.ietf.org/mail-archive/web/mmusic/current/msg08611.html > > There was no feedback/response to that, afaict. > You are referencing a ~6 month old e-mail, and there has since then been several more e-mail exchanges on this subject, an explanation of the issues with the old approach, and a thread plus WG meeting discussion on the need for an ICE alternative (like latching), which didn't garner any takers so far. If you believe those arguments still stand and offer a viable path forward, then please resurrect them (either in the context of this e-mail thread or as a new thread), and we (and hopefully other members of the WG) can discuss further. Again, to recap the concerns with the old approach: - We have a general and Standards Track NAT traversal solution in the form of ICE so we should use it - If there is a need for an ICE alternative, then we need to discuss that more generally and come up with a proper solution - If latching is indeed needed as an alternative solution to ICE, then it needs to be properly documented and the limitations of it spelled out clearly. Furthermore, the loopback draft does not seem like the right place for this. Thanks -- Flemming > -hadriel > > > From miguel.a.garcia@ericsson.com Tue Oct 18 13:03:35 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 0069521F8B87 for ; Tue, 18 Oct 2011 13:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbU4Yu93PNJ6 for ; Tue, 18 Oct 2011 13:03:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAEB21F8B59 for ; Tue, 18 Oct 2011 13:03:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-30-4e9ddb93ccd6 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D2.19.13753.39BDD9E4; Tue, 18 Oct 2011 22:03:32 +0200 (CEST) Received: from [159.107.105.201] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 18 Oct 2011 22:03:31 +0200 Message-ID: <4E9DDB92.5020504@ericsson.com> Date: Tue, 18 Oct 2011 22:03:30 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> <4E98838A.7040206@alum.mit.edu> <4E9AAEEF.70001@ericsson.com> <4E9CABD2.9020200@alum.mit.edu> In-Reply-To: <4E9CABD2.9020200@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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: Tue, 18 Oct 2011 20:03:35 -0000 Hi Paul, see inline comments. On 18/10/2011 0:27, Paul Kyzivat wrote: > Miguel - comments inline. > > Thanks, > Paul > > On 10/16/11 6:16 AM, Miguel A. Garcia wrote: >> Hi Paul. >> >> You can find my comments inline, except for one that we are discussing >> with Keith in a separate e-mail. >> >> On 14/10/2011 20:46, Paul Kyzivat wrote: >>> I reviewed draft-ietf-mmusic-sdp-cs-08 and have a number of comments: >>> >>> 5.2.1 >>> >>> This says addresses for the E164 address type are represented according >>> to ITU-T E.164. If I have followed the reference correctly, it only >>> specifies the country codes, not the encoding of numbers including >>> country codes. I think it would be better to define this by reference to >>> RFC 3966 (TEL) and to either telephone-subscriber, or global-number, or >>> global-number-digits defined there. (I'm not sure which of those is most >>> appropriate for your use.) >>> >>> Also, you give the example >>> >>> c=PSTN - - >>> >>> That requires that "-" be a defined address type. AFAIK it is not. >>> Did you mean it to be >>> >>> c=PSTN E164 - >> >> >> No, we meant: >> >> c=PSTN - - >> >> The idea is frequently a device will know that is Circuit-Switched >> capable, but it wouldn't know its own E.164 number, or even it is >> allocated an E.164 number. It could be possible that the device is aware >> of a different numbering plan (for example, E.212). >> >> So, in summary: we want to express that the device has a PSTN >> Circuit-Switched connection, but it is not aware of its address in any >> numbering plan. >> >> In Section 8.3, we register with IANA both the E.164 and the dash "-" >> tokens. > > OK, I see its registered. And I found it mentioned in passing. > But I don't find a specification for what the connection-address > may/must be when the addrtype is "-". > > In 4566 there is: > > When the is IP4 and IP6, the connection address is defined > as follows: > > o ... > > It would be helpful if this doc had a similar thing: > > When the is PSTN, the connection address is defined > as follows: > > o an e164-address > > When the is "-", the connection address is defined > as follows: > > o the value "-", signifying that the address is unknown. > OR > o any syntactically valid value, which is to be ignored.. Good point. We will add it to the draft. > >>> 5.2.3.1 >>> >>> The syntax given for a=cs-correlation is inconsistent with the syntax in >>> 5.6 and with usage throughout the document. >> >> I am comparing Sections 5.2.3.1 and 5.6, and the usage throughout the >> document and I don't find this inconsistency. Can you elaborate a bit >> more what this inconsistency is? > > 5.2.3.1 has: > > a=cs-correlation: callerid: | > uuie: | > dtmf: | > *[extension-name:] > > This requires callerid, uuid, and dtmf to be mutually exclusive, rather > than permitting one of each as 5.6 allows. Also, the ":" and value are > required rather than being optional. Aha, I see it know. The correct one is in 5.6, so we will change 5.2.3.1. > >>> 5.2.3.3 >>> >>> You specify that the UUIE has a max size of 35 or 131 octets. AFAIK the >>> actual max information content is actually either 32 or 128 octets plus >>> a leading protocol discriminator byte. >> >> Right. The terminology in Q.931 helps to mislead. The User-User >> Information Element contains three parts: >> >> - 1-octet User-user information element identifier >> - 1-octet "Length of user-user contents" >> - 1-octet "Protocol discriminator" >> - "User Information". >> >> The "User Information can be up to 32 or 128 octets, depending on >> networks. Together with the other 3 octets, it makes a maximum of 35 or >> 131 octets. >> >> I guess the draft should elaborate the composition of this information >> element and clarify that it includes the 3 initial octets. > > Based on the examples, and some common sense, I think you don't want to > specify the first two of the above in the SDP. AFAIK the first has a > well defined value, and the second is well defined by counting the bytes > in the uuie-value. It is true that the fist octet is fixed and the second is the length, so they do not really convey useful information. But we do really need the third octet (the protocol discriminator). Based on this, I would prefer to include the whole object (User-user information element) rather than the object minus two octets. > >>> Its unclear what you intend to be included in the specified uuie element >>> in the sdp - does it include the protocol discriminator or not? >> >> Yes, as I described above. >> >>> >>> Also, the content and protocol discriminator contain octets, not just >>> alphanumerics, but the syntax in 5.6 only permits alphanumerics. Is it >>> your *intent* to limit the protocol discriminator and the value to that >>> subset described by alphanumerics? And is that a reasonable thing to do? >>> (For this use, it *might* be sufficient to prescribe a specific value >>> for the protocol discriminator.) >> >> This is an error that we should fix. It is not the intention of this >> draft to limit the protocol discriminator, so, we need to address this >> issue and allow any possible value. We will fix it in the next version >> of the draft. >> >> >> >>> >>> 5.5.1 / 5.5.4 >>> >>> The description of a=connection here is more appropriate to section >>> 5.5.4. Here, for the initial offer, a=connection:new is the only thing >>> that makes sense. >> >> Ok, we can move the a=connection:existing to 5.5.4. >> >>> >>> In 5.5.4 it would be helpful to explain in more detail how a=connection >>> is used to control whether an existing call is retained, dropped, or >>> dropped and reestablished. >> > >>> >>> (In some cases it will be desired to do another o/a while leaving the >>> pstn call undisturbed. In other cases it may the explicit intent to >>> cause the call to be reestablished.) >> >> ok, will do. >> >> >>> >>> 5.6 >>> >>> Is there a reason why you don't use the definition of an E.164 number >>> from RFC 3966, rather than using your own? >> >> RFC 3966 defines how to represent an E.164 number as a URL. Here, we do >> not intent to use URLs. Additionally, the tel: URL provide >> representation of either global and local numbers, ISDN subaddresses, >> extensions, and phone context, which are not intended to be used here. > > I meant not the entire tel syntax, but by reference to one of the ABNF > symbols defined in 3966. That has the benefit of being more accessible > to those reading ietf drafts, and to give the syntax in ABNF that can be > readily incorporated with the rest of the syntax. > > Of course that would allowing visual-separator. I don't know if that is > a big deal or not. Actually, this field should only contain digits. > >> > What is the significance of >>> making the "+" optional? >> >> The only reason I can think, is that the draft has a "SHOULD" strength >> for using the international format of E.164. If someone really knows >> what he is doing and can use a national format, it wouldn't use the "+" >> sign. I recognize that this is not a very strong reason, but it is the >> only justification I can find. > > Well, if the intent is to allow a national format, then it should be > made clear that lack of the "+" means that. (And then how on how one is > supposed to know *which* national format.) > > I realize there is text that says the actual callerid received may not > be in E.164 format and so the comparison should take that into account. > But I didn't think that applied to the number specified in SDP. That is correct. That does not apply to the number included in SDP, but to the received Caller-ID in Q.931. Some operators of some countries send this number in international format; others send it in national format. Unless someone has a very good reason, I guess we can preclude national numbers from SDP, so we should remove the '+' sign from the syntax. > >> > And why is caller-id-value defined differently >>> than e164-address? >> >> Yes, I think they should be equal. Probably we should get rid of >> "caller-id-value" and use "e164-address" instead. >> >> >> >>> Figure 4, and others: >>> >>> The E.164 number used (+15551234) isn't a valid one for country code 1. >> >> Is it because there are not enough number of digits for the subscriber >> number? > > Right. Its just a nit. There is no area code in it. > >>> General Comment: >>> >>> Everything is described, and examples show, only a single m= line, and >>> all the cs-correlation and setup things used within that one media >>> section. There is no explanation of what to do if there is more than one >>> pstn m= line, as might arise if the intent is to have an audio/video >>> call. Without any explanation, it would seem that everything should be >>> specified separately for each m= line, which might result in *two* pstn >>> calls. Presumably that isn't want is desired. >>> >>> More definition is needed if the same pstn call is to be used for two >>> media streams. >> >> Yes, I agree with you. I think we should add a section describing how to >> setup an circuit-switched audio/video call. >> >>> >>> Thanks, >>> Paul >> >> Thanks for your comments, >> >> Miguel >> /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Wed Oct 19 02:38:25 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 8DD9921F8B6E for ; Wed, 19 Oct 2011 02:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVNGFdY3IuQE for ; Wed, 19 Oct 2011 02:38:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D7DD621F8B5B for ; Wed, 19 Oct 2011 02:38:24 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-67-4e9e9a8f5c2a Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CF.45.20773.F8A9E9E4; Wed, 19 Oct 2011 11:38:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 19 Oct 2011 11:38:23 +0200 From: Christer Holmberg To: IETF - MMUSIC Date: Wed, 19 Oct 2011 11:38:22 +0200 Thread-Topic: Draft new name: draft-holmberg-mmusic-sdp-bundle-negotiation (previously known as draft-holmberg-mmusic-sdp-multiplex-negotiation) Thread-Index: AcyOQtgBe5btYoLfQ1a4aVK3Zkwg8w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F489A@ESESSCMS0356.eemea.ericsson.se> 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_7F2072F1E0DE894DA4B517B93C6A058522341F489AESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Draft new name: draft-holmberg-mmusic-sdp-bundle-negotiation (previously known as draft-holmberg-mmusic-sdp-multiplex-negotiation) 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, 19 Oct 2011 09:38:25 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A058522341F489AESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new draft: draft-holmberg-mmusic-sdp-bundle-negotiation-00 It replaces draft-holmberg-mmusic-sdp-multiplex-negotiation, and the name o= f the group extension is now 'BUNDLE' (instead of 'MULTIPLEX'), based on of= f-line comments that the 'multiplexing' terminology caused some confusion. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A058522341F489AESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I've submitted a new draft:
 
draft-holmberg-mmusic-sdp-bundle-negotiation-00
 
It replaces draft-holmberg-mmusic-sdp-multiplex-negot= iation, and the name of the group extension is now 'BUNDLE' (instead of 'MU= LTIPLEX'), based on off-line comments that the 'multiplexing' terminology c= aused some confusion.
 
Regards,
 
Christer
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A058522341F489AESESSCMS0356e_-- From harald@alvestrand.no Wed Oct 19 02:59:28 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 7FD5E21F8A7B for ; Wed, 19 Oct 2011 02:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.564 X-Spam-Level: X-Spam-Status: No, score=-110.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4o+BoRWA4k5 for ; Wed, 19 Oct 2011 02:59:28 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AB30F21F89BA for ; Wed, 19 Oct 2011 02:59:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E34C639E163 for ; Wed, 19 Oct 2011 11:59:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkGjZ0kwic8B for ; Wed, 19 Oct 2011 11:59:25 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5330639E162 for ; Wed, 19 Oct 2011 11:59:25 +0200 (CEST) Message-ID: <4E9E9F7D.3080505@alvestrand.no> Date: Wed, 19 Oct 2011 11:59:25 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: mmusic@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A058522341F489A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F489A@ESESSCMS0356.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="------------060804090507030206070505" Subject: Re: [MMUSIC] Draft new name: draft-holmberg-mmusic-sdp-bundle-negotiation (previously known as draft-holmberg-mmusic-sdp-multiplex-negotiation) 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, 19 Oct 2011 09:59:28 -0000 This is a multi-part message in MIME format. --------------060804090507030206070505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/19/11 11:38, Christer Holmberg wrote: > Hi, > I've submitted a new draft: > draft-holmberg-mmusic-sdp-bundle-negotiation-00 > It replaces draft-holmberg-mmusic-sdp-multiplex-negotiation, and the > name of the group extension is now 'BUNDLE' (instead of 'MULTIPLEX'), > based on off-line comments that the 'multiplexing' terminology caused > some confusion. And since the discussion seemed to indicate that Christer's way of writing drafts harmonizes better with mmusic than my way of writing drafts ..... I'm happy to cede the pen to Christer, and support his efforts in getting this draft improved and (eventually) adopted and published. Expect no more updates to draft-alvestrand-one-rtp. Harald > Regards, > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------060804090507030206070505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/19/11 11:38, Christer Holmberg wrote:
 
Hi,
 
I've submitted a new draft:
 
draft-holmberg-mmusic-sdp-bundle-negotiation-00
 
It replaces draft-holmberg-mmusic-sdp-multiplex-negotiation, and the name of the group extension is now 'BUNDLE' (instead of 'MULTIPLEX'), based on off-line comments that the 'multiplexing' terminology caused some confusion.

And since the discussion seemed to indicate that Christer's way of writing drafts harmonizes better with mmusic than my way of writing drafts ..... I'm happy to cede the pen to Christer, and support his efforts in getting this draft improved and (eventually) adopted and published.

Expect no more updates to draft-alvestrand-one-rtp.

                Harald

 
Regards,
 
Christer
 
 
 

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

--------------060804090507030206070505-- From tasveren@sonusnet.com Wed Oct 19 13:51:30 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 6E21211E80A5 for ; Wed, 19 Oct 2011 13:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIhU2tG8BIYQ for ; Wed, 19 Oct 2011 13:51:26 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id CB3F411E8096 for ; Wed, 19 Oct 2011 13:51:25 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9JKptEl029537; Wed, 19 Oct 2011 16:51:55 -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: Wed, 19 Oct 2011 16:51:18 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703DBF79B@sonusmail04.sonusnet.com> In-Reply-To: <4E9CDD35.6020304@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 Thread-Index: AcyNOWnXe9xWC4UHTPCXcziGRvUxvABZv74w References: <4E8C6114.4000402@ericsson.com><03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com><4E9047F7.9000204@cisco.com><0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> From: "Asveren, Tolga" To: "Flemming Andreasen" , "Hadriel Kaplan" Cc: mmusic , draft-ietf-mmusic-media-loopback@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 19 Oct 2011 20:51:30 -0000 I would like to echo concerns voiced by Hadriel (in the linked e-mail below) and particularly that loopback call should look as much similar to regular calls as possible. Forcing deployments, which do not use ICE for regular calls to use ICE for loopback calls, does not sound like a good idea to me.=20 Thanks, Tolga > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Flemming Andreasen > Sent: Monday, October 17, 2011 9:58 PM > To: Hadriel Kaplan > Cc: mmusic; > Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 >=20 >=20 >=20 > On 10/12/11 10:59 AM, Hadriel Kaplan wrote: > > On Oct 8, 2011, at 8:54 AM, Flemming Andreasen wrote: > > > > > >> The issue was discussed on the mailing list in August, where the > authors suggested it as a path forward and the chairs asked the WG for > feedback on this approach, see e.g. > >> > >> http://www.ietf.org/mail-archive/web/mmusic/current/msg08857.html > >> > >> The issue was also discussed in the last IETF MMUSIC meeting (see > http://www.ietf.org/proceedings/81/minutes/mmusic.txt) > >> > >> To date, we have only seen opposition to this proposal from you (on > both the mailing list and in the meeting), and we are lacking an > alternative path forward that can satisfy all involved parties, including > the general AD and WG chair concerns around definining an alternative NAT > traversal mechanism in this draft without proper discussion and general > considerations around the need for an alternative to ICE (per the above > thread). > >> > > In the email thread you referenced above there was in fact someone else > who was for keeping the priming mechanism, and it wasn't me. > > > > In fact, in that whole thread there was only one other person than > yourself who was in favor of only having ICE in the draft. Of course > there was only one other person than myself who was in favor of keeping > the primer mechanism. > > > > My point is that there has been no consensus either way. The authors > only changed the draft due to your objections, afaict, not due to some > large consensus to do so. > > >=20 > To be clear, the author(s), myself, and our responsible AD did send a > note to the list suggesting this as a path forward. I asked the WG > members to speak up if they disagreed with the suggested path forward, > and you are the only person to argue against subsequently. While I'll > agree there is not unanimous agreement in the group with the direction, > I think we need to hear from more than 1 person to declare a lack of > (rough) concensus. Having said that, it would be better if we could > reach an agreement that is satisfactory to all. >=20 >=20 > >> If you do not find this path forward acceptable, can you please suggest > an alternative that satisfies the general concerns around defining an > alternative NAT traversal mechanism in this draft ? > >> > > There have been no "general concerns" as far as I can tell, other than > "we have ICE defined so why not use it". > Yes - we have a Standards Track and general solution available, so we > should use it. >=20 > > My concerns with mandating *only* ICE as opposed to having a SHOULD > use ICE but MAY use primer are detailed here: > > http://www.ietf.org/mail-archive/web/mmusic/current/msg08611.html > > > > There was no feedback/response to that, afaict. > > > You are referencing a ~6 month old e-mail, and there has since then been > several more e-mail exchanges on this subject, an explanation of the > issues with the old approach, and a thread plus WG meeting discussion on > the need for an ICE alternative (like latching), which didn't garner any > takers so far. If you believe those arguments still stand and offer a > viable path forward, then please resurrect them (either in the context > of this e-mail thread or as a new thread), and we (and hopefully other > members of the WG) can discuss further. Again, to recap the concerns > with the old approach: > - We have a general and Standards Track NAT traversal solution in the > form of ICE so we should use it > - If there is a need for an ICE alternative, then we need to discuss > that more generally and come up with a proper solution > - If latching is indeed needed as an alternative solution to ICE, then > it needs to be properly documented and the limitations of it spelled out > clearly. Furthermore, the loopback draft does not seem like the right > place for this. >=20 > Thanks >=20 > -- Flemming >=20 >=20 > > -hadriel > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Thu Oct 20 09:39: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 C7CEC21F8CC3 for ; Thu, 20 Oct 2011 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=1.251, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42fTlYtAUK53 for ; Thu, 20 Oct 2011 09:39:36 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id F03E621F8C9D for ; Thu, 20 Oct 2011 09:39:35 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id n4Rg1h0021ZXKqc594fc9W; Thu, 20 Oct 2011 16:39:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id n4fb1h01c0tdiYw3h4fbmx; Thu, 20 Oct 2011 16:39:36 +0000 Message-ID: <4EA04EC6.2090204@alum.mit.edu> Date: Thu, 20 Oct 2011 12:39:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <20111013121902.4228.66523.idtracker@ietfa.amsl.com> <4E98838A.7040206@alum.mit.edu> <4E9AAEEF.70001@ericsson.com> <4E9CABD2.9020200@alum.mit.edu> <4E9DDB92.5020504@ericsson.com> In-Reply-To: <4E9DDB92.5020504@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.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, 20 Oct 2011 16:39:36 -0000 On 10/18/11 4:03 PM, Miguel A. Garcia wrote: trimming out the settled stuff >>>> 5.2.3.3 >>>> >>>> You specify that the UUIE has a max size of 35 or 131 octets. AFAIK the >>>> actual max information content is actually either 32 or 128 octets plus >>>> a leading protocol discriminator byte. >>> >>> Right. The terminology in Q.931 helps to mislead. The User-User >>> Information Element contains three parts: >>> >>> - 1-octet User-user information element identifier >>> - 1-octet "Length of user-user contents" >>> - 1-octet "Protocol discriminator" >>> - "User Information". >>> >>> The "User Information can be up to 32 or 128 octets, depending on >>> networks. Together with the other 3 octets, it makes a maximum of 35 or >>> 131 octets. >>> >>> I guess the draft should elaborate the composition of this information >>> element and clarify that it includes the 3 initial octets. >> >> Based on the examples, and some common sense, I think you don't want to >> specify the first two of the above in the SDP. AFAIK the first has a >> well defined value, and the second is well defined by counting the bytes >> in the uuie-value. > > It is true that the fist octet is fixed and the second is the length, so > they do not really convey useful information. But we do really need the > third octet (the protocol discriminator). Based on this, I would prefer > to include the whole object (User-user information element) rather than > the object minus two octets. Really??? I find that just an invitation to confusion and error. Also, you should take a look at what is being done in the CUSS wg - draft-ietf-cuss-sip-uui-02. For this purpose you have some latitude in what you allow. It isn't really necessary to allow all data bytes, all lengths, or all protocol discriminators. You only need to allow enough to work in all networks and to provide sufficient randomness. The cuss work wants to provide access to the complete mechanism, and even beyond that when not going over a PSTN link. So you might choose different approach. But its at least worth a look. (Personally, I haven't been happy with CUSS including the protocol discriminator in the string with the data, but I haven't convinced anyone else of that.) >>>> 5.6 >>>> >>>> Is there a reason why you don't use the definition of an E.164 number >>>> from RFC 3966, rather than using your own? >>> >>> RFC 3966 defines how to represent an E.164 number as a URL. Here, we do >>> not intent to use URLs. Additionally, the tel: URL provide >>> representation of either global and local numbers, ISDN subaddresses, >>> extensions, and phone context, which are not intended to be used here. >> >> I meant not the entire tel syntax, but by reference to one of the ABNF >> symbols defined in 3966. That has the benefit of being more accessible >> to those reading ietf drafts, and to give the syntax in ABNF that can be >> readily incorporated with the rest of the syntax. >> >> Of course that would allowing visual-separator. I don't know if that is >> a big deal or not. > > Actually, this field should only contain digits. My point in calling out 3966 is that it is more familiar to the sip community. But this isn't a big deal as long as the reference is specific. >>> > What is the significance of >>>> making the "+" optional? >>> >>> The only reason I can think, is that the draft has a "SHOULD" strength >>> for using the international format of E.164. If someone really knows >>> what he is doing and can use a national format, it wouldn't use the "+" >>> sign. I recognize that this is not a very strong reason, but it is the >>> only justification I can find. >> >> Well, if the intent is to allow a national format, then it should be >> made clear that lack of the "+" means that. (And then how on how one is >> supposed to know *which* national format.) >> >> I realize there is text that says the actual callerid received may not >> be in E.164 format and so the comparison should take that into account. >> But I didn't think that applied to the number specified in SDP. > > That is correct. That does not apply to the number included in SDP, but > to the received Caller-ID in Q.931. Some operators of some countries > send this number in international format; others send it in national > format. > > Unless someone has a very good reason, I guess we can preclude national > numbers from SDP, so we should remove the '+' sign from the syntax. Or always include it. I guess if its always there it is redundant, but having it there would still remind people of what it is. Thanks, Paul From yuepeiyu@huawei.com Thu Oct 20 18:36: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 2F7DA1F0C47 for ; Thu, 20 Oct 2011 18:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.146 X-Spam-Level: X-Spam-Status: No, score=-96.146 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_35=0.339, EXTRA_MPART_TYPE=1, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urYGQv5FFa0N for ; Thu, 20 Oct 2011 18:36:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id EB34B1F0C3C for ; Thu, 20 Oct 2011 18:36:52 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE006NO75DII@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 21 Oct 2011 09:36:49 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00FB275DLG@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 21 Oct 2011 09:36:49 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI62120; Fri, 21 Oct 2011 09:36:49 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 09:36:37 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.160]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 09:36:41 +0800 Date: Fri, 21 Oct 2011 01:36:41 +0000 From: "Roy Yue(PeiYu)" X-Originating-IP: [10.138.73.89] To: "mmusic@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_b0PxCUh/1QnEXfk1npzgug)"; type="multipart/alternative" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Draft submittion: draft-yue-mmusic-rtsp-substream-control-extension-00 Thread-index: AcyPkec/rKpwj61BSuSFejA4wx7VQA== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [MMUSIC] Draft submittion: draft-yue-mmusic-rtsp-substream-control-extension-00 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, 21 Oct 2011 01:36:54 -0000 --Boundary_(ID_b0PxCUh/1QnEXfk1npzgug) Content-type: multipart/alternative; boundary="Boundary_(ID_wkVimHtmqedT3NcSO1jBrg)" --Boundary_(ID_wkVimHtmqedT3NcSO1jBrg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGVsbG8gYWxsLA0KDQpJIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgYXMgYmVsbG93 Og0KRmlsZW5hbWU6ICAgICAgICAgZHJhZnQteXVlLW1tdXNpYy1ydHNwLXN1YnN0cmVhbS1jb250 cm9sLWV4dGVuc2lvbg0KUmV2aXNpb246ICAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAgICAg IFJUU1AgRXh0ZW5zaW9uIGZvciBTdWJzdHJlYW0gQ29udHJvbA0KQ3JlYXRpb24gZGF0ZTogICAg ICAgIDIwMTEtMTAtMjENCldHIElEOiAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KTnVtYmVyIG9mIHBhZ2VzOiAxMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVm aW5lcyBleHRlbnNpb25zIHRvIFJUU1AgMi4wIHByb3RvY29sLCBpbmNsdWRpbmcNCiAgIGhlYWRl ciChsFN1YnN0cmVhbaGxOywgZmVhdHVyZSB0YWcgobBQbGF5LnN1YnN0cmVhbaGxOyAsIGFuZCBy ZWxhdGVkIG5ldw0KICAgc3RhdHVzIGNvZGVzLiAgVGhlc2UgZXh0ZW5zaW9ucyBlbmFibGVzIHRo ZSBwbGF5YmFjayBjb250cm9sIG9mIGENCiAgIG1lZGlhIHN0cmVhbSBvbiBzdWJzdHJlYW0gYmFz aXMuDQoNCllvdSBjYW4gcmVmZXIgaXQgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC15dWUtbW11c2ljLXJ0c3Atc3Vic3RyZWFtLWNvbnRyb2wtZXh0ZW5zaW9uLw0KDQpZ b3VyIGNvbW1lbnRzL3N1Z2dlc3Rpb25zIGFyZSB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQhIQ0KDQpC UiwNClBlaXl1IFlVRShSb3kpDQpIdWF3ZWkgU29mdHdhcmUgVGVjaG5vbG9naWVzIENvLiwgTHRk IFtodWF3ZWlfbG9nb10NCg0KTjUsIE5PLiAxMDEsIEh1YXdlaSBCYXNlDQpSdWFuamlhbiBBdiwg WXVIdWEgRGlzdA0KTmFuamluZywgMjEwMDEyLCBQLlIuQw0KVGVsOiArODYtMjUtNTY2MjIwNTgN CkZheDogKzg2LTI1LTU2NjI0MDgxDQpNb2JpbGU6ICs4Ni0xMzgwOTAzMDQwMQ0KRW1haWw6IHl1 ZXBlaXl1QGh1YXdlaS5jb20NCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0Ksb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvNuPjJ z8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3KudPD o6iw/MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQq1 xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Ki yb6z/bG+08q8/qOhDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29u ZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25s eSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUu IEFueSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkg KGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9z dXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhh biB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2 ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9u ZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0K --Boundary_(ID_wkVimHtmqedT3NcSO1jBrg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hello all,

 

I have just submitted a new dra= ft as bellow:

Filename:     &nb= sp;   draft-yue-mmusic-rtsp-substream-control-extension
Revision:         00
Title:             &= nbsp; RTSP Extension for Substream Control
Creation date:        2011-10-21
WG ID:             &= nbsp; Individual Submission
Number of pages: 11

Abstract:
   This document defines extensions to RTSP 2.0 protocol, includi= ng
   header =A1=B0Substream=A1=B1;, feature tag =A1=B0Play.substream=A1=B1; , and related new
   status codes.  These extensions enables the playback cont= rol of a
   media stream on substream basis.

 

You can refer it at http://datatracker.ietf.org/doc/draft-yue-mmusic-rtsp-substream-control-ext= ension/

 

Your comments/suggestions are v= ery much appreciated!!

 

BR,

Peiyu YUE(Roy)
Huawei Software Technologies Co., Ltd 3D"huawei_logo"


N5, NO. 101, Huawei Base
Ruanjian Av, YuHua Dist
Nanjing, 210012, P.R.C
Tel: +86-25-56622058
Fax: +86-25-56624081
Mobile: +86-13809030401
Email: yuepeiyu@huawei.com
http://www.huawei.com
---------------------------------------------------------------------------= ----------------------------------------------------------
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE= =AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2= =CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB= =F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!<= /o:p>

--Boundary_(ID_wkVimHtmqedT3NcSO1jBrg)-- --Boundary_(ID_b0PxCUh/1QnEXfk1npzgug) Content-id: Content-type: image/jpeg; name=image001.jpg Content-transfer-encoding: base64 Content-disposition: inline; filename=image001.jpg; size=6737; creation-date="Fri, 21 Oct 2011 01:36:40 GMT"; modification-date="Fri, 21 Oct 2011 01:36:40 GMT" Content-description: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_b0PxCUh/1QnEXfk1npzgug)-- From Bert.Greevenbosch@huawei.com Thu Oct 20 19:20:15 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 4B9FD1F0C4F for ; Thu, 20 Oct 2011 19:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8mMX47+dVlI for ; Thu, 20 Oct 2011 19:20:14 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 568321F0C3B for ; Thu, 20 Oct 2011 19:20:13 -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 <0LTE00NIJ95J40@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 21 Oct 2011 10:20:08 +0800 (CST) Received: from szxrg02-dlp.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 <0LTE00BOR95JU0@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 21 Oct 2011 10:20:07 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI64787; Fri, 21 Oct 2011 10:20:06 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 10:19:59 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.46]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 10:19:56 +0800 Date: Fri, 21 Oct 2011 02:19:54 +0000 From: Bert Greevenbosch X-Originating-IP: [10.70.109.97] To: "capelastegui@dit.upm.es" Message-id: <46A1DF3F04371240B504290A071B4DB60BF75AAC@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_92JUmIYkuohpbtkmTrUQew)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: Comments on draft-greevenbosch-mmusic-signal-3d-format-01 Thread-index: AcyKijb4TtB/B1/kTfyPYAoYdFul1gC7CiGgADJdn5AAVd2OEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: IETF - MMUSIC Subject: Re: [MMUSIC] Comments on draft-greevenbosch-mmusic-signal-3d-format-01 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, 21 Oct 2011 02:20:15 -0000 --Boundary_(ID_92JUmIYkuohpbtkmTrUQew) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGkgUGVkcm8sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgdGhvcm91Z2ggcmV2aWV3 IG9mIHRoZSBkcmFmdHMuICBQbGVhc2UgZmluZCBteSByZXNwb25zZXMgaW5saW5lLg0KDQpCZXN0 IHJlZ2FyZHMsDQpCZXJ0DQoNCg0KRnJvbTogUGVkcm8gQ2FwZWxhc3RlZ3VpIFttYWlsdG86Y2Fw ZWxhc3RlZ3VpQGRpdC51cG0uZXNdDQpTZW50OiAxNSBPY3RvYmVyIDIwMTEgMDA6MTgNClRvOiAn SUVURiAtIE1NVVNJQyc7IEJlcnQgR3JlZXZlbmJvc2NoDQpTdWJqZWN0OiBDb21tZW50cyBvbiBk cmFmdC1ncmVldmVuYm9zY2gtbW11c2ljLXNpZ25hbC0zZC1mb3JtYXQtMDENCg0KDQpIaSwNCg0K DQoNCkkgaGF2ZSByZXZpZXdlZCBkcmFmdC1ncmVldmVuYm9zY2gtbW11c2ljLXNpZ25hbC0zZC1m b3JtYXQtMDEsIGFuZCBJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50cy4NCg0KDQoNCiAgICAg ICAgICAgICAgICAtIEJhY2t3YXJkcyBjb21wYXRpYmlsaXR5DQoNCg0KDQpXaGVuIGEgM0QtZW5h YmxlZCBkZXZpY2UgdXNpbmcgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbGxzIGEgbGVnYWN5IGRldmlj ZSwgaXQgaXMgdmVyeSBsaWtlbHkgdGhhdCB0aGUgYW5zd2VyZXIgd2lsbCBhY2NlcHQgdGhlIHNl c3Npb24gYW5kIGVuZCB1cCByZWNlaXZpbmcgbWVkaWEgdGhhdCBpdCBjYW7igJl0IGRpc3BsYXkg cHJvcGVybHksIHN1Y2ggYXMgZnJhbWUtcGFja2VkIHZpZGVvIG9yIGEgZGVwdGggbWFwLiBJIHRo aW5rIHRoZSBkZWZhdWx0IGJlaGF2aW91ciBoZXJlIHNob3VsZCBiZSB0aGF0IHdoZW5ldmVyIHRo ZSBTRFAgYW5zd2VyIG9taXRzIHRoZSAzZEZvcm1hdCBhdHRyaWJ1dGUsIHRoZSBvZmZlcmVyIG9u bHkgc2VuZHMgMkQgdmlkZW8gKGlmIGF2YWlsYWJsZSksIGF2b2lkaW5nIGZ1cnRoZXIgb2ZmZXJz IGlmIHBvc3NpYmxlLiBUaGlzIHNwZWVkcyB1cCBzZXNzaW9uIHNldHVwIHdpdGggbGVnYWN5IGFn ZW50cywgYW5kIHByZXZlbnRzIHRyYW5zbWl0dGluZyB1c2VsZXNzIG1lZGlhLg0KDQoNCg0KVG8g aW1wbGVtZW50IHRoaXMgY2hhbmdlLCBJIHdvdWxkIG1vZGlmeSBhIGZldyBwYXJhZ3JhcGhzIGlu IHNlY3Rpb24gOC4NCg0KDQoNCkluIDguMSAoRnJhbWUgUGFja2luZyksIHJlcGxhY2U6DQoNCg0K DQrigJx0aGUgb2ZmZXJlciBNQVkgdXBkYXRlIHRoZSBvZmZlciB3aXRoIGEgMkQgc3RyZWFtLiAg SWYgdGhlIG9mZmVyZXIgaXMgdGhlIHN0cmVhbWluZyBzZXJ2ZXIsIGl0ICBNQVkgY2hvb3NlIHRv IHN0cmVhbSB0aGUgZnJhbWUgcGFja2VkIHZpZGVvIGFzIGl0IGlzLuKAnA0KDQoNCg0Kd2l0aA0K DQoNCg0K4oCcdGhlIG9mZmVyZXIgU0hPVUxEIHRyZWF0IHRoYXQgbWVkaWEgc3RyZWFtIGFzIGEg MkQgc3RyZWFtLuKAnQ0KDQoNCg0KW0JHXSBUaGUgb3JpZ2luYWwgdGhpbmtpbmcgd2FzLCB0aGF0 IHdoZW4gdGhlIGxlZ2FjeSBhbnN3ZXJlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBTRFAgYXR0cmli dXRlLCBidXQgZG9lcyBzdXBwb3J0IDNEICh3aGljaCB0aGUgdXNlciBjYW4gc3dpdGNoIG9uIG1h bnVhbGx5KSwgdGhlbiBpdCBjb3VsZCBtYWtlIHNlbnNlIHNlbmRpbmcgdGhlIDNEIHN0cmVhbSBh bnl3YXkuIEkgYW0gZmluZSB3aXRoIHlvdXIgY2hhbmdlLCBwbHVzIGFuIGluZm9ybWF0aXZlIG5v dGUgcG9pbnRpbmcgYXQgdGhlIHBvc3NpYmlsaXR5IGZvciBtYW51YWwgc3dpdGNoaW5nLg0KDQoN Cg0KSW4gOC4yICgyRCBhbmQgYXV4aWxpYXJ5IGFzIGEgc2luZ2xlIHN0cmVhbSksIHJlcGxhY2U6 DQoNCg0KDQrigJwgdGhlIG9mZmVyZXIgTUFZIHVwZGF0ZSBpdHMgb2ZmZXIgYnkgb2ZmZXJpbmcg b25seSBhIDJEICB2aWRlbyBzdHJlYW0u4oCdDQoNCg0KDQp3aXRoDQoNCg0KDQrigJxTSE9VTEQg dHJlYXQgdGhhdCBtZWRpYSBzdHJlYW0gYXMgYSAyRCBzdHJlYW0u4oCdDQoNCg0KDQoNCg0KDQoN CkluIDguMyAoMkQgYW5kIGF1eGlsaWFyeSBhcyB0d28gc2VwYXJhdGUgc3RyZWFtcyksIHJlcGxh Y2U6DQoNCg0KDQoiIElmIHRoZSBhbnN3ZXJlciBzZWxlY3RzIG9ubHkgdGhlIGF1eGlsaWFyeSB2 aWRlbywgdGhlIG9mZmVyZXIgIFNIT1VMRCB1cGRhdGUgaXRzIG9mZmVyIHdpdGhvdXQgdGhlIGF1 eGlsaWFyeSB2aWRlby4iDQoNCg0KDQp3aXRoDQoNCg0KDQoiSWYgdGhlIGFuc3dlcmVyIHNlbGVj dHMgb25seSB0aGUgYXV4aWxpYXJ5IHZpZGVvLCB0aGUgb2ZmZXJlciAgTUFZIHRyZWF0IHRoYXQg c3RyZWFtIGFzIGEgMkQgdmlkZW8gc3RyZWFtLiBJZiBpdCBkb2VzIG5vdCwgdGhlIG9mZmVyZXIg U0hPVUxEIHVwZGF0ZSBpdHMgb2ZmZXIgd2l0aG91dCB0aGUgYXV4aWxpYXJ5IHZpZGVvLiINCg0K 4oCDDQoNCltCR10gQXMgbG9uZyBhcyB0aGUgYXV4aWxpYXJ5IHZpZGVvIHVzZXMgdGhlIHNhbWUg Y29kZWMgYXMgdGhlIDJEIHZpZGVvIChsaWtlbHkpIHRoaXMgaXMgT0suIFNvICJNQVkiIHN1aXRz IGluIHRoZSBuZXcgdGV4dC4gSSdsbCBhZG9wdCBpdC4NCg0KDQoNCg0KDQogICAgICAgICAgICAg ICAgLSBILjI2NC9NVkMNCg0KDQoNCkkgdGhpbmsgdGhhdCBjb21wYXRpYmlsaXR5IHdpdGggdGhl IE1WQyBmb3JtYXQgaXMgYSBtdXN0IGZvciB0aGlzIHNwZWNpZmljYXRpb24uIFRoaXMgd2lsbCBw cm9iYWJseSByZXF1aXJlIGRlZmluaW5nIG5ldyB0eXBlcyBvZiAzRCBmb3JtYXRzIGFuZCBjb21w b25lbnRzLiBVbmZvcnR1bmF0ZWx5LCB0aGUgcGF5bG9hZCBmb3JtYXQgZm9yIE1WQyAoZHJhZnQt aWV0Zi1wYXlsb2FkLXJ0cC1tdmMtMCkgaXMgc3RpbGwgdW5maW5pc2hlZCwgd2l0aCBtb3N0IG9m IHRoZSBTRFAgc2VjdGlvbiBtaXNzaW5n4oCmDQoNCg0KDQpbQkddIFRoZSBkcmFmdCBjdXJyZW50 bHkgZG9lcyBub3QgY29uc2lkZXIgTVZDLCBidXQgaXMgbW9yZSBmb2N1c3NlZCBvbiBnZW5lcmFs IGNvZGVjcy4gRm9yIGV4YW1wbGUsIFRhQiBvciBTYlMgZnJhbWUgcGFja2luZyBjYW4gYmUgdXNl ZCBieSBhbnkgMkQgdmlkZW8gY29kZWMgdG8gY29udmV5IDNELiBIb3dldmVyLCBjZXJ0YWluIG1v ZGVzLCBlLmcuIGZyYW1lIHNlcXVlbnRpYWwgZnJhbWUgcGFja2luZyBhbmQgMkQrZGVwdGggcmVx dWlyZSBzcGVjaWZpYyBjb2RlY3MsIHN1Y2ggYXMgQVZDICsgZnJhbWUgcGFja2luZyBhcnJhbmdl bWVudCBTRUkgb3IgMjMwMDItMy4NCg0KDQoNCiAgICAgICAgICAgICAgICAtIERlcHRoIE1hcHMg aW4gYXV4aWxpYXJ5IHN0cmVhbXMuDQoNCg0KDQpTb21lIHRyYW5zbWlzc2lvbiBvcHRpb25zIHVz ZSBhIHNpbmdsZSBzdHJlYW0gY29udGFpbmluZyBvbmUgdmlldyAoY2VudHJlIG9yIGxlZnQpIGFu ZCBpdHMgYXNzb2NpYXRlZCBkZXB0aCBtYXAgKG9yIHBhcmFsbGF4IG1hcCkuIEhvd2V2ZXIsIHRo ZXJlIGlzIG5vIG1lbnRpb24gYXMgdG8gaG93IHRoZSB2aWV3IGFuZCBtYXAgYXJlIHBhY2tlZCBp biB0aGF0IHN0cmVhbS4gSSBzdXBwb3NlIHRoZSBzcGVjaWZpY2F0aW9uIGFzc3VtZXMgdGhlIHVz ZSBvZiB0aGUgYXV4aWxpYXJ5IGRhdGEgZm9ybWF0IGRlZmluZWQgaW4gTVBFRy1DIHBhcnQgMywg YnV0IHRoaXMgc2hvdWxkIHByb2JhYmx5IGJlIGluZGljYXRlZCBleHBsaWNpdGx5Lg0KDQoNCg0K QWxzbywgcGVyaGFwcyB0aGUg4oCcMkRB4oCdIGZvcm1hdCBzaG91bGQgbGVhdmUgdGhlIGRvb3Ig b3BlbiB0byBhbHRlcm5hdGUgcGFja2luZyBtZWNoYW5pc21zIG90aGVyIHRoYW4gTVBFRy1DIHBh cnQgMy4gSSBkb27igJl0IGtub3cgb2YgYW55IGN1cnJlbnRseSBleGlzdGluZyBhbHRlcm5hdGl2 ZXMsIGJ1dCBpdCBpcyBub3QgdW5yZWFzb25hYmxlIHRvIGV4cGVjdCB0aGVtIGF0IHNvbWUgcG9p bnQgaW4gdGhlIGZ1dHVyZS4NCg0KDQoNCltCR10gWWVzLCB0aGUgZHJhZnQgZm9jdXNlcyBvbiAy MzAwMi0zIGZvciBkZXB0aCBtYXBzIGFuZCB0aGVpciBzaWduYWxsaW5nLiBIb3cgdG8gY29tYmlu ZSB0aGUgMkQgYW5kIGF1eGlsaWFyeSBzdHJlYW1zIGluIGEgc2luZ2xlIHN0cmVhbSBpcyBvdXQt b2Ytc2NvcGUgb2YgMjMwMDItMywgYW5kIGFsc28gbGVmdCBvdXQtb2Ytc2NvcGUgb2YgdGhpcyBk cmFmdC4gSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBrZWVwIHRoZSBkb29yIG9wZW4gZm9yIG90aGVy IHBhY2tpbmcgbWVjaGFuaXNtcy4NCg0KDQoNCiAgICAgICAgICAgICAgICAtIFBhcmFsbGF4IE1h cHMNCg0KDQoNClRoZSBkcmFmdCBwcm92aWRlcyBubyByZWZlcmVuY2UgZm9yIHRoZSB1c2Ugb2Yg cGFyYWxsYXggbWFwcywgc28gaXTigJlzIHByb2JhYmx5IHdvcnRoIG1lbnRpb25pbmcgdGhhdCB0 aGV5IGFyZSBkZWZpbmVkLCBsaWtlIGRlcHRoIG1hcHMsIGluIFtJU08vSUVDIDIzMDAyLTNdLiBB bHNvLCBJIGhhdmUgbm90IGZvdW5kIGFueSBleGFtcGxlcyBvZiAzRCB2aWRlbyBhcHBsaWNhdGlv bnMgYmFzZWQgb24gcGFyYWxsYXggbWFwcyBpbiB0aGUgbGl0ZXJhdHVyZS4gIEhvdyBsaWtlbHkg aXMgaXQgdGhhdCB0aGlzIHNjZW5hcmlvIHdpbGwgc2VlIGFjdHVhbCB1c2U/DQoNCg0KDQpbQkdd IEkgY2FuIGFkZCB0aGUgcmVmZXJlbmNlIHRvIHRoZSBkcmFmdC4gSSBhZ3JlZSB0aGF0IGRlcHRo IG1hcHMgYXJlIG1vcmUgY29tbW9uIHRoYW4gcGFyYWxsYXggbWFwcy4NCg0KDQoNCiAgICAgICAg ICAgICAgICAtIEZyYW1lIFNlcXVlbnRpYWwgcGFja2luZw0KDQoNCg0KSSB0aGluayB0aGF0IHRo ZSBtZWNoYW5pc20gZm9yIGlkZW50aWZ5aW5nIEwtIGFuZCBSLSBzdHJlYW1zIGluIGEgZnJhbWUg c2VxdWVudGlhbCBzdHJlYW0gc2hvdWxkIGJlIGNsZWFybHkgZXhwbGFpbmVkLg0KDQoNCg0KW0JH XSBGb3IgQVZDIGZyYW1lIHBhY2tpbmcsIHRoaXMgY2FuIGJlIGRvbmUgaW4gdGhlIGZyYW1lIHBh Y2tpbmcgYXJyYW5nZW1lbnQgU0VJIG1lc3NhZ2VzLiBJIGNhbiBhZGQgc29tZSBleHBsYW5hdG9y eSB0ZXh0IGZvciB0aGlzLiBJdCB3aWxsIGJlIGhhcmQgdG8gd3JpdGUgc29tZXRoaW5nIGdlbmVy YWwgZm9yIGFsbCBjb2RlY3MsIGFzIHRoZSBzaWduYWxsaW5nIG9mIHdoaWNoIGZyYW1lcyBhcmUg TCBhbmQgd2hpY2ggYXJlIFIgc2hvdWxkIGJlIHNlbnQgc3luY2hyb25vdXMgd2l0aCB0aGUgdmlk ZW8gc3RyZWFtLg0KDQoNCg0KICAgICAgICAgICAgICAgIC0gTXVsdGlwbGUgM0Qgc3RyZWFtcw0K DQoNCg0KT24gcGFnZSAxNCwgaXQgc2F5cyB0aGF0IOKAnFRoZSBhbnN3ZXJlciBTSE9VTEQgc2Vs ZWN0IG9ubHkgb25lIDNEIGZvcm1hdOKAnS4gVGhpcyBtZWFucyB0aGF0LCBmb3IgYW55IGdpdmVu IHNlc3Npb24sIG9ubHkgb25lIDNEIHZpZGVvIHN0cmVhbSBjYW4gYmUgdXNlZC4gSSB0aGluayB0 aGlzIGlzIHRvbyBsaW1pdGluZywgc2luY2UgaXQgcHJldmVudHMgZGVzY3JpYmluZyBzZXNzaW9u cyB3aGVyZSBvbmUgYWdlbnQgaGFzIG11bHRpcGxlIDNEIGRpc3BsYXlzLCBhbW9uZyBvdGhlcnMu DQoNCg0KDQpbQkddIEkgYW0gZmluZSB3aXRoIHJlbW92aW5nIHRoaXMgbm9ybWF0aXZlIHN0YXRl bWVudCBmcm9tIHRoZSBkcmFmdC4NCg0KDQoNCiAgICAgICAgICAgICAgICAtIE11bHRpcGxlIERl cHRoIE1hcHMuDQoNCg0KDQpUaGUgZG9jdW1lbnQgYXNzdW1lcyB0aGF0IGRlcHRoIG1hcHMgd2ls bCBvbmx5IGJlIHVzZWQgaW4gMkQrZGVwdGggc3RyZWFtcy4gSG93ZXZlciwgSSB0aGluayB0aGF0 IHRoZSBjb21iaW5hdGlvbiBvZiBtdWx0aXBsZSB2aWV3cyBhbmQgZGVwdGggbWFwcyAoZS5nLiBM L1Igdmlld3MgYW5kIDIgZGVwdGggbWFwcykgaXMgYW4gaW50ZXJlc3Rpbmcgc2NlbmFyaW8gdGhh dCBtYXkgZGVzZXJ2ZSBjb25zaWRlcmF0aW9uLg0KDQoNCg0KW0JHXSBEbyB5b3UgaGF2ZSBhbnkg ZXhpc3RpbmcgZm9ybWF0IGluIG1pbmQ/IE9yIGRvIHlvdSB3YW50IHRvIGtlZXAgb3BlbiB0aGUg cG9zc2liaWxpdHkgdG8gc2lnbmFsIHRoaXMga2luZCBvZiBzY2VuYXJpbyBsYXRlcj8NCg0KDQoN ClJlZ2FyZHMsDQoNClBlZHJvDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpQ ZWRybyBDYXBlbGFzdGVndWkNCg0KUmVzZWFyY2hlcg0KDQpVbml2ZXJzaWRhZCBQb2xpdMOpY25p Y2EgZGUgTWFkcmlkDQo= --Boundary_(ID_92JUmIYkuohpbtkmTrUQew) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5UZXh0b3Np bmZvcm1hdG9DYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRvIHNpbiBmb3JtYXRvIENhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0byBzaW4gZm9ybWF0 byI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLlRleHRvc2luZm9y bWF0bywgbGkuVGV4dG9zaW5mb3JtYXRvLCBkaXYuVGV4dG9zaW5mb3JtYXRvDQoJe21zby1zdHls ZS1uYW1lOiJUZXh0byBzaW4gZm9ybWF0byI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRvIHNpbiBm b3JtYXRvIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDMuMGNtIDcwLjg1cHQgMy4wY207fQ0KZGl2 LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFBlZHJvLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHRob3JvdWdoIHJldmlldyBvZiB0aGUg ZHJhZnRzLiAmbmJzcDtQbGVhc2UgZmluZCBteSByZXNwb25zZXMgaW5saW5lLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CZXJ0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KJnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBlZHJvIENhcGVsYXN0ZWd1aSBbbWFpbHRvOmNh cGVsYXN0ZWd1aUBkaXQudXBtLmVzXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE1IE9jdG9iZXIgMjAx MSAwMDoxODxicj4NCjxiPlRvOjwvYj4gJ0lFVEYgLSBNTVVTSUMnOyBCZXJ0IEdyZWV2ZW5ib3Nj aDxicj4NCjxiPlN1YmplY3Q6PC9iPiBDb21tZW50cyBvbiBkcmFmdC1ncmVldmVuYm9zY2gtbW11 c2ljLXNpZ25hbC0zZC1mb3JtYXQtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBoYXZl IHJldmlld2VkIGRyYWZ0LWdyZWV2ZW5ib3NjaC1tbXVzaWMtc2lnbmFsLTNkLWZvcm1hdC0wMSwg YW5kIEkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSA8dT5CYWNrd2FyZHMg Y29tcGF0aWJpbGl0eTwvdT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2hlbiBhIDNE LWVuYWJsZWQgZGV2aWNlIHVzaW5nIHRoaXMgc3BlY2lmaWNhdGlvbiBjYWxscyBhIGxlZ2FjeSBk ZXZpY2UsIGl0IGlzIHZlcnkgbGlrZWx5IHRoYXQgdGhlIGFuc3dlcmVyIHdpbGwgYWNjZXB0IHRo ZSBzZXNzaW9uIGFuZCBlbmQgdXAgcmVjZWl2aW5nIG1lZGlhIHRoYXQgaXQgY2Fu4oCZdCBkaXNw bGF5IHByb3Blcmx5LCBzdWNoIGFzIGZyYW1lLXBhY2tlZCB2aWRlbyBvciBhIGRlcHRoIG1hcC4N CiBJIHRoaW5rIHRoZSBkZWZhdWx0IGJlaGF2aW91ciBoZXJlIHNob3VsZCBiZSB0aGF0IHdoZW5l dmVyIHRoZSBTRFAgYW5zd2VyIG9taXRzIHRoZSAzZEZvcm1hdCBhdHRyaWJ1dGUsIHRoZSBvZmZl cmVyIG9ubHkgc2VuZHMgMkQgdmlkZW8gKGlmIGF2YWlsYWJsZSksIGF2b2lkaW5nIGZ1cnRoZXIg b2ZmZXJzIGlmIHBvc3NpYmxlLiBUaGlzIHNwZWVkcyB1cCBzZXNzaW9uIHNldHVwIHdpdGggbGVn YWN5IGFnZW50cywgYW5kIHByZXZlbnRzIHRyYW5zbWl0dGluZw0KIHVzZWxlc3MgbWVkaWEuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRvIGltcGxlbWVudCB0aGlzIGNoYW5nZSwgSSB3 b3VsZCBtb2RpZnkgYSBmZXcgcGFyYWdyYXBocyBpbiBzZWN0aW9uIDguPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkluIDguMSAoRnJhbWUgUGFja2luZyksIHJlcGxhY2U6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPuKAnDxpPnRoZSBvZmZlcmVyIE1BWSB1cGRhdGUgdGhlIG9m ZmVyIHdpdGggYSAyRCBzdHJlYW0uJm5ic3A7IElmIHRoZSBvZmZlcmVyIGlzIHRoZSBzdHJlYW1p bmcgc2VydmVyLCBpdCZuYnNwOyBNQVkgY2hvb3NlIHRvIHN0cmVhbSB0aGUgZnJhbWUgcGFja2Vk IHZpZGVvIGFzIGl0IGlzPC9pPi7igJw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+d2l0 aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij7igJw8aT50aGUgb2ZmZXJlciBTSE9VTEQg dHJlYXQgdGhhdCBtZWRpYSBzdHJlYW0gYXMgYSAyRCBzdHJlYW0uPC9pPuKAnTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bQkddIFRoZSBvcmlnaW5hbCB0aGlua2luZyB3YXMs IHRoYXQgd2hlbiB0aGUgbGVnYWN5IGFuc3dlcmVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIFNEUCBh dHRyaWJ1dGUsIGJ1dCBkb2VzIHN1cHBvcnQgM0QgKHdoaWNoIHRoZSB1c2VyIGNhbiBzd2l0Y2gg b24gbWFudWFsbHkpLCB0aGVuIGl0IGNvdWxkIG1ha2Ugc2Vuc2Ugc2VuZGluZyB0aGUgM0Qgc3Ry ZWFtDQogYW55d2F5LiBJIGFtIGZpbmUgd2l0aCB5b3VyIGNoYW5nZSwgcGx1cyBhbiBpbmZvcm1h dGl2ZSBub3RlIHBvaW50aW5nIGF0IHRoZSBwb3NzaWJpbGl0eSBmb3IgbWFudWFsIHN3aXRjaGlu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SW4gOC4yICgyRCBhbmQgYXV4aWxpYXJ5IGFzIGEgc2luZ2xlIHN0 cmVhbSksIHJlcGxhY2U6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij7igJwgPGk+dGhlIG9mZmVyZXIgTUFZIHVwZGF0ZSBpdHMgb2ZmZXIg Ynkgb2ZmZXJpbmcgb25seSBhIDJEJm5ic3A7IHZpZGVvIHN0cmVhbS48L2k+4oCdPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPndpdGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPuKAnDxpPlNIT1VMRCB0cmVhdCB0aGF0IG1lZGlh IHN0cmVhbSBhcyBhIDJEIHN0cmVhbS48L2k+4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbiA4LjMgKDJEIGFuZCBhdXhpbGlhcnkg YXMgdHdvIHNlcGFyYXRlIHN0cmVhbXMpLCByZXBsYWNlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7IDxpPklmIHRoZSBhbnN3 ZXJlciBzZWxlY3RzIG9ubHkgdGhlIGF1eGlsaWFyeSB2aWRlbywgdGhlIG9mZmVyZXImbmJzcDsg U0hPVUxEIHVwZGF0ZSBpdHMgb2ZmZXIgd2l0aG91dCB0aGUgYXV4aWxpYXJ5IHZpZGVvPC9pPi4m cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+d2l0aDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7PGk+SWYgdGhl IGFuc3dlcmVyIHNlbGVjdHMgb25seSB0aGUgYXV4aWxpYXJ5IHZpZGVvLCB0aGUgb2ZmZXJlciZu YnNwOyBNQVkgdHJlYXQgdGhhdCBzdHJlYW0gYXMgYSAyRCB2aWRlbyBzdHJlYW0uIElmIGl0IGRv ZXMgbm90LCB0aGUgb2ZmZXJlciBTSE9VTEQgdXBkYXRlIGl0cyBvZmZlciB3aXRob3V0IHRoZSBh dXhpbGlhcnkgdmlkZW8uPC9pPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+4oCDPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCR10gQXMgbG9uZyBh cyB0aGUgYXV4aWxpYXJ5IHZpZGVvIHVzZXMgdGhlIHNhbWUgY29kZWMgYXMgdGhlIDJEIHZpZGVv IChsaWtlbHkpIHRoaXMgaXMgT0suIFNvICZxdW90O01BWSZxdW90OyBzdWl0cyBpbiB0aGUgbmV3 IHRleHQuIEknbGwgYWRvcHQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSA8dT5ILjI2NC9NVkM8L3U+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgdGhpbmsgdGhhdCBjb21wYXRpYmlsaXR5 IHdpdGggdGhlIE1WQyBmb3JtYXQgaXMgYSBtdXN0IGZvciB0aGlzIHNwZWNpZmljYXRpb24uIFRo aXMgd2lsbCBwcm9iYWJseSByZXF1aXJlIGRlZmluaW5nIG5ldyB0eXBlcyBvZiAzRCBmb3JtYXRz IGFuZCBjb21wb25lbnRzLiBVbmZvcnR1bmF0ZWx5LCB0aGUgcGF5bG9hZCBmb3JtYXQgZm9yIE1W QyAoZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1tdmMtMCkgaXMNCiBzdGlsbCB1bmZpbmlzaGVkLCB3 aXRoIG1vc3Qgb2YgdGhlIFNEUCBzZWN0aW9uIG1pc3NpbmfigKY8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+W0JHXSBUaGUgZHJhZnQgY3VycmVudGx5IGRvZXMgbm90IGNvbnNp ZGVyIE1WQywgYnV0IGlzIG1vcmUgZm9jdXNzZWQgb24gZ2VuZXJhbCBjb2RlY3MuIEZvciBleGFt cGxlLCBUYUIgb3IgU2JTIGZyYW1lIHBhY2tpbmcgY2FuIGJlIHVzZWQgYnkgYW55IDJEIHZpZGVv IGNvZGVjIHRvIGNvbnZleSAzRC4gSG93ZXZlciwgY2VydGFpbiBtb2RlcywgZS5nLiBmcmFtZQ0K IHNlcXVlbnRpYWwgZnJhbWUgcGFja2luZyBhbmQgMkQmIzQzO2RlcHRoIHJlcXVpcmUgc3BlY2lm aWMgY29kZWNzLCBzdWNoIGFzIEFWQyAmIzQzOyBmcmFtZSBwYWNraW5nIGFycmFuZ2VtZW50IFNF SSBvciAyMzAwMi0zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gPHU+RGVwdGggTWFwcyBpbiBhdXhpbGlhcnkg c3RyZWFtcy48L3U+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNvbWUgdHJhbnNtaXNz aW9uIG9wdGlvbnMgdXNlIGEgc2luZ2xlIHN0cmVhbSBjb250YWluaW5nIG9uZSB2aWV3IChjZW50 cmUgb3IgbGVmdCkgYW5kIGl0cyBhc3NvY2lhdGVkIGRlcHRoIG1hcCAob3IgcGFyYWxsYXggbWFw KS4gSG93ZXZlciwgdGhlcmUgaXMgbm8gbWVudGlvbiBhcyB0byBob3cgdGhlIHZpZXcgYW5kIG1h cCBhcmUgcGFja2VkIGluIHRoYXQgc3RyZWFtLiBJIHN1cHBvc2UgdGhlIHNwZWNpZmljYXRpb24N CiBhc3N1bWVzIHRoZSB1c2Ugb2YgdGhlIGF1eGlsaWFyeSBkYXRhIGZvcm1hdCBkZWZpbmVkIGlu IE1QRUctQyBwYXJ0IDMsIGJ1dCB0aGlzIHNob3VsZCBwcm9iYWJseSBiZSBpbmRpY2F0ZWQgZXhw bGljaXRseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWxzbywgcGVyaGFwcyB0aGUg 4oCcMkRB4oCdIGZvcm1hdCBzaG91bGQgbGVhdmUgdGhlIGRvb3Igb3BlbiB0byBhbHRlcm5hdGUg cGFja2luZyBtZWNoYW5pc21zIG90aGVyIHRoYW4gTVBFRy1DIHBhcnQgMy4gSSBkb27igJl0IGtu b3cgb2YgYW55IGN1cnJlbnRseSBleGlzdGluZyBhbHRlcm5hdGl2ZXMsIGJ1dCBpdCBpcyBub3Qg dW5yZWFzb25hYmxlIHRvIGV4cGVjdCB0aGVtIGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVyZS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0JHXSBZZXMsIHRoZSBkcmFmdCBm b2N1c2VzIG9uIDIzMDAyLTMgZm9yIGRlcHRoIG1hcHMgYW5kIHRoZWlyIHNpZ25hbGxpbmcuIEhv dyB0byBjb21iaW5lIHRoZSAyRCBhbmQgYXV4aWxpYXJ5IHN0cmVhbXMgaW4gYSBzaW5nbGUgc3Ry ZWFtIGlzIG91dC1vZi1zY29wZSBvZiAyMzAwMi0zLCBhbmQgYWxzbyBsZWZ0IG91dC1vZi1zY29w ZSBvZiB0aGlzIGRyYWZ0Lg0KIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQga2VlcCB0aGUgZG9vciBv cGVuIGZvciBvdGhlciBwYWNraW5nIG1lY2hhbmlzbXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gPHU+UGFyYWxsYXggTWFwczwvdT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VGhlIGRyYWZ0IHByb3ZpZGVzIG5vIHJlZmVyZW5jZSBmb3IgdGhlIHVz ZSBvZiBwYXJhbGxheCBtYXBzLCBzbyBpdOKAmXMgcHJvYmFibHkgd29ydGggbWVudGlvbmluZyB0 aGF0IHRoZXkgYXJlIGRlZmluZWQsIGxpa2UgZGVwdGggbWFwcywgaW4gW0lTTy9JRUMgMjMwMDIt M10uIEFsc28sIEkgaGF2ZSBub3QgZm91bmQgYW55IGV4YW1wbGVzIG9mIDNEIHZpZGVvIGFwcGxp Y2F0aW9ucyBiYXNlZCBvbiBwYXJhbGxheA0KIG1hcHMgaW4gdGhlIGxpdGVyYXR1cmUuJm5ic3A7 IEhvdyBsaWtlbHkgaXMgaXQgdGhhdCB0aGlzIHNjZW5hcmlvIHdpbGwgc2VlIGFjdHVhbCB1c2U/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5bQkddIEkgY2FuIGFkZCB0aGUgcmVmZXJlbmNlIHRvIHRoZSBkcmFmdC4gSSBhZ3JlZSB0aGF0 IGRlcHRoIG1hcHMgYXJlIG1vcmUgY29tbW9uIHRoYW4gcGFyYWxsYXggbWFwcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gPHU+RnJhbWUgU2VxdWVu dGlhbCBwYWNraW5nPC91PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIHRoaW5rIHRo YXQgdGhlIG1lY2hhbmlzbSBmb3IgaWRlbnRpZnlpbmcgTC0gYW5kIFItIHN0cmVhbXMgaW4gYSBm cmFtZSBzZXF1ZW50aWFsIHN0cmVhbSBzaG91bGQgYmUgY2xlYXJseSBleHBsYWluZWQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCR10gRm9yIEFWQyBmcmFtZSBwYWNraW5n LCB0aGlzIGNhbiBiZSBkb25lIGluIHRoZSBmcmFtZSBwYWNraW5nIGFycmFuZ2VtZW50IFNFSSBt ZXNzYWdlcy4gSSBjYW4gYWRkIHNvbWUgZXhwbGFuYXRvcnkgdGV4dCBmb3IgdGhpcy4gSXQgd2ls bCBiZSBoYXJkIHRvIHdyaXRlIHNvbWV0aGluZyBnZW5lcmFsIGZvciBhbGwgY29kZWNzLCBhcyB0 aGUgc2lnbmFsbGluZw0KIG9mIHdoaWNoIGZyYW1lcyBhcmUgTCBhbmQgd2hpY2ggYXJlIFIgc2hv dWxkIGJlIHNlbnQgc3luY2hyb25vdXMgd2l0aCB0aGUgdmlkZW8gc3RyZWFtLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0gPHU+TXVsdGlwbGUgM0Qgc3RyZWFtczwvdT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+T24gcGFnZSAxNCwgaXQgc2F5cyB0aGF0IOKAnFRoZSBhbnN3ZXJlciBTSE9VTEQgc2Vs ZWN0IG9ubHkgb25lIDNEIGZvcm1hdOKAnS4gVGhpcyBtZWFucyB0aGF0LCBmb3IgYW55IGdpdmVu IHNlc3Npb24sIG9ubHkgb25lIDNEIHZpZGVvIHN0cmVhbSBjYW4gYmUgdXNlZC4gSSB0aGluayB0 aGlzIGlzIHRvbyBsaW1pdGluZywgc2luY2UgaXQgcHJldmVudHMgZGVzY3JpYmluZyBzZXNzaW9u cyB3aGVyZSBvbmUgYWdlbnQNCiBoYXMgbXVsdGlwbGUgM0QgZGlzcGxheXMsIGFtb25nIG90aGVy cy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCR10gSSBhbSBmaW5lIHdp dGggcmVtb3ZpbmcgdGhpcyBub3JtYXRpdmUgc3RhdGVtZW50IGZyb20gdGhlIGRyYWZ0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0gPHU+TXVsdGlwbGUgRGVwdGggTWFwcy48L3U+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoZSBkb2N1bWVudCBhc3N1bWVzIHRoYXQgZGVwdGggbWFwcyB3aWxsIG9u bHkgYmUgdXNlZCBpbiAyRCYjNDM7ZGVwdGggc3RyZWFtcy4gSG93ZXZlciwgSSB0aGluayB0aGF0 IHRoZSBjb21iaW5hdGlvbiBvZiBtdWx0aXBsZSB2aWV3cyBhbmQgZGVwdGggbWFwcyAoZS5nLiBM L1Igdmlld3MgYW5kIDIgZGVwdGggbWFwcykgaXMgYW4gaW50ZXJlc3Rpbmcgc2NlbmFyaW8gdGhh dCBtYXkgZGVzZXJ2ZSBjb25zaWRlcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0JHXSBEbyB5b3UgaGF2ZSBhbnkgZXhpc3Rp bmcgZm9ybWF0IGluIG1pbmQ/IE9yIGRvIHlvdSB3YW50IHRvIGtlZXAgb3BlbiB0aGUgcG9zc2li aWxpdHkgdG8gc2lnbmFsIHRoaXMga2luZCBvZiBzY2VuYXJpbyBsYXRlcj88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBlZHJv PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlBlZHJvIENhcGVsYXN0ZWd1aTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+UmVzZWFyY2hlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+VW5pdmVyc2lkYWQgUG9saXTDqWNuaWNhIGRlIE1hZHJpZDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --Boundary_(ID_92JUmIYkuohpbtkmTrUQew)-- From miguel.a.garcia@ericsson.com Fri Oct 21 00:14:41 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 07C461F0C60 for ; Fri, 21 Oct 2011 00:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzuDpgahMhI9 for ; Fri, 21 Oct 2011 00:14:40 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DD9481F0C59 for ; Fri, 21 Oct 2011 00:14:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-e1-4ea11bdeae4c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D7.F1.13753.EDB11AE4; Fri, 21 Oct 2011 09:14:38 +0200 (CEST) Received: from [159.107.24.141] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Fri, 21 Oct 2011 09:14:38 +0200 Message-ID: <4EA11BDD.3010607@ericsson.com> Date: Fri, 21 Oct 2011 09:14:37 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 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 82 Taipei 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, 21 Oct 2011 07:14:41 -0000 Hi, If you want a timeslot for discussing a draft in Taipei, please ping the chairs (unless you have already done so). I want to draw your attention to the fact that we are scheduled for Friday 9 AM, but for a two-hour time, and not 2.5-hours as we used to have. It seems that the schedule of the Friday morning at IETF meetings have changed the sessions time schemes. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From magnus.westerlund@ericsson.com Fri Oct 21 02:25:29 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 95FFF21F8BA9; Fri, 21 Oct 2011 02:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I914Xa1iKTvS; Fri, 21 Oct 2011 02:25:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 52B2221F8B85; Fri, 21 Oct 2011 02:25:27 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-09-4ea13a86a7e2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.2D.13753.68A31AE4; Fri, 21 Oct 2011 11:25:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 21 Oct 2011 11:25:25 +0200 Message-ID: <4EA13A85.2060506@ericsson.com> Date: Fri, 21 Oct 2011 11:25:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mmusic (E-mail)" , "payload@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16 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, 21 Oct 2011 09:25:29 -0000 Hi, I have reviewed An "Extension to the Session Description Protocol (SDP) for Media Loopback" whos WG last call ended yesterday. I hope this comments will be addressed as I think there are some serious short commings and also process steps that must be done. 1. This document contains media types. But it has not been reviewed by the ietf-types@iana.org mailing list. This must be completed prior to publication request. 2. I do CC the payload WG mailing list as this document really should be reviewed there. I know the chairs have realized that need. 3. I think the authors and chairs should discuss how to handle the fact that there is 6 authors on the front page. It is possible to ask for exception on this, but might be simpler to move one of the authors to a contributor section. 4. Title: I think the title is indicating that this is only an SDP solution, but it clearly contains the considerations needed for the RTP/RTCP part also. I think it should reflect that it is a solution for RTP transported media loopback including SDP signalling. 5. Abstract: "maintaining voice/real-time Text/video quality, reliability, and overall performance." The "voice/real-time" construction appears to indicate that voice isn't real-time. I guess something like: maintaining real-time voice/Text/video quality, reliability, and overall performance. would be easier and clearer. 6. Section 3. No reference to SDP offer answer. And the "Offering entity" is called agent in SDP O/A terminology. 7. Section 3: "it MAY do so as defined in section 5.4.1 of this specification." Considering what is written in 5.4.1 I think that section can be moved to section 3. 8. Section 4: An answering entity that is not compliant to this specification and which receives an offer with the "loopback" media attributes MAY ignore the attribute and treat the incoming offer as a normal request. I would suggest reformulate this. I expect this text to say what is expected to happen when the answering agent doesn't know what this attribute is. Which is ignore the attribute, attempt to establish the session without loopback and send back the answer without the attribute. I would suggest to clarify that the offering agent should consider terminating the establishment at this point as loopback was not available, unless it might actual "ring" if this is an end-point at a user. 9. What about declarative SDP usage? 10. What is really the purpose of the sections 3 and 4. They seem to be teasers for a very small part of the issue that is covered in detail in section 5. Why not move the appropriate text in to the relevant subsections? 11. Section 5.3 " Note: A loopback offer in a given media description MUST NOT contain the standard mode attributes sendonly, recvonly, sendrecv, or inactive. The loopback-mode attributes (loopback-source and loopback-mirror) replace the standard attributes." This appears to be a strange MUST NOT which I think might encounter issues. Considering that SIP proxies that looks into this SDP requires the direction attribute to be present and adds it, what happens now. And why isn't sendrecv and inactive possible values? sendrecv appears to be requried for loopback to work, and inactive would put media transport in an established session on hold. Isn't that reasonable? 12. Section 5.3: I think one could clarify that the loopback source needs to include the encapsulation or direct loopback payload formats when suggesting pckt type loopback. 13. What happens if I offer both media and pckt loopback at the same time by including two loopback attributes? 14. Section 5.1: loopback-type = loopback-choice [1*SP loopback-choice] loopback-choice = loopback-type-pkt / loopback-type-media loopback-type-pkt = "rtp-pkt-loopback" loopback-type-media = "rtp-media-loopback" The ABNF appears broken as it doesn't define the whole attribute. I would suggest to add a line: loopback-attr = "a=loopback:" loopback-type 15. Section 5.2 is missing ABNF. I think it should make clear the attributes definition completely. 16. Section 5 Two new media attributes are defined: one indicates the type of loopback and the other indicates the mode of the loopback. I would claim that this spec defines 3 attributes. 17. Section 5.4: The loopback-mode attributes (loopbackThe port number and the address in the answer (m= line) indicate where the answerer would like to receive the media stream. Strange sentence! 18. Section 5.4: If an answerer wishes to accept the loopback request it MUST include both the loopback mode and loopback type attribute in the answer. When a stream is offered with the loopback-source attribute, the corresponding stream in the response MUST be loopback-mirror and vice versa, provided that answerer is capable of supporting the requested loopback-type. This seems to be in partial conflict with 5.4.1. As my impression of the above, is that if you don't want to accept, you don't include the attributes. But 5.4.1 says that it should be included but the port set to 0. 19. Section 5.4 I am missing clear rules for the cases when I might exclude payload types from loopback-mode attributes compared to the m= lines. Are this only the loopback payload types? What happens if I exclude a regular media payload format? 20. Section 7.1: The packet expansion of the encapsulated format I think needs better discussion. I think one needs to first recommend PMTU discovery. Secondly I think it is likely worth discussing when the loopback source should reduce the packet sizes to avoid fragmentation versus the need to measure that size in the forward link and thus causing fragmentation. 21. Section 6. "An answering entity that is compliant to this specification and accepting a media with the loopback type rtp-media-loopback MUST transmit all received media back to the sender. " I think this MUST, MUST have an exception for that the path from the mirror to the source actually can support the bit-rate required. 22. Section 6. Media loopback, if a loopback source would send more than one stream how does the loopback mirror indicate which source is which in its return stream? SDES CNAME could be copied but would be confusing for anyone monitoring this stream as SSRCs from both end-points would appear to have the same CNAME. The ssrc-grouping could possibly be used, but I think one needs to consider the effect of that the SSRCs to be grouped are not on the same end-point. I don't even know if my SRCNAME proposal could deal with this case well. 23. Section 7.1.1: Marker (M) bit: If the received RTP packet is looped back in multiple RTP packets, the M bit is set to 1 in the last packet, otherwise it is set to 0. I don't like this definition as it means that complete non fragment packets will have a m=0 the same as non last fragements. would it not be better to define it so that all packets have m=1 except non-last fragments. 24.section 7.1.1.: The RTP timestamp MUST use the same clock rate used by the loopback-source. I think this needs to be defined as the same clock rate used by the packet being encapsulated. Otherwise this becomes ambigous when the loopback source have payload types with multiple rates. 25. Section 7.1.2: Payload strucutre. I think it is unclear. Which of the following options do you really want. Outer RTP header (optional CSRC list or Header ext) Receive timestamp Inner RTP packet { - RTP header - (optional CSRC list or Header ext) - RTP payload } or Outer RTP header (optional CSRC list or Header ext) RTP Payload header { Receive timestamp Inner RTP packet header fields as specified in 7.1.2 } Inner RTP payload Note that the second doesn't echo back the extension header In general the text is not clear that the inner RTP payload should be included. 26. Section 7.1.2: You decide to overwrite the version field in the packet echoed back that is likely fine, however, why are you overwriting the P and X bits? Why not include the header extension in what is being echoed back so that mirror doesn't have to remove them in case they are present. 27. Section 7.1.2: The fragmentation procedures are unclear. I guess you want the RTP header part to be duplicated with each fragment but that isn't clearly specified. But, will you include header extensions also in the repeat if you include them? 28. Section 7.1.2: The Receive timestamp MUST be based on the same clock used by the loopback-source. This is an impossibility. The two end-points can't have the same clock. The can have a common clock reference like NTP. But, they are still not the same clocks, but possibly synchronized well enough for your needs What I guess you are after is that the clock rate should be the same as for the packet encapsulated. The Timestamp in the outer header should also be corrected. I also think you should clarify that the receive timestamp and the timestamp in the header needs to be from the same clock in the mirror. Otherwise the time spent on the mirror for the packet is not useful. I think it might also be worth actually writing up the measurements that become possible by these two timestamps plus having the source logg transmission and arrival times. The fact that one can derive both one way delay and jitter for each loopback packet is kind of important. However, to have correct one way delays the mirror clock needs to be synchronized with the source clock, or at least the current offset. 29. Section 7.1.2: "Any padding octets in the original packet MUST NOT be included in the loopback packet generated by a loopback-mirror." What is the motivation behind this? If the reason I want to do packet loopback is to find out if somebody is manipulating the packets between the source and the mirror you need to include the whole packet as it is, not throw away parts of it. What if padding is added or removed on path. That might matter for the one doing the active measurement. 30. Section 7.2.1: Sequence Number: The RTP sequence number SHOULD be generated by the loopback-mirror in the usual manner with a constant random offset. What is the acceptable cases for when to break it? I assume the intention with not saying MUST is that one can copy it from the incomming packet. Thus when source -> mirror packet losses occur causing wholes in the return path which isn't real loss on the mirror->source path. It also causes third party monitor to report losses that aren't real on this stream. 31. Section 7.2.1: Timestamp: The RTP timestamp denotes the sampling instant for when the loopback-mirror is transmitting this packet to the loopback-source. The RTP timestamp MUST be based on the same clock used by the loopback-source. The initial value of the timestamp SHOULD be random for security reasons (see Section 5.1 of RFC 3550 [RFC3550]). One more case of not correct timestamp definition. 32. Section 7.2.1: The usage of the CSRC and extension headers for this payload format should be clarified. Shall the mirror copy these fields or not? 33. Section 8: Why should a mirror do VoIP Metric Reports Block XR blocks for a video stream. I think some clarification based on media type is in order here. 34. Section 9. This section is thoroughly inadequate. The reason is that you have a forward path that is coupled to the reverse path. If the loopback is to work correctly the mirror needs to be able to send back what the source sent to it. Thus it is the loopback source that needs to adapt the media bit-rate so that both forward and reverse path can handle the flows. If doesn't the mirror will need to reduce the bit-rate it transmits and that can only happen in two ways, dropping packets or transcoding them to a lower rate fulfilling the congestion control requirement. Neither will fulfill the purpose of the loopback as I see it. This issue needs discussion, including some considerations in how to actually accomplish it with the tools we have available. 35. Section 10.1 What is the purpose of this example? What I see it establish the fact that the end-points can take respecitve roles of source and mirror. But it doesn't indicate any media which can be looped back? 36. Section 10.1 Either of the o= lines are in error. Because they can't be the same when it comes to the ID and version fields. 37. Section 11: This needs to be very much fleshed out. First of all the denial of service attack are actually several possible. One is to use a loopback mirror as a slight amplification source and primarily a indirection. This is accomplished by attacker spoofing source address to the targets and sending media to the loopback mirror. A much more hideous attack is the one where an attacker emits signalling messages that results in that two mirrors are connected to each other. As soon as a few packet are injected into that loop it will grow until the resources are consumed. Any non lost packet arriving at either mirror will be forwarded and grow 16 bytes per mirror bounce. It will bounce between the mirrors until fragmentation occurs and then you have two packets. This will continue until all CPU or bandwidth resources are consume causing packet loss. So I think you better explain how one in reality do authenticate the signalling messages so that only approved initiators of loopback are allowed. Because doing this without being certain that it is not a malicous entity setting up the sessions are plain stupid and this should not be specified if there is no solution to this issue. I also think a consideration of the media plane security should be done. Are there any privacy concerns. 38. I also don't see any discussion of the interaction between this an the high layers. For example if this is implemented in a SIP end-point is that supposed to ring? Are there any case where media will be allowed to be played out when doing loopback? I don't think so, but it should be stated. 39. Section 7.2: If one has multiple media sources in an RTP session arriving at the mirror. I expect the mirror to loopback both. However, in which way does the loopback source determine which mirror stream is related to the one being sent? 40. Section 7.2: In an RTP session where one uses more than a single payload type for the source to mirror media, how does the source determine which original payload type the payload had? Is there need for solution the Retransmission payload foramt uses RFC 4588? 41. The media type registrations "rate" parameter I think needs to be redefined. It needs to reference the rate of the payload types it intends to mirror back. Also, I don't think 8k Hz clock is typical enough for any of the media type. Audio has a number of common ones beyond 8k. video uses most commonly but not exclusively 90k. Text uses yet something else. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Mon Oct 24 10:57:30 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 B73D021F8B63; Mon, 24 Oct 2011 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM+s8Dlp3Ihm; Mon, 24 Oct 2011 10:57:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CAC21F8B53; Mon, 24 Oct 2011 10:57:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111024175730.13367.80904.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 10:57:30 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-04.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: Mon, 24 Oct 2011 17:57:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : SDP: Session Description Protocol Author(s) : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-04.txt Pages : 49 Date : 2011-10-24 This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-04.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-ietf-mmusic-rfc4566bis-04.txt From HKaplan@acmepacket.com Mon Oct 24 11:06: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 D947021F8B38 for ; Mon, 24 Oct 2011 11:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAgTKsw62hDG for ; Mon, 24 Oct 2011 11:06:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4B21F8B25 for ; Mon, 24 Oct 2011 11:06:09 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 24 Oct 2011 14:06:08 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 24 Oct 2011 14:06:09 -0400 From: Hadriel Kaplan To: Flemming Andreasen Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMknebntelnQXQtEmTBz+tE712dg== Date: Mon, 24 Oct 2011 18:06:08 +0000 Message-ID: <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> In-Reply-To: <4E9CDD35.6020304@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: mmusic , "" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 24 Oct 2011 18:06:11 -0000 On Oct 17, 2011, at 9:58 PM, Flemming Andreasen wrote: [snip] > Again, to recap the concerns with the old approach: > - We have a general and Standards Track NAT traversal solution in the for= m of ICE so we should use it And we are - the loopback draft explicitly says to do ICE if both sides can= do so. It doesn't ignore ICE. The question is if the loopback draft can = also say what to do if ICE isn't supported. (and no, saying "well then go s= upport ICE" isn't an option for the reasons explained previously in the ema= il threads) > - If there is a need for an ICE alternative, then we need to discuss that= more generally and come up with a proper solution > - If latching is indeed needed as an alternative solution to ICE, then it= needs to be properly documented and the limitations of it spelled out clea= rly. Furthermore, the loopback draft does not seem like the right place for= this. You make it sound like latching is some new thing - it's not - it's been ar= ound since long before ICE. I don't disagree it's not documented in an RFC= , though it is somewhat documented in draft-ietf-mmusic-media-path-middlebo= xes. But I'm not sure latching even needs to be documented for loopback-draft to= state something like "send packet out". Something like what Dan Wing sugg= ested here: http://www.ietf.org/mail-archive/web/mmusic/current/msg08865.html -hadriel From internet-drafts@ietf.org Mon Oct 24 23:27:31 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 4B84C21F8B81; Mon, 24 Oct 2011 23:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pruDix5-K9ao; Mon, 24 Oct 2011 23:27:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4FE21F8B67; Mon, 24 Oct 2011 23:27:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025062730.23643.99624.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 23:27:30 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-traffic-class-for-sdp-00.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: Tue, 25 Oct 2011 06:27:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : The Session Description Protocol (SDP) 'trafficclass= ' Attribute Author(s) : James Polk Subha Dhesikan Paul E. Jones Filename : draft-ietf-mmusic-traffic-class-for-sdp-00.txt Pages : 20 Date : 2011-10-24 This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp= -00.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-ietf-mmusic-traffic-class-for-sdp-= 00.txt From HKaplan@acmepacket.com Tue Oct 25 11:01:08 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 C808B21F87F0; Tue, 25 Oct 2011 11:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20fb26D2ucFE; Tue, 25 Oct 2011 11:01:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id A531621F87D3; Tue, 25 Oct 2011 11:01:07 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 Oct 2011 14:01:06 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 25 Oct 2011 14:01:06 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMk0AQgFOaHLkVnk2PMnyyKDinTw== Date: Tue, 25 Oct 2011 18:01:05 +0000 Message-ID: References: <4EA13A85.2060506@ericsson.com> In-Reply-To: <4EA13A85.2060506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <09DDE6791FA3654888911EA283C25B64@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16 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, 25 Oct 2011 18:01:08 -0000 On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > 11. Section 5.3 > " Note: A loopback offer in a given media description MUST NOT > contain the standard mode attributes sendonly, recvonly, sendrecv, > or inactive. The loopback-mode attributes (loopback-source and > loopback-mirror) replace the standard attributes." >=20 > This appears to be a strange MUST NOT which I think might encounter > issues. Considering that SIP proxies that looks into this SDP requires > the direction attribute to be present and adds it, what happens now. > And why isn't sendrecv and inactive possible values? sendrecv appears to > be requried for loopback to work, and inactive would put media transport > in an established session on hold. Isn't that reasonable? How about this: Since media loopback requires bidirectional RTP, its normal direction mode = is "sendrecv"; the "sendrecv" direction attribute MAY be encoded in SDP or = not, as per section 5.1 of [RFC3264], since it is implied by default. If e= ither the loopback source or mirror wish to disable loopback use during a s= ession, the direction attribute "inactive" MUST be used as per [RFC3264]. = The direction mode attributes "recvonly" and "sendonly" are incompatible wi= th the loopback mechanism and MUST NOT be indicated when generating an SDP = Offer or Answer. When receiving an SDP Offer or Answer, if "recvonly" or "= sendonly" is indicated for loopback, the SDP-receiving agent MAY treat it a= s a failure of the loopback negotiation or ignore the direction attribute.= =20 [This last sentence is probably controversial?] -hadriel From fandreas@cisco.com Wed Oct 26 08:23:03 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 6DFF021F8AF9 for ; Wed, 26 Oct 2011 08:23:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVizKfLdZboc for ; Wed, 26 Oct 2011 08:23:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1D03021F8A96 for ; Wed, 26 Oct 2011 08:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=9366; q=dns/txt; s=iport; t=1319642582; x=1320852182; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=u6M2wcH3a9lgrwt49vx6UVcXeWBAUxxyYynOyb9SBBc=; b=CS4D/F9ZiA/++E9LwhtMPsOB0MZ2Y/bF8rIcugEjqEhu25sILTJdpE9x UinExzZx2Ba5gscWCbrF7Tw314fUmQRWwrgkLcAUBlxklwmTlSQdpm89k q22OiIUcMBetfXbg94xzocTBI/zcu9X1We9b1xzGiqSB/YD1r7d6cfEQ6 g=; X-IronPort-AV: E=Sophos;i="4.69,409,1315180800"; d="scan'208,217";a="31139118" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 26 Oct 2011 15:23:01 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9QFMxu0030595; Wed, 26 Oct 2011 15:22:59 GMT Message-ID: <4EA825D2.6090405@cisco.com> Date: Wed, 26 Oct 2011 11:22:58 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> In-Reply-To: <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> Content-Type: multipart/alternative; boundary="------------020400040003020204030108" Cc: Dan Wing , mmusic , "" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 26 Oct 2011 15:23:03 -0000 This is a multi-part message in MIME format. --------------020400040003020204030108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/24/11 2:06 PM, Hadriel Kaplan wrote: > On Oct 17, 2011, at 9:58 PM, Flemming Andreasen wrote: > [snip] > >> Again, to recap the concerns with the old approach: >> - We have a general and Standards Track NAT traversal solution in the form of ICE so we should use it >> > And we are - the loopback draft explicitly says to do ICE if both sides can do so. It doesn't ignore ICE. The question is if the loopback draft can also say what to do if ICE isn't supported. (and no, saying "well then go support ICE" isn't an option for the reasons explained previously in the email threads) > > I'm not sure which previous part you are referring to since many different points have been made by different people. However, can we change the above to say that loopback implementations MUST still support ICE, but then add text/procedures around what to do in case ICE procedures cannot be used per the points made by Emil in http://www.ietf.org/mail-archive/web/mmusic/current/msg08788.html, or are you objecting to the "MUST support ICE" part ? > >> - If there is a need for an ICE alternative, then we need to discuss that more generally and come up with a proper solution >> - If latching is indeed needed as an alternative solution to ICE, then it needs to be properly documented and the limitations of it spelled out clearly. Furthermore, the loopback draft does not seem like the right place for this. >> > You make it sound like latching is some new thing - it's not - it's been around since long before ICE. I don't disagree it's not documented in an RFC, though it is somewhat documented in draft-ietf-mmusic-media-path-middleboxes. > We'll need more than that I think. As I've stated before, we have asked the working group on multiple occasions if there is interest in exploring alternatives to the ICE NAT traversal mechanisms (e.g. latching) and then get those discussed and documented properly. So far, we haven't seen any takers (and no, the loopback draft is not the right place to put it since it needs proper attention and discussion). > But I'm not sure latching even needs to be documented for loopback-draft to state something like "send packet out". Something like what Dan Wing suggested here: > http://www.ietf.org/mail-archive/web/mmusic/current/msg08865.html > We are going in circles here. Dan's proposed text was: "If the network is using media latching, the endpoint MUST emit a UDP packet (in order for media latching to work) towards the remote endpoint and it SHOULD send several packets to accommodate packet loss. If the network is using ICE or media latching, the endpoint SHOULD emit packets every 15 seconds to accommodate stateful middleboxes (e.g., NATs) [RFC6263]." Again, media latching needs to be discussed and documented properly if you want to reference it, and it cannot be part of the loopback draft. Example questions that come to mind here: - How does an endpoint know the "network" is using latching and hence whether to send this UDP packet or not ? - Is the remote endpoint involved in this latching operation, and if so what does it need to do ? - Under what circumstances should you use this media latching mechamism ? We need something more solid to reference to move us forward, or some alternative concrete text proposal to the above that doesn't lead to open questions, e.g. along the lines of Emil's proposal, (however I'm not sure it goes to the extent that you are looking for in terms of removing ICE dependencies, but you tell me). Thanks -- Flemming > -hadriel > > > --------------020400040003020204030108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 10/24/11 2:06 PM, Hadriel Kaplan wrote: 
On Oct 17, 2011, at 9:58 PM, Flemming Andreasen wrote:
[snip]
  
 Again, to recap the concerns with the old approach:
- We have a general and Standards Track NAT traversal solution in the form of ICE so we should use it
    
And we are - the loopback draft explicitly says to do ICE if both sides can do so.  It doesn't ignore ICE.  The question is if the loopback draft can also say what to do if ICE isn't supported. (and no, saying "well then go support ICE" isn't an option for the reasons explained previously in the email threads)
I'm not sure which previous part you are referring to since many different points have been made by different people.

However, can we change the above to say that loopback implementations MUST still support ICE, but then add text/procedures around what to do in case ICE procedures cannot be used per the points made by Emil in http://www.ietf.org/mail-archive/web/mmusic/current/msg08788.html, or are you objecting to the "MUST support ICE" part ? 

  
- If there is a need for an ICE alternative, then we need to discuss that more generally and come up with a proper solution
- If latching is indeed needed as an alternative solution to ICE, then it needs to be properly documented and the limitations of it spelled out clearly. Furthermore, the loopback draft does not seem like the right place for this.
    
You make it sound like latching is some new thing - it's not - it's been around since long before ICE.  I don't disagree it's not documented in an RFC, though it is somewhat documented in draft-ietf-mmusic-media-path-middleboxes.
We'll need more than that I think. As I've stated before, we have asked the working group on multiple occasions if there is interest in exploring alternatives to the ICE NAT traversal mechanisms (e.g. latching) and then get those discussed and documented properly. So far, we haven't seen any takers (and no, the loopback draft is not the right place to put it since it needs proper attention and discussion). 

But I'm not sure latching even needs to be documented for loopback-draft to state something like "send packet out".  Something like what Dan Wing suggested here:
http://www.ietf.org/mail-archive/web/mmusic/current/msg08865.html
We are going in circles here. Dan's proposed text was:
<quote>
  "If the network is using media latching, the endpoint MUST emit
   a UDP packet (in order for media latching to work) towards the 
   remote endpoint and it SHOULD send several packets to accommodate
   packet loss.  If the network is using ICE or media latching, the
   endpoint SHOULD emit packets every 15 seconds to accommodate
   stateful middleboxes (e.g., NATs) [RFC6263]."
</quote>

Again, media latching needs to be discussed and documented properly if you want to reference it, and it cannot be part of the loopback draft. Example questions that come to mind here:
- How does an endpoint know the "network" is using latching and hence whether to send this UDP packet or not ?
- Is the remote endpoint involved in this latching operation, and if so what does it need to do ? 
- Under what circumstances should you use this media latching mechamism ?

We need something more solid to reference to move us forward, or some alternative concrete text proposal to the above that doesn't lead to open questions, e.g. along the lines of Emil's proposal, (however I'm not sure it goes to the extent that you are looking for in terms of removing ICE dependencies, but you tell me).

Thanks

-- Flemming 


-hadriel
--------------020400040003020204030108-- From HKaplan@acmepacket.com Wed Oct 26 20:36:11 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 35ECB21F85B9 for ; Wed, 26 Oct 2011 20:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFrpKOk3tzrU for ; Wed, 26 Oct 2011 20:36:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4221F84C9 for ; Wed, 26 Oct 2011 20:36:10 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 26 Oct 2011 23:36:08 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 26 Oct 2011 23:36:09 -0400 From: Hadriel Kaplan To: Flemming Andreasen Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMlFmPMVljMp3YQlalenMYL4fQVg== Date: Thu, 27 Oct 2011 03:36:07 +0000 Message-ID: <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> In-Reply-To: <4EA825D2.6090405@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Dan Wing , mmusic , "" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 27 Oct 2011 03:36:11 -0000 Hi Flemming, Sorry about the length of this email. I think we are either talking past each other, or going in circles as you s= aid. :( It would probably be better to discuss this in person in Taipei, but here's= an attempt at a reset: 1) My goal is to be enable a SIP-domain administrator to make loopback test= -calls from a testing system (phone or server SIP UAC) to SIP clients; whet= her those SIP clients be behind NATs or not. To achieve that goal, I belie= ve we need an RFC that we can reference the SIP client vendors to implement= against. 2) To make it useful, I believe such an RFC needs to: a) Be likely to be implemented: the easier it is to implement, the likelie= r to be implemented. b) Be as close to normal calls as possible, both from a signaling and medi= a-path perspective: if regular calls use ICE, media-loopback calls need to = use ICE; if regular calls don't use ICE, media-loopback calls should not ei= ther... because we don't want a different media-path used for them or else = the purpose of media-loopback test calls is negated. c) Not require changing the deployed SIP and media-handling architecture, = whatever it may be; media-loopback is a testing tool, not new service/reven= ue, so people won't be willing to change their whole infrastructure just to= make a test call. 3) Current SIP-domain media-handling architectures differ, but we don't nee= d to go define what all of them are or could be to enable media-loopback; a= ll we have to do is point 2(b) above: keep them doing what they do for norm= al calls, except in a loopback mode. The only problem with that is that in= normal calls the SIP UA sends RTP without waiting to receive RTP, for a se= ndrecv mode call. Because of RFC 4787, we know that if the UA is behind a = NAT then not sending some packets out first means the loopback packets won'= t be let in. In order to make the loopback call appear as close to a normal= call as possible, therefore, we need to have the UA send some packets out = first. (luckily we have RFC 4787 or we'd be having an argument about having= to publish that before publishing media-loopback! ;) 4) We don't need to describe latching to specify in a media-loopback RFC th= at a SIP UA needs to mimic what is does in a normal call. Al we have to sa= y is: use ICE if you support ICE and the incoming SDP offer indicated ICE a= s per RFC 5245, or just send some primer RTP packets if what you would do i= n a normal call is send RTP without ICE. Frankly, it won't hurt anything i= f a SIP UAC *always* sends primer RTP packets in a loopback call, even if i= t also does ICE. Whether NAT traversal works by latching, or by some wires= hark script, or by reading tea leaves doesn't matter. We just need to foll= ow 2(b): act like a normal call as much as possible. 5) My original email was to indicate my belief that the change from draft-1= 5 to draft-16 is a bad one: both because it makes the situation worse not b= etter, and because I feel it was taken without real consensus in this WG. = I wouldn't care much about the lack of consensus for some editorial nit, bu= t I think this is a big deployment-impacting change for a vote of 3 vs. 2 t= o be called "rough consensus". 6) The current loopback draft-16 says this and only this with respect to ha= ndling loopback calls and NATs: Section 5.7: ICE/STUN/TURN provide a general solution to establishing media sessions between entities that are behind NATs. Loopback sessions that involve one or more end points behind NATs SHOULD use these general solutions wherever possible. That's it, in the ENTIRE document. That's approaching 'useless' on the Ric= hter scale of RFC mandates. How do you know if you're "behind NATs"? If i= t's a "SHOULD", what's the exception/alternative? What if you're not in "w= herever possible"? The previous draft version-15, on the other hand, told you what to do if no= t ICE. We can argue about whether what it said to do was good or not, but a= t least it did something.=20 -hadriel From miguel.a.garcia@ericsson.com Thu Oct 27 00:13:00 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 E615B21F84DB for ; Thu, 27 Oct 2011 00:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldC1RlPb8RWe for ; Thu, 27 Oct 2011 00:13:00 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EC71721F84CD for ; Thu, 27 Oct 2011 00:12:59 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-fe-4ea9047a7085 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F5.C1.20773.A7409AE4; Thu, 27 Oct 2011 09:12:58 +0200 (CEST) Received: from [159.107.24.222] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 27 Oct 2011 09:12:58 +0200 Message-ID: <4EA90478.4090608@ericsson.com> Date: Thu, 27 Oct 2011 09:12:56 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mmusic References: <20111026195651.11998.61241.idtracker@ietfa.amsl.com> In-Reply-To: <20111026195651.11998.61241.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111026195651.11998.61241.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] Fwd: Protocol Action: 'IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)' to Proposed Standard (draft-salgueiro-mmusic-image-iana-registration-09.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, 27 Oct 2011 07:13:01 -0000 Hi, this document was developed through the AD-sponsored track. Just for your information, IANA registration of the media type "image" in SDP has been approved now. /Miguel -------- Original Message -------- Subject: Protocol Action: 'IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)' to Proposed Standard (draft-salgueiro-mmusic-image-iana-registration-09.txt) Date: Wed, 26 Oct 2011 21:56:51 +0200 From: The IESG To: IETF-Announce CC: RFC Editor The IESG has approved the following document: - 'IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)' (draft-salgueiro-mmusic-image-iana-registration-09.txt) as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-salgueiro-mmusic-image-iana-registration/ Technical Summary This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the Session Description Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams. Working Group Summary While this is not an official document of the MMUSIC working group, the document has been reviewed in the MMUSIC WG. It is widely supported by its members and external bodies. Has received substantial review, including an unofficial WGLC. There is consensus to proceed forward with the document. Since this document is registering a missing token in an existing registry, it was decided to expedite the document in the sake of simplicity and speedness. Document Quality There are implementations and RFCs documenting the usage of the "image" media type in SDP. This document adds it to the SDP parameters registry. Personnel Miguel Angel Garcia is the document shepherd. Gonzalo Camarillo is the responsible AD. RFC Editor's Note: OLD: The 'image' media type for the Session Description Protocol is used to describes a media stream that represents a still image. The media subtype further describes the specific format of the image. Currently, the 'image' media type for SDP is used ubiquitously by the SIP control protocol to establish T.38 media streams. NEW: The 'image' media type for the Session Description Protocol is used to describe a media stream whose content consists of one or more separate images that require appropriate hardware to display. The media subtype further describes the specific format of the image. Currently, the 'image' media type for SDP is used ubiquitously by the SIP control protocol to establish T.38 media streams. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From HKaplan@acmepacket.com Thu Oct 27 01:10: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 23F6E21F87C2 for ; Thu, 27 Oct 2011 01:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6j4Ymcfa-TP for ; Thu, 27 Oct 2011 01:10:45 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 50DA221F8511 for ; Thu, 27 Oct 2011 01:10:45 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 27 Oct 2011 04:10:41 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 04:10:42 -0400 From: Hadriel Kaplan To: Flemming Andreasen Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMlH/rMVljMp3YQlalenMYL4fQVg== Date: Thu, 27 Oct 2011 08:10:40 +0000 Message-ID: <7F97F7F5-86F0-4684-B2C4-F4B9372C6E26@acmepacket.com> References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> In-Reply-To: <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <9DB1746AE495B14B8AA8E3323D78D29B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" , "mmusic \(E-mail\)" , Dan Wing Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 27 Oct 2011 08:10:46 -0000 Howdy, Before you read the insanely long email I just sent, I have a proposed solu= tion which may satisfy you, the authors, and the Working Group as a whole. = Or maybe this solution is what the loopback draft actually means and I'm j= ust dumb as a stump. As I understand it, your concern is we (1) don't have an RFC defining how N= AT traversal works if not with ICE, (2) don't want to define a "primer" thi= ngy just for this one loopback draft, and (3) are dizzy from of going aroun= d in circles. :) Well... there is an escape clause in ICE RFC 5245, section 5.1, for what to= do if there's an ICE mismatch or a received Offer doesn't indicate ICE. I= n theory an ICE-supporting UA must follow that behavior. The rationale for= this is explained in section 18, with regards to ALGs and SBCs. =20 Note that when the other side doesn't do ICE or there is an ALG, section 5.= 1 instructs the UA to do section 10. Per section 10, if the peer supports = ICE at all (even if ICE is mismatched and not being used), the local UA sen= ds STUN Binding Indications as the keepalives. If the peer doesn't support= ICE at all, then what the local UA sends is its choice. Examples the ICE = RFC gives is Comfort Noise, or draft-ietf-avt-rtp-no-op (which I believe wa= s written by someone named Flemming Andreasen :) My point in all this is to propose the following high-level straw-man: 1) We use the STUN Binding Indications as our primer packet format, by refe= rencing STUN RFC. 2) We put in text that a UA loopback-mirror MUST either support ICE, or at = least section 10 of ICE. 3) We specify that the media-loopback indication in SDP means the loopback-= source supports receiving and ignoring STUN Binding Indications, so that fo= llowing Section 10 of RFC 5245 the mirror MUST send STUN not no-op or comfo= rt noise. 4) We put some text in the loopback-source about sources MUST support ignor= ing received STUN Binding Indications, not depend on getting them, etc. 5) We fix all of Magnus' comments and publish this as an RFC before our Sun= becomes a red giant and dies out. 6) Profit? -hadriel From magnus.westerlund@ericsson.com Thu Oct 27 01:56:03 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 75ABC21F86A5; Thu, 27 Oct 2011 01:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp9r3TdYBPrw; Thu, 27 Oct 2011 01:56:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA6121F8672; Thu, 27 Oct 2011 01:55:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-c2-4ea91c9e4911 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 56.65.13753.E9C19AE4; Thu, 27 Oct 2011 10:55:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 27 Oct 2011 10:55:57 +0200 Message-ID: <4EA91C9C.7010801@ericsson.com> Date: Thu, 27 Oct 2011 10:55:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4EA13A85.2060506@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16 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, 27 Oct 2011 08:56:03 -0000 On 2011-10-25 20:01, Hadriel Kaplan wrote: > > On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > >> 11. Section 5.3 " Note: A loopback offer in a given media >> description MUST NOT contain the standard mode attributes sendonly, >> recvonly, sendrecv, or inactive. The loopback-mode attributes >> (loopback-source and loopback-mirror) replace the standard >> attributes." >> >> This appears to be a strange MUST NOT which I think might >> encounter issues. Considering that SIP proxies that looks into this >> SDP requires the direction attribute to be present and adds it, >> what happens now. And why isn't sendrecv and inactive possible >> values? sendrecv appears to be requried for loopback to work, and >> inactive would put media transport in an established session on >> hold. Isn't that reasonable? > > How about this: Since media loopback requires bidirectional RTP, its > normal direction mode is "sendrecv"; the "sendrecv" direction > attribute MAY be encoded in SDP or not, as per section 5.1 of > [RFC3264], since it is implied by default. If either the loopback > source or mirror wish to disable loopback use during a session, the > direction attribute "inactive" MUST be used as per [RFC3264]. The > direction mode attributes "recvonly" and "sendonly" are incompatible > with the loopback mechanism and MUST NOT be indicated when generating > an SDP Offer or Answer. When receiving an SDP Offer or Answer, if > "recvonly" or "sendonly" is indicated for loopback, the SDP-receiving > agent MAY treat it as a failure of the loopback negotiation or ignore > the direction attribute. > That is much better. I think the only "controversial" from my perspective is the "ignore" part. It is clearly an error. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Thu Oct 27 04:39:31 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 1EFAA21F8A6C; Thu, 27 Oct 2011 04:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYYs5e4QWpNr; Thu, 27 Oct 2011 04:39:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B077621F87C5; Thu, 27 Oct 2011 04:39:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111027113930.27632.9366.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2011 04:39:30 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-04.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, 27 Oct 2011 11:39:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : The Evaluation of Different Network Addres Translator (N= AT) Traversal Techniques for Media Controlled by Real-time Streaming Protoc= ol (RTSP) Author(s) : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-04.txt Pages : 37 Date : 2011-10-27 This document describes several Network Address Translator (NAT) traversal techniques that was considered to be used by Real-time Streaming Protocol (RTSP). Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also disussions on how NAT traversal techniques relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0 standardized in the MMUSIC WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-0= 4.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-ietf-mmusic-rtsp-nat-evaluation-04= .txt From internet-drafts@ietf.org Thu Oct 27 04:43:42 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 D048D21F8AB8; Thu, 27 Oct 2011 04:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNTwJOgIXk8H; Thu, 27 Oct 2011 04:43:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715BE21F899F; Thu, 27 Oct 2011 04:43:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111027114342.28697.72368.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2011 04:43:42 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-11.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, 27 Oct 2011 11:43:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : A Network Address Translator (NAT) Traversal mechanism f= or media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : Jeff Goldberg Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-11.txt Pages : 29 Date : 2011-10-27 This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-11.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-ietf-mmusic-rtsp-nat-11.txt From magnus.westerlund@ericsson.com Thu Oct 27 04:50:15 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 2195221F8A97 for ; Thu, 27 Oct 2011 04:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+vl1v9ArZF3 for ; Thu, 27 Oct 2011 04:50:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2686821F8663 for ; Thu, 27 Oct 2011 04:50:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-19-4ea945741d30 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FE.84.20773.47549AE4; Thu, 27 Oct 2011 13:50:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 27 Oct 2011 13:50:11 +0200 Message-ID: <4EA94572.9050804@ericsson.com> Date: Thu, 27 Oct 2011 13:50:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20111027114342.28697.72368.idtracker@ietfa.amsl.com> In-Reply-To: <20111027114342.28697.72368.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-11.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, 27 Oct 2011 11:50:15 -0000 WG, No changes only to keep the document alive. Same is true for the nat evaluation draft. Cheers Magnus On 2011-10-27 13:43, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) > Author(s) : Jeff Goldberg > Magnus Westerlund > Thomas Zeng > Filename : draft-ietf-mmusic-rtsp-nat-11.txt > Pages : 29 > Date : 2011-10-27 > > This document defines a solution for Network Address Translation > (NAT) traversal for datagram based media streams setup and controlled > with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses > Interactive Connectivity Establishment (ICE) adapted to use RTSP as a > signalling channel, defining the necessary extra RTSP extensions and > procedures. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-11.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-ietf-mmusic-rtsp-nat-11.txt > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From pkyzivat@alum.mit.edu Thu Oct 27 13:47:27 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 769ED21F8B4C for ; Thu, 27 Oct 2011 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hobeZX9My8kh for ; Thu, 27 Oct 2011 13:47:27 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id B3D1821F8B49 for ; Thu, 27 Oct 2011 13:47:26 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta07.westchester.pa.mail.comcast.net with comcast id pwjw1h0080ldTLk57wnTtc; Thu, 27 Oct 2011 20:47:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta04.westchester.pa.mail.comcast.net with comcast id pwnS1h01A0tdiYw3QwnT86; Thu, 27 Oct 2011 20:47:27 +0000 Message-ID: <4EA9C35C.3000109@alum.mit.edu> Date: Thu, 27 Oct 2011 16:47:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <4EA13A85.2060506@ericsson.com> <4EA91C9C.7010801@ericsson.com> In-Reply-To: <4EA91C9C.7010801@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16 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, 27 Oct 2011 20:47:27 -0000 On 10/27/11 4:55 AM, Magnus Westerlund wrote: > On 2011-10-25 20:01, Hadriel Kaplan wrote: >> >> On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: >> >>> 11. Section 5.3 " Note: A loopback offer in a given media >>> description MUST NOT contain the standard mode attributes sendonly, >>> recvonly, sendrecv, or inactive. The loopback-mode attributes >>> (loopback-source and loopback-mirror) replace the standard >>> attributes." >>> >>> This appears to be a strange MUST NOT which I think might >>> encounter issues. Considering that SIP proxies that looks into this >>> SDP requires the direction attribute to be present and adds it, >>> what happens now. And why isn't sendrecv and inactive possible >>> values? sendrecv appears to be requried for loopback to work, and >>> inactive would put media transport in an established session on >>> hold. Isn't that reasonable? >> >> How about this: Since media loopback requires bidirectional RTP, its >> normal direction mode is "sendrecv"; the "sendrecv" direction >> attribute MAY be encoded in SDP or not, as per section 5.1 of >> [RFC3264], since it is implied by default. If either the loopback >> source or mirror wish to disable loopback use during a session, the >> direction attribute "inactive" MUST be used as per [RFC3264]. The >> direction mode attributes "recvonly" and "sendonly" are incompatible >> with the loopback mechanism and MUST NOT be indicated when generating >> an SDP Offer or Answer. When receiving an SDP Offer or Answer, if >> "recvonly" or "sendonly" is indicated for loopback, the SDP-receiving >> agent MAY treat it as a failure of the loopback negotiation or ignore >> the direction attribute. >> > > That is much better. I think the only "controversial" from my > perspective is the "ignore" part. It is clearly an error. Yeah. Normally we don't specify the behavior in error cases. Doing a behavior is recommended that allows things to proceed in a useful way, it is in effect "allowing" the error. (Specifying *which* error to report, when there is a choice, seems reasonable.) Thanks, Paul > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From fandreas@cisco.com Thu Oct 27 18:40: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 34ACA11E8073 for ; Thu, 27 Oct 2011 18:40: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqFqPg9LZ0WL for ; Thu, 27 Oct 2011 18:40:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5F16A11E80A1 for ; Thu, 27 Oct 2011 18:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=3455; q=dns/txt; s=iport; t=1319766031; x=1320975631; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nqpAuOgwCwDUjN85lldEQehO6sk/jOtMiRjrVhp/gi8=; b=JhiApCQIdoVhlNDMUPLQOr9umD3ohWcrqJIhkwZPxCHmZbSnzC7Zj9AN YzCsc/5cscPud03t8o21TmBryNjatoNz4R7i1ysZWxsVM+ILQqhBeamFK EP0ydJxwfyTi+K1Q4mEUl79GlzN7hEoI+hXuo8akovMh97pVN9zCHc2sf w=; X-IronPort-AV: E=Sophos;i="4.69,416,1315180800"; d="scan'208";a="31570831" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 28 Oct 2011 01:40:31 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9S1eUmB019795; Fri, 28 Oct 2011 01:40:30 GMT Message-ID: <4EAA080D.8070801@cisco.com> Date: Thu, 27 Oct 2011 21:40:29 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> <7F97F7F5-86F0-4684-B2C4-F4B9372C6E26@acmepacket.com> In-Reply-To: <7F97F7F5-86F0-4684-B2C4-F4B9372C6E26@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "mmusic \(E-mail\)" , Dan Wing Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 28 Oct 2011 01:40:32 -0000 On 10/27/11 4:10 AM, Hadriel Kaplan wrote: > Howdy, > Before you read the insanely long email I just sent, I have a proposed solution which may satisfy you, the authors, and the Working Group as a whole. Or maybe this solution is what the loopback draft actually means and I'm just dumb as a stump. > I don't think either is really the case (or at least it's far from obvious :-) > As I understand it, your concern is we (1) don't have an RFC defining how NAT traversal works if not with ICE, (2) don't want to define a "primer" thingy just for this one loopback draft, and (3) are dizzy from of going around in circles. :) > > Right, and (4) If we are not happy with ICE as our IETF NAT traversal mechanism, for whatever reason, then we as WG need to be explicit about that and figure out a way of addressing it in general - not just in the form of and as part of some loopback specific discussion (or we'll have another one of these threads when the next draft comes along that needs to work behind NATs, but doesn't really want to do ICE). > Well... there is an escape clause in ICE RFC 5245, section 5.1, for what to do if there's an ICE mismatch or a received Offer doesn't indicate ICE. In theory an ICE-supporting UA must follow that behavior. The rationale for this is explained in section 18, with regards to ALGs and SBCs. > > Right - I think this was Emil's point as well (further noting that even when ICE is supported, a media latching SBC may lead to these procedures being invoked). > Note that when the other side doesn't do ICE or there is an ALG, section 5.1 instructs the UA to do section 10. Per section 10, if the peer supports ICE at all (even if ICE is mismatched and not being used), the local UA sends STUN Binding Indications as the keepalives. If the peer doesn't support ICE at all, then what the local UA sends is its choice. Examples the ICE RFC gives is Comfort Noise, or draft-ietf-avt-rtp-no-op (which I believe was written by someone named Flemming Andreasen :) > > :-) > My point in all this is to propose the following high-level straw-man: > > 1) We use the STUN Binding Indications as our primer packet format, by referencing STUN RFC. > Any reason we can't reference the ICE RFC and make it a "SHOULD" implement ? > 2) We put in text that a UA loopback-mirror MUST either support ICE, or at least section 10 of ICE. > Ok - I think we can reference ICE in 1) then (right ?) > 3) We specify that the media-loopback indication in SDP means the loopback-source supports receiving and ignoring STUN Binding Indications, so that following Section 10 of RFC 5245 the mirror MUST send STUN not no-op or comfort noise. > 4) We put some text in the loopback-source about sources MUST support ignoring received STUN Binding Indications, not depend on getting them, etc. > This seems like a way forward that would keep us consistent with current ICE procedures. We probably need to explore it in more detail (and I'd welcome more comments on this as well), but it seems promising. One question is the frequency with which these STUN Binding Requests would be sent ? > 5) We fix all of Magnus' comments and publish this as an RFC before our Sun becomes a red giant and dies out. > 6) Profit? > Let's explore the details further and get more comments on this. Thanks -- Flemming > -hadriel > > > From fandreas@cisco.com Thu Oct 27 18:42:45 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 01B4811E8096 for ; Thu, 27 Oct 2011 18:42:45 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnxOfYYS0NGZ for ; Thu, 27 Oct 2011 18:42:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1683B11E808D for ; Thu, 27 Oct 2011 18:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=4364; q=dns/txt; s=iport; t=1319766164; x=1320975764; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iQPkqLb7UeKQnzn5nfLaptyXBGMBd0Tt59QrdiQcuEY=; b=i00Gym0an3jGOJw0nGNVuOkVOnW9UrNKsROHXLNytlW9EiV2B1I396Ll KY7cNAiZ7RWv6Fh4sNB6lCNxsRndAgqTqhd92o/Veh3iedYwDcsiEQ1bg WtElp0QYS23rpdcmpv+H6LgUFqvEqoISXSPv+EzO5VxId8rnV5H9GN3an k=; X-IronPort-AV: E=Sophos;i="4.69,416,1315180800"; d="scan'208";a="31579891" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 28 Oct 2011 01:42:43 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9S1ggu2005346; Fri, 28 Oct 2011 01:42:43 GMT Message-ID: <4EAA0891.6060308@cisco.com> Date: Thu, 27 Oct 2011 21:42:41 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> In-Reply-To: <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Wing , mmusic , "" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 28 Oct 2011 01:42:45 -0000 Hi Hadriel Per your other subsequent e-mail (http://www.ietf.org/mail-archive/web/mmusic/current/msg08979.html), I'll defer on this one. If your other proposal ends up not moving forward, then please resurrect this one again. Thanks -- Flemming On 10/26/11 11:36 PM, Hadriel Kaplan wrote: > Hi Flemming, > Sorry about the length of this email. > I think we are either talking past each other, or going in circles as you said. :( > It would probably be better to discuss this in person in Taipei, but here's an attempt at a reset: > > 1) My goal is to be enable a SIP-domain administrator to make loopback test-calls from a testing system (phone or server SIP UAC) to SIP clients; whether those SIP clients be behind NATs or not. To achieve that goal, I believe we need an RFC that we can reference the SIP client vendors to implement against. > > 2) To make it useful, I believe such an RFC needs to: > a) Be likely to be implemented: the easier it is to implement, the likelier to be implemented. > b) Be as close to normal calls as possible, both from a signaling and media-path perspective: if regular calls use ICE, media-loopback calls need to use ICE; if regular calls don't use ICE, media-loopback calls should not either... because we don't want a different media-path used for them or else the purpose of media-loopback test calls is negated. > c) Not require changing the deployed SIP and media-handling architecture, whatever it may be; media-loopback is a testing tool, not new service/revenue, so people won't be willing to change their whole infrastructure just to make a test call. > > 3) Current SIP-domain media-handling architectures differ, but we don't need to go define what all of them are or could be to enable media-loopback; all we have to do is point 2(b) above: keep them doing what they do for normal calls, except in a loopback mode. The only problem with that is that in normal calls the SIP UA sends RTP without waiting to receive RTP, for a sendrecv mode call. Because of RFC 4787, we know that if the UA is behind a NAT then not sending some packets out first means the loopback packets won't be let in. In order to make the loopback call appear as close to a normal call as possible, therefore, we need to have the UA send some packets out first. (luckily we have RFC 4787 or we'd be having an argument about having to publish that before publishing media-loopback! ;) > > 4) We don't need to describe latching to specify in a media-loopback RFC that a SIP UA needs to mimic what is does in a normal call. Al we have to say is: use ICE if you support ICE and the incoming SDP offer indicated ICE as per RFC 5245, or just send some primer RTP packets if what you would do in a normal call is send RTP without ICE. Frankly, it won't hurt anything if a SIP UAC *always* sends primer RTP packets in a loopback call, even if it also does ICE. Whether NAT traversal works by latching, or by some wireshark script, or by reading tea leaves doesn't matter. We just need to follow 2(b): act like a normal call as much as possible. > > 5) My original email was to indicate my belief that the change from draft-15 to draft-16 is a bad one: both because it makes the situation worse not better, and because I feel it was taken without real consensus in this WG. I wouldn't care much about the lack of consensus for some editorial nit, but I think this is a big deployment-impacting change for a vote of 3 vs. 2 to be called "rough consensus". > > 6) The current loopback draft-16 says this and only this with respect to handling loopback calls and NATs: > Section 5.7: > ICE/STUN/TURN provide a general solution to establishing media > sessions between entities that are behind NATs. Loopback sessions > that involve one or more end points behind NATs SHOULD use these > general solutions wherever possible. > > That's it, in the ENTIRE document. That's approaching 'useless' on the Richter scale of RFC mandates. How do you know if you're "behind NATs"? If it's a "SHOULD", what's the exception/alternative? What if you're not in "wherever possible"? > The previous draft version-15, on the other hand, told you what to do if not ICE. We can argue about whether what it said to do was good or not, but at least it did something. > > -hadriel > > > From HKaplan@acmepacket.com Thu Oct 27 20:36:37 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 BFB981F0C54 for ; Thu, 27 Oct 2011 20:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibAJFp7ap60F for ; Thu, 27 Oct 2011 20:36:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F1E661F0C53 for ; Thu, 27 Oct 2011 20:36:36 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 27 Oct 2011 23:36:34 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 23:36:35 -0400 From: Hadriel Kaplan To: Flemming Andreasen Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMlSLKMVljMp3YQlalenMYL4fQVg== Date: Fri, 28 Oct 2011 03:36:34 +0000 Message-ID: <945EE41C-0068-4CBE-8797-1DF8C7F2BDC0@acmepacket.com> References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> <7F97F7F5-86F0-4684-B2C4-F4B9372C6E26@acmepacket.com> <4EAA080D.8070801@cisco.com> In-Reply-To: <4EAA080D.8070801@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <714207450047A54A899599C39679C36C@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" , "mmusic \(E-mail\)" , Dan Wing Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 28 Oct 2011 03:36:37 -0000 On Oct 27, 2011, at 9:40 PM, Flemming Andreasen wrote: >> As I understand it, your concern is we (1) don't have an RFC defining ho= w NAT traversal works if not with ICE, (2) don't want to define a "primer" = thingy just for this one loopback draft, and (3) are dizzy from of going ar= ound in circles. :) >> =20 > Right, and > (4) If we are not happy with ICE as our IETF NAT traversal mechanism, for= whatever reason, then we as WG need to be explicit about that and figure o= ut a way of addressing it in general - not just in the form of and as part = of some loopback specific discussion (or we'll have another one of these th= reads when the next draft comes along that needs to work behind NATs, but d= oesn't really want to do ICE). While I and some others have noted on multiple occasions that ICE isn't the= utopian solution it's cracked up to be, it appears so far we're still in t= he minority in the WG. I did put in text in: http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00 in Appendix A.2, of an example why ICE can't be used for some people - but = that's sort of an obscure reference because the point of the draft is about= IPv4/v6 not NATs. There're other ICE-problem examples too, like in the En= terprise market where the IT guys want to force the media to go through the= ir VPNs or stay inside and never reach the public Internet. But essentially media-loopback is the only case I've seen where there's a N= AT problem to solve that isn't auto-handled by just normal RTP behavior and= latching. The IPv4/v6 case isn't a NAT traversal problem per se, nor a la= tching one, but more of a need to indicate multiple address families in SDP= , competing with the desire by some others in the WG that a connectivity ch= eck type thing happens because IPv6 isn't stable. >> My point in all this is to propose the following high-level straw-man: >>=20 >> 1) We use the STUN Binding Indications as our primer packet format, by r= eferencing STUN RFC. >> =20 > Any reason we can't reference the ICE RFC and make it a "SHOULD" implemen= t ? How about this: "A UAC compliant with this document SHOULD implement [RFC52= 45], but MAY only implement section 10 of [RFC5245] with the additional rul= es noted in section X of this document if it does not use ICE for normal me= dia sessions." And section X would have something like this: When a UAS loopback mirror receives an SDP Offer with media-loopback, if th= e UAS implements [RFC5245] then it follows ICE procedures, including fallba= ck to just sending STUN Binding Indications per Section 10 of ICE if the re= ceived Offer did not indicate ICE or there is an ICE mismatch condition. I= f the UAS does not implement [RFC5245], then it MUST at least follow the pr= ocedures of Section 10 of [RFC5245] and send STUN Binding Indications. In = all cases, even if ICE is not actively used, the existence of the media-loo= pback indication in SDP indicates the far-end is capable of receiving and i= gnoring STUN Binding Indications, and the local UAS MUST send such as per S= ection 10 of [RFC5245] as if the SDP contained a candidate line. This is t= o ensure some initial packets gets sent to the loopback source, to create N= AT bindings or open Firewall pinholes along the path, since RTP is not gene= rated by the loopback mirror until RTP is received. >> 3) We specify that the media-loopback indication in SDP means the loopba= ck-source supports receiving and ignoring STUN Binding Indications, so that= following Section 10 of RFC 5245 the mirror MUST send STUN not no-op or co= mfort noise. >> 4) We put some text in the loopback-source about sources MUST support ig= noring received STUN Binding Indications, not depend on getting them, etc. >> =20 > This seems like a way forward that would keep us consistent with current = ICE procedures. We probably need to explore it in more detail (and I'd welc= ome more comments on this as well), but it seems promising. One question is= the frequency with which these STUN Binding Requests would be sent ? The frequency is in section 10, but I assume you mean when "inactive" mode = is used in media-loopback? That's a tough one. In a normal call there wou= ld be no RTP in that mode, and since the tester may want to test that mode = to see if it is causing problems then I think the mirror shouldn't send STU= N even then. :( -hadriel From internet-drafts@ietf.org Fri Oct 28 05:27:29 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 D068521F8B98; Fri, 28 Oct 2011 05:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uW0IF3zKBckF; Fri, 28 Oct 2011 05:27:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3AF21F8B4C; Fri, 28 Oct 2011 05:27:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111028122729.14066.44352.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2011 05:27:29 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-28.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, 28 Oct 2011 12:27:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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) : Henning Schulzrinne Anup Rao Rob Lanphier Magnus Westerlund Martin Stiemerling Filename : draft-ietf-mmusic-rfc2326bis-28.txt Pages : 297 Date : 2011-10-28 This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of 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-28.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-ietf-mmusic-rfc2326bis-28.txt From internet-drafts@ietf.org Mon Oct 31 05:03:09 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 573C821F8DC2; Mon, 31 Oct 2011 05:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNjDiGcjzkar; Mon, 31 Oct 2011 05:03:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD79D21F8D99; Mon, 31 Oct 2011 05:03:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 05:03:08 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-09.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: Mon, 31 Oct 2011 12:03:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-09.txt Pages : 30 Date : 2011-10-31 This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.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-ietf-mmusic-sdp-cs-09.txt From Simo.Veikkolainen@nokia.com Mon Oct 31 05:06:29 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 F31CA21F8D47 for ; Mon, 31 Oct 2011 05:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQOVzW6Cmj-r for ; Mon, 31 Oct 2011 05:06:28 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 02CB721F8DAE for ; Mon, 31 Oct 2011 05:06:26 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9VC65cV004492 for ; Mon, 31 Oct 2011 14:06:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 14:06:16 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 31 Oct 2011 13:06:15 +0100 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.38]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 13:06:15 +0100 From: To: Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt Thread-Index: AQHMl8UhGeJlmRQ8r02tioerLlQmapWWWu/g Date: Mon, 31 Oct 2011 12:06:15 +0000 Message-ID: References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> In-Reply-To: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: NgLgUAGhIMVcmkVcu9QCAzv+Bz/SDrcr/xSr2jrzza9g21NPZJkwj0rJbeCn4+LFWXFGxYloJ4iSj1eEFnad+28cjrGQHM6JcTT/E0o3Mr2OlKBDAvvUFYZ2NyajeCFuI3XlZFkSs1thkQvRQ/5bS00DEdEyj176YVAdoREnk7iOPmnpa4yT/u/CXKUMHQIW4sTZ9dtbmSQgfQ3qU+DAfEgPepaBuNO6oFOLSUmVtw68zH+PA7qV5UCN+yj0kFmS x-originating-ip: [172.21.22.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 12:06:16.0229 (UTC) FILETIME=[7DD3DD50:01CC97C5] X-Nokia-AV: Clean Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.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: Mon, 31 Oct 2011 12:06:29 -0000 SGksDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBzZHAtY3MgZHJhZnQg KGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11c2ljLXNk cC1jcy0wOS50eHQpLCBhZGRyZXNzaW5nIFBhdWwncyBjb21tZW50cy4NCg0KQmVsb3cgaXMgYSBs aXN0IG9mIGNoYW5nZXMgaW4gdGhlIC0wOSB2ZXJzaW9uOg0KDQpOdW1iZXIgZm9ybWF0DQotCVVz ZSB0aGUgdGVybSDigJxpbnRlcm5hdGlvbmFsIEUuMTY0IG51bWJlcuKAnSB0aHJvdWdob3V0IHRo ZSBkb2N1bWVudA0KLQlSZXF1aXJlIGEg4oCcK+KAnSBzaWduIGluIGFsbCBpbnRlcm5hdGlvbmFs IEUuMTY0IG51bWJlcnMNCg0KQWRkZWQgdGhlIGZvbGxvd2luZyBsaW5lcyB0byBhZGRyZXNzdHlw ZSBzcGVjaWZpY2F0aW9uIGluIDUuMi4xOg0K4oCcDQogICAgV2hlbiB0aGUgPGFkZHJ0eXBlPiBp cyBQU1ROLCB0aGUgY29ubmVjdGlvbiBhZGRyZXNzIGlzIGRlZmluZWQNCiAgICBhcyBmb2xsb3dz Og0KDQogICAgbyAgYW4gZTE2NC1hZGRyZXNzDQoNCiAgICBXaGVuIHRoZSA8YWRkcnR5cGU+IGlz ICItIiwgdGhlIGNvbm5lY3Rpb24gYWRkcmVzcyBpcyBkZWZpbmVkDQogICAgYXMgZm9sbG93czoN Cg0KICAgIG8gIHRoZSB2YWx1ZSAiLSIsIHNpZ25pZnlpbmcgdGhhdCB0aGUgYWRkcmVzcyBpcyB1 bmtub3duLg0KT1INCiAgICBvICBhbnkgc3ludGFjdGljYWxseSB2YWxpZCB2YWx1ZSwgd2hpY2gg aXMgdG8gYmUgaWdub3JlZC4uDQrigJwNCg0KU3ludGF4IG9mIGNzLWNvcnJlbGF0aW9uIGNoYW5n ZWQgaW4gNS4yLjMuMSANCg0KVVVJRSBwcm90b2NvbCBkaXNjcmltaW5hdG9yDQotCUNsYXJpZmll ZCB0aGF0IG9ubHkgdGhlIOKAnFVzZXIgaW5mb3JtYXRpb27igJ0gcGFydCBvZiBVVUlFIGlzIHRv IGJlIGluY2x1ZGVkIGFzIHRoZSB2YWx1ZSBvZiB1dWllLW1lY2gsIGFuZCB1c2VkIGZvciBjb21w YXJpbmcgdGhlIGluY29taW5nIFVVSUUNCi0JQWRkZWQgYW4gT1BFTiBJU1NVRSBzdGlsbCBoZXJl DQoNCk1vdmVkIHRoZSB1c2FnZSBvZiDigJxhPWNvbm5lY3Rpb246ZXhpc3RpbmfigJ0gdG8gNS41 LjQgTW9kaWZ5aW5nIHRoZSBzZXNzaW9uLg0KDQpBZGRlZCB0ZXh0IGluIDUuNS40IG9uIGhvdyBj b25uZWN0aW9uIHJldXNlIHdvcmtzLg0KDQpFLjE2NCBzeW50YXggaW4gNS42DQotIHdlIGRpZG7i gJl0IGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gUkZDMzk2NiBzaW5jZSB3ZSBkb27igJl0IHdhbnQg dG8gaW5jbHVkZSB0aGUgdmlzdWFsIHNlcGFyYXRvciwgYW5kIG90aGVyd2lzZSB0aGUgYmVuZWZp dCBvZiBoYXZpbmcgdGhlIFJGQyBhcyByZWZlcmVuY2Ugd291bGQgYmUgc21hbGwNCg0KQ2hhbmdl ZCB0aGUgbnVtYmVyIGluIHRoZSBleGFtcGxlcy4gKzE1NTUxMjM0IC0+ICszNTg5MTIzNDU2NyAo SSBrbm93IHRoaXMgYXQgbGVhc3QgaXMgYSBzeW50YWN0aWNhbGx5IGNvcnJlY3QgcmVwcmVzZW50 YXRpb24g74GKDQoNClRoaW5ncyB3aGljaCBkaWQgbm90IG1ha2UgdGhpcyB2ZXJzaW9uOg0KDQpU T0RPOiBBZGQgZXhhbXBsZSB3aXRoIENTIGF1ZGlvL3ZpZGVvIHN0cmVhbS4NClRPRE86IFNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIG5lZWRzIG1vcmUgd29yayBiYXNlZCBvbiBGbGVtbWluZydzIGVh cmxpZXIgY29tbWVudHMgKGluY2x1ZGluZyBjYWxsZXIncyBFMTY0IG51bWJlciBpbiBTRFApLg0K VE9ETzogQ2xhcmlmaWNhdGlvbiBvbiB0aGUgbWVjaGFuaXNtIHdvcmtzIHdpdGggM1BDQy4NCg0K DQpUaGFua3MNClNpbW8NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaS1k LWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNClNlbnQ6 IDMxIE9jdG9iZXIsIDIwMTEgMTQ6MDMNClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBt bXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLXNk cC1jcy0wOS50eHQNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBNdWx0aXBhcnR5IE11bHRpbWVkaWEgU2Vzc2lvbiBDb250cm9sIFdvcmtp bmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCglUaXRsZSAgICAgICAgICAgOiBTZXNzaW9uIERlc2Ny aXB0aW9uIFByb3RvY29sIChTRFApIEV4dGVuc2lvbiBGb3IgU2V0dGluZyBVcCBBdWRpbyBhbmQg VmlkZW8gTWVkaWEgU3RyZWFtcyBPdmVyIENpcmN1aXQtU3dpdGNoZWQgQmVhcmVycyBJbiBUaGUg UHVibGljIFN3aXRjaGVkIFRlbGVwaG9uZSBOZXR3b3JrIChQU1ROKQ0KCUF1dGhvcihzKSAgICAg ICA6IE1pZ3VlbCBBLiBHYXJjaWEtTWFydGluDQogICAgICAgICAgICAgICAgICAgICAgICAgIFNp bW8gVmVpa2tvbGFpbmVuDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1tbXVzaWMtc2Rw LWNzLTA5LnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDMwDQoJRGF0ZSAgICAgICAgICAgIDogMjAx MS0xMC0zMQ0KDQogICBUaGlzIG1lbW8gZGVzY3JpYmVzIHVzZSBjYXNlcywgcmVxdWlyZW1lbnRz LCBhbmQgcHJvdG9jb2wgZXh0ZW5zaW9ucw0KICAgZm9yIHVzaW5nIHRoZSBTZXNzaW9uIERlc2Ny aXB0aW9uIFByb3RvY29sIChTRFApIE9mZmVyL0Fuc3dlciBtb2RlbA0KICAgZm9yIGVzdGFibGlz aGluZyBhdWRpbyBhbmQgdmlkZW8gbWVkaWEgc3RyZWFtcyBvdmVyIGNpcmN1aXQtc3dpdGNoZWQN CiAgIGJlYXJlcnMgaW4gdGhlIFB1YmxpYyBTd2l0Y2hlZCBUZWxlcGhvbmUgTmV0d29yayAoUFNU TikuDQoNCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtY3MtMDkudHh0DQoN CkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN CmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNClRoaXMgSW50ZXJuZXQtRHJh ZnQgY2FuIGJlIHJldHJpZXZlZCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLWNzLTA5LnR4dA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkkt RC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0 ZXMudHh0DQo= From internet-drafts@ietf.org Mon Oct 31 10:04:03 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 C3F7F11E815B; Mon, 31 Oct 2011 10:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2r1x1xVKeFQA; Mon, 31 Oct 2011 10:04:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B1721F84A5; Mon, 31 Oct 2011 10:04:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031170403.17308.84925.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 10:04:03 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-media-capabilities-12.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: Mon, 31 Oct 2011 17:04:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : SDP Media Mapabilities Negotiation Author(s) : Robert R Gilman Roni Even Flemming Andreasen Filename : draft-ietf-mmusic-sdp-media-capabilities-12.txt Pages : 50 Date : 2011-10-31 Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilitie= s-12.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-ietf-mmusic-sdp-media-capabilities= -12.txt From fandreas@cisco.com Mon Oct 31 12:26: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 A290711E815F for ; Mon, 31 Oct 2011 12:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysrqTeyXsnTg for ; Mon, 31 Oct 2011 12:26:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8304B11E8154 for ; Mon, 31 Oct 2011 12:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=5436; q=dns/txt; s=iport; t=1320089198; x=1321298798; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DfiN/efUqowqH57Gs6rhsJP6m3+1Vg5FziqkJ+k0hCc=; b=kIZgkhbFrP9bE0VSi2ks/t9WMi2dPUVGw8TqiZp9HA2gFmF05kY2lWmA /AiHFsdEWrlQspO8MqaB3Ii46tt78xBM779e45+uoNEan4Edc0a+NdYFT kQLiBNUaYU5LZ+A/K1uaz+7crKGjSD8XwUY144BAGoy2Mdnaksvwksngl c=; X-IronPort-AV: E=Sophos;i="4.69,433,1315180800"; d="scan'208";a="32298322" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 31 Oct 2011 19:26:38 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9VJQjJm019227; Mon, 31 Oct 2011 19:26:45 GMT Message-ID: <4EAEF66D.3030007@cisco.com> Date: Mon, 31 Oct 2011 15:26:37 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> <7F97F7F5-86F0-4684-B2C4-F4B9372C6E26@acmepacket.com> <4EAA080D.8070801@cisco.com> <945EE41C-0068-4CBE-8797-1DF8C7F2BDC0@acmepacket.com> In-Reply-To: <945EE41C-0068-4CBE-8797-1DF8C7F2BDC0@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "" , "Elwell, John" , "mmusic \(E-mail\)" , Dan Wing Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 31 Oct 2011 19:26:39 -0000 On 10/27/11 11:36 PM, Hadriel Kaplan wrote: > On Oct 27, 2011, at 9:40 PM, Flemming Andreasen wrote: > > =20 >>> As I understand it, your concern is we (1) don't have an RFC defining= how NAT traversal works if not with ICE, (2) don't want to define a "pri= mer" thingy just for this one loopback draft, and (3) are dizzy from of g= oing around in circles. :) >>> >>> =20 >> Right, and >> (4) If we are not happy with ICE as our IETF NAT traversal mechanism, = for whatever reason, then we as WG need to be explicit about that and fig= ure out a way of addressing it in general - not just in the form of and a= s part of some loopback specific discussion (or we'll have another one of= these threads when the next draft comes along that needs to work behind = NATs, but doesn't really want to do ICE). >> =20 > While I and some others have noted on multiple occasions that ICE isn't= the utopian solution it's cracked up to be, it appears so far we're stil= l in the minority in the WG. > > I did put in text in: > http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00 > in Appendix A.2, of an example why ICE can't be used for some people - = but that's sort of an obscure reference because the point of the draft is= about IPv4/v6 not NATs. Would it make sense to include this as part of John Elwells ICE draft ? > There're other ICE-problem examples too, like in the Enterprise marke= t where the IT guys want to force the media to go through their VPNs or s= tay inside and never reach the public Internet. > > But essentially media-loopback is the only case I've seen where there's= a NAT problem to solve that isn't auto-handled by just normal RTP behavi= or and latching. The IPv4/v6 case isn't a NAT traversal problem per se, = nor a latching one, but more of a need to indicate multiple address famil= ies in SDP, competing with the desire by some others in the WG that a con= nectivity check type thing happens because IPv6 isn't stable. > > > =20 >>> My point in all this is to propose the following high-level straw-man= : >>> >>> 1) We use the STUN Binding Indications as our primer packet format, b= y referencing STUN RFC. >>> >>> =20 >> Any reason we can't reference the ICE RFC and make it a "SHOULD" imple= ment ? >> =20 > How about this: "A UAC compliant with this document SHOULD implement [R= FC5245], but MAY only implement section 10 of [RFC5245] with the addition= al rules noted in section X of this document if it does not use ICE for n= ormal media sessions." > > And section X would have something like this: > When a UAS loopback mirror receives an SDP Offer with media-loopback, i= f the UAS implements [RFC5245] then it follows ICE procedures, including = fallback to just sending STUN Binding Indications per Section 10 of ICE i= f the received Offer did not indicate ICE or there is an ICE mismatch con= dition. If the UAS does not implement [RFC5245], then it MUST at least f= ollow the procedures of Section 10 of [RFC5245] and send STUN Binding Ind= ications. In all cases, even if ICE is not actively used, the existence = of the media-loopback indication in SDP indicates the far-end is capable = of receiving and ignoring STUN Binding Indications, and the local UAS MUS= T send such as per Section 10 of [RFC5245] as if the SDP contained a cand= idate line. This is to ensure some initial packets gets sent to the loop= back source, to create NAT bindings or open Firewall pinholes along the p= ath, since RTP is not generated by the loopback mirror until RTP is recei= ved. > > =20 I'd like to hear more people commenting on this. My understanding of ICE = Section 5.1/10 in this case is that it's for keep-alives and hence you=20 wouldn't send these messages initially (which is not to say that=20 couldn't be changed when used with loopback - the question is how it=20 differs from "real" ICE then). >>> 3) We specify that the media-loopback indication in SDP means the loo= pback-source supports receiving and ignoring STUN Binding Indications, so= that following Section 10 of RFC 5245 the mirror MUST send STUN not no-o= p or comfort noise. >>> 4) We put some text in the loopback-source about sources MUST support= ignoring received STUN Binding Indications, not depend on getting them, = etc. >>> >>> =20 >> This seems like a way forward that would keep us consistent with curre= nt ICE procedures. We probably need to explore it in more detail (and I'd= welcome more comments on this as well), but it seems promising. One ques= tion is the frequency with which these STUN Binding Requests would be sen= t ? >> =20 > The frequency is in section 10, but I assume you mean when "inactive" m= ode is used in media-loopback? That's a tough one. In a normal call the= re would be no RTP in that mode, and since the tester may want to test th= at mode to see if it is causing problems then I think the mirror shouldn'= t send STUN even then. :( > =20 I believe Section 10 would only apply to keep-alives in the scenario=20 being considered here (and hence inactive mode is fine). The issue, I=20 believe, is that you need these STUN binding packets sent initially to=20 punch a hole through the NAT, and I don't believe the current RFC 5245=20 by itself will give you that. -- Flemming > -hadriel > > > =20 From pkyzivat@alum.mit.edu Mon Oct 31 12:30:28 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 6848F1F0C3D for ; Mon, 31 Oct 2011 12:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH3OEyAl1H1m for ; Mon, 31 Oct 2011 12:30:27 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 701D01F0C8E for ; Mon, 31 Oct 2011 12:30:27 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA11.westchester.pa.mail.comcast.net with comcast id rXUq1h00617dt5G5BXWTUD; Mon, 31 Oct 2011 19:30:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta13.westchester.pa.mail.comcast.net with comcast id rXWT1h00Q0tdiYw3ZXWTGm; Mon, 31 Oct 2011 19:30:27 +0000 Message-ID: <4EAEF751.6000205@alum.mit.edu> Date: Mon, 31 Oct 2011 15:30:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.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: Mon, 31 Oct 2011 19:30:28 -0000 Thanks. This clears up a lot. In looking over the changes, I noted the following other things: Syntax (in 5.2.3.1 and 5.6): As written, this will allow individual correlation mechanisms to be repeated, possibly with differing values. E.g. a=cs-correlation: dtmf:123 dtmf:456 I'm not sure, but I *doubt* you intend to allow that. To address it, you have a couple of choices: - fiddle the syntax to disallow it. - put in textual rules to forbid it. In section 5.2.3.2, you have: For example, the numbers +358-9-123-4567 and 09-123-4567 could be considered as the same number. This could be interpreted as indicating that the international E.164 number might contain separator characters. Based on your syntax, the one in the cs-correlation attribute can't have them. I'm not sure if the one received as callerid info from the PSTN can have them or not. In section 5.2.3.3: The protocol discriminator must be specified *somewhere*. Either you can specify a fixed one as part of this mechanism, or else you must allow it to be specified as part of the value. In section 5.5.4: "If either party wishes to drop and reestablish an existing call..." This implies that one must use one o/a exchange to drop the existing call and another one to establish it again. That shouldn't be necessary. Sending the same sort of offer one would do to establish the initial session (including a=connection:new) should be fine. Thanks, Paul On 10/31/11 8:06 AM, Simo.Veikkolainen@nokia.com wrote: > Hi, > We have submitted a new version of the sdp-cs draft (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.txt), addressing Paul's comments. > > Below is a list of changes in the -09 version: > > Number format > - Use the term “international E.164 number” throughout the document > - Require a “+” sign in all international E.164 numbers > > Added the following lines to addresstype specification in 5.2.1: > “ > When the is PSTN, the connection address is defined > as follows: > > o an e164-address > > When the is "-", the connection address is defined > as follows: > > o the value "-", signifying that the address is unknown. > OR > o any syntactically valid value, which is to be ignored.. > “ > > Syntax of cs-correlation changed in 5.2.3.1 > > UUIE protocol discriminator > - Clarified that only the “User information” part of UUIE is to be included as the value of uuie-mech, and used for comparing the incoming UUIE > - Added an OPEN ISSUE still here > > Moved the usage of “a=connection:existing” to 5.5.4 Modifying the session. > > Added text in 5.5.4 on how connection reuse works. > > E.164 syntax in 5.6 > - we didn’t include a reference to RFC3966 since we don’t want to include the visual separator, and otherwise the benefit of having the RFC as reference would be small > > Changed the number in the examples. +15551234 -> +35891234567 (I know this at least is a syntactically correct representation  > > Things which did not make this version: > > TODO: Add example with CS audio/video stream. > TODO: Security considerations needs more work based on Flemming's earlier comments (including caller's E164 number in SDP). > TODO: Clarification on the mechanism works with 3PCC. > > > Thanks > Simo > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org > Sent: 31 October, 2011 14:03 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: I-D Action: draft-ietf-mmusic-sdp-cs-09.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 : Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) > Author(s) : Miguel A. Garcia-Martin > Simo Veikkolainen > Filename : draft-ietf-mmusic-sdp-cs-09.txt > Pages : 30 > Date : 2011-10-31 > > This memo describes use cases, requirements, and protocol extensions > for using the Session Description Protocol (SDP) Offer/Answer model > for establishing audio and video media streams over circuit-switched > bearers in the Public Switched Telephone Network (PSTN). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.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-ietf-mmusic-sdp-cs-09.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From gunnar.hellstrom@omnitor.se Mon Oct 31 23:13:30 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 BDA5F11E80E8 for ; Mon, 31 Oct 2011 23:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRc7GJI6aMAC for ; Mon, 31 Oct 2011 23:13:29 -0700 (PDT) Received: from vsp-outgoing3.binero.net (vsp-outgoing3.binero.net [193.17.218.162]) by ietfa.amsl.com (Postfix) with SMTP id 1C8C411E80B2 for ; Mon, 31 Oct 2011 23:13:27 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing3.binero.net (Halon Mail Gateway) with ESMTP for ; Tue, 1 Nov 2011 07:13:18 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 9E72A3A185; Tue, 1 Nov 2011 07:13:17 +0100 (CET) Message-ID: <4EAF8E01.4010807@omnitor.se> Date: Tue, 01 Nov 2011 07:13:21 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Flemming Andreasen References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> <7F97F7F5-86F0-4684-B2C4-F4B9372C6E26@acmepacket.com> <4EAA080D.8070801@cisco.com> <945EE41C-0068-4CBE-8797-1DF8C7F2BDC0@acmepacket.com> <4EAEF66D.3030007@cisco.com> In-Reply-To: <4EAEF66D.3030007@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Wing , "Elwell, John" , "" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 01 Nov 2011 06:13:30 -0000 Can rfc6263 RTP Keep-alive be referenced for the non-ICE case? /Gunnar Flemming Andreasen skrev 2011-10-31 20:26: > > > On 10/27/11 11:36 PM, Hadriel Kaplan wrote: >> On Oct 27, 2011, at 9:40 PM, Flemming Andreasen wrote: >> >>>> As I understand it, your concern is we (1) don't have an RFC >>>> defining how NAT traversal works if not with ICE, (2) don't want to >>>> define a "primer" thingy just for this one loopback draft, and (3) >>>> are dizzy from of going around in circles. :) >>>> >>> Right, and >>> (4) If we are not happy with ICE as our IETF NAT traversal >>> mechanism, for whatever reason, then we as WG need to be explicit >>> about that and figure out a way of addressing it in general - not >>> just in the form of and as part of some loopback specific discussion >>> (or we'll have another one of these threads when the next draft >>> comes along that needs to work behind NATs, but doesn't really want >>> to do ICE). >> While I and some others have noted on multiple occasions that ICE >> isn't the utopian solution it's cracked up to be, it appears so far >> we're still in the minority in the WG. >> >> I did put in text in: >> http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00 >> in Appendix A.2, of an example why ICE can't be used for some people >> - but that's sort of an obscure reference because the point of the >> draft is about IPv4/v6 not NATs. > Would it make sense to include this as part of John Elwells ICE draft ? > >> There're other ICE-problem examples too, like in the Enterprise >> market where the IT guys want to force the media to go through their >> VPNs or stay inside and never reach the public Internet. >> >> But essentially media-loopback is the only case I've seen where >> there's a NAT problem to solve that isn't auto-handled by just normal >> RTP behavior and latching. The IPv4/v6 case isn't a NAT traversal >> problem per se, nor a latching one, but more of a need to indicate >> multiple address families in SDP, competing with the desire by some >> others in the WG that a connectivity check type thing happens because >> IPv6 isn't stable. >> >> >>>> My point in all this is to propose the following high-level straw-man: >>>> >>>> 1) We use the STUN Binding Indications as our primer packet format, >>>> by referencing STUN RFC. >>>> >>> Any reason we can't reference the ICE RFC and make it a "SHOULD" >>> implement ? >> How about this: "A UAC compliant with this document SHOULD implement >> [RFC5245], but MAY only implement section 10 of [RFC5245] with the >> additional rules noted in section X of this document if it does not >> use ICE for normal media sessions." >> >> And section X would have something like this: >> When a UAS loopback mirror receives an SDP Offer with media-loopback, >> if the UAS implements [RFC5245] then it follows ICE procedures, >> including fallback to just sending STUN Binding Indications per >> Section 10 of ICE if the received Offer did not indicate ICE or there >> is an ICE mismatch condition. If the UAS does not implement >> [RFC5245], then it MUST at least follow the procedures of Section 10 >> of [RFC5245] and send STUN Binding Indications. In all cases, even >> if ICE is not actively used, the existence of the media-loopback >> indication in SDP indicates the far-end is capable of receiving and >> ignoring STUN Binding Indications, and the local UAS MUST send such >> as per Section 10 of [RFC5245] as if the SDP contained a candidate >> line. This is to ensure some initial packets gets sent to the >> loopback source, to create NAT bindings or open Firewall pinholes >> along the path, since RTP is not generated by the loopback mirror >> until RTP is received. >> > > I'd like to hear more people commenting on this. My understanding of > ICE Section 5.1/10 in this case is that it's for keep-alives and hence > you wouldn't send these messages initially (which is not to say that > couldn't be changed when used with loopback - the question is how it > differs from "real" ICE then). > >>>> 3) We specify that the media-loopback indication in SDP means the >>>> loopback-source supports receiving and ignoring STUN Binding >>>> Indications, so that following Section 10 of RFC 5245 the mirror >>>> MUST send STUN not no-op or comfort noise. >>>> 4) We put some text in the loopback-source about sources MUST >>>> support ignoring received STUN Binding Indications, not depend on >>>> getting them, etc. >>>> >>> This seems like a way forward that would keep us consistent with >>> current ICE procedures. We probably need to explore it in more >>> detail (and I'd welcome more comments on this as well), but it seems >>> promising. One question is the frequency with which these STUN >>> Binding Requests would be sent ? >> The frequency is in section 10, but I assume you mean when "inactive" >> mode is used in media-loopback? That's a tough one. In a normal >> call there would be no RTP in that mode, and since the tester may >> want to test that mode to see if it is causing problems then I think >> the mirror shouldn't send STUN even then. :( > I believe Section 10 would only apply to keep-alives in the scenario > being considered here (and hence inactive mode is fine). The issue, I > believe, is that you need these STUN binding packets sent initially to > punch a hole through the NAT, and I don't believe the current RFC 5245 > by itself will give you that. > > -- Flemming > > >> -hadriel >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic