From miguel.a.garcia@ericsson.com Mon Apr 2 06:18:16 2012 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 E8FE321F8510 for ; Mon, 2 Apr 2012 06:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 J8gVvbgj-aOw for ; Mon, 2 Apr 2012 06:18:16 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 35D5821F850F for ; Mon, 2 Apr 2012 06:18:16 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-5c-4f79a717d0f3 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5E.4C.03534.717A97F4; Mon, 2 Apr 2012 15:18:15 +0200 (CEST) Received: from [159.107.24.209] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012 15:18:14 +0200 Message-ID: <4F79A716.3080804@ericsson.com> Date: Mon, 2 Apr 2012 15:18:14 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mmusic , draft-ietf-mmusic-media-loopback.authors@tools.ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 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, 02 Apr 2012 13:18:17 -0000 This is to start a 2-week Working Group Last Call for draft-ietf-mmusic-media-loopback-18.txt The WGLC ends on April 16th, 2012. Please reply to this e-mail to send comments, so that the authors and the mailing list are all copied. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Tue Apr 3 05:35:17 2012 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 A93B621F879D for ; Tue, 3 Apr 2012 05:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 637MwK9n3OkT for ; Tue, 3 Apr 2012 05:35:17 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BC6E921F8764 for ; Tue, 3 Apr 2012 05:35:16 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-f8-4f7aee830774 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 88.0E.03534.38EEA7F4; Tue, 3 Apr 2012 14:35:15 +0200 (CEST) Received: from [159.107.25.175] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Apr 2012 14:35:15 +0200 Message-ID: <4F7AEE82.5030704@ericsson.com> Date: Tue, 3 Apr 2012 14:35:14 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.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] Feedback on draft-boucadair-mmusic-altc-04 as Independent Submission 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, 03 Apr 2012 12:35:17 -0000 This mail is related to draft-boucadair-mmusic-altc-04.txt, available at: http://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/ This draft has been submitted to the RFC Editor for publication in the independent submission stream. Because of this, it can be published as either Informational or Experimental RFC. The RFC Editor, in these cases, gets feedback from the community about the possible publication, including consultation to the IESG (see RFC 5742). We would like to get your input, basically, indicating whether you are OK with the publication of this Informational/Experimental RFC or whether you have concerns. We will try to have a consolidated set of comments to the RFC Editor. The draft proposes a mechanism to include several IP addresses related to the same media stream in an SDP offer, including alternative IPv4 and IPv6 addresses. The draft presents a problem: it defines a SIP option tag. SIP option tags can only be defined in standards track RFCs (See RFC 3261 Section 19.2), but this document can only be Informational or Experimental. Please let the mailing list know your thoughts. BR, Flemming and Miguel (chairs) -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From brett@broadsoft.com Tue Apr 3 06:30:25 2012 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 2950D11E808E for ; Tue, 3 Apr 2012 06:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 sXJav+GVJIOT for ; Tue, 3 Apr 2012 06:30:24 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpedge01.chinookhosting.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id 669A811E809A for ; Tue, 3 Apr 2012 06:30:24 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 3 Apr 2012 06:32:08 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Tue, 3 Apr 2012 06:32:08 -0700 From: Brett Tate To: mmusic Date: Tue, 3 Apr 2012 06:30:22 -0700 Thread-Topic: [MMUSIC] Feedback on draft-boucadair-mmusic-altc-04 as Independent Submission Thread-Index: Ac0Rlnv0b+4V5GufRkiEgWszGw38GwAAjDPQ Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1E2AF95C@EXMBXCLUS01.citservers.local> References: <4F7AEE82.5030704@ericsson.com> In-Reply-To: <4F7AEE82.5030704@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Feedback on draft-boucadair-mmusic-altc-04 as Independent Submission 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, 03 Apr 2012 13:30:25 -0000 The functionality provided by draft-boucadair-mmusic-altc is useful. I pre= fer that this draft progress to be an RFC. It should progress as standard = track; however publishing as Informational is adequate (especially if can r= eserve the "altc" option-tag) if no IETF working group is willing to work o= n the draft. If the option-tag issue causes concern, it currently appears to provide lit= tle value other than a hint. Thus, it could be removed or uselessly commun= icated by other means (such as defining a "ns-supported" header to mean the= same thing as "supported" when non standard track). Thanks, Brett From ietf@meetecho.com Tue Apr 3 07:34:08 2012 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 5D3FA21F879E for ; Tue, 3 Apr 2012 07:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI0AFcOpbnoO for ; Tue, 3 Apr 2012 07:34:07 -0700 (PDT) Received: from smtpw2.aruba.it (smtpw.aruba.it [62.149.157.41]) by ietfa.amsl.com (Postfix) with SMTP id 418CA21F879D for ; Tue, 3 Apr 2012 07:34:06 -0700 (PDT) Received: (qmail 19824 invoked by uid 89); 3 Apr 2012 14:33:54 -0000 Received: from unknown (HELO meetecho.com) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 3 Apr 2012 14:33:54 -0000 Date: Tue, 3 Apr 2012 16:33:54 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1333463634.2A.468187.42.24781.52.42.007.1312405235" From: "Meetecho IETF support" To: mmusic@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 143.225.229.174 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N Cc: team@meetecho.com Subject: [MMUSIC] Meetecho recordings available 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, 03 Apr 2012 14:34:08 -0000 --_=__=_XaM3_.1333463634.2A.468187.42.24781.52.42.007.1312405235 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,=0A=0Athe full recording (synchronized video, audio, slides and = jabber room)=0Aof MMUSIC session at IETF-83 is available.=0A=0AYou can wa= tch it by either clicking the proper link on the remote =0Aparticipation = page =0A(http://www.ietf.org/meeting/83/remote-participation.html#Meetech= o), or =0Aby directly accessing the following URL:=0Ahttp://ietf83.conf.m= eetecho.com/index.php/Recorded_Sessions#MMUSIC_IETF83=0A=0AFor the chair(= s): please feel free to put the link to the recording in =0Athe minutes, = if you think this might be useful.=0A=0AIn case of problems with the play= out, just drop an e-mail to=0Ateam@meetecho.com.=0A=0ACheers,=0Athe Meete= cho team=C2=A0=0A=0A=C2=A0=0AMeetecho s.r.l.=0AWeb Conferencing and Colla= boration Tools=0Awww.meetecho.com=0A=C2=A0 --_=__=_XaM3_.1333463634.2A.468187.42.24781.52.42.007.1312405235 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A
=0A
Dear all,=0A
=0A
the full recording (syn= chronized video, audio, slides and jabber room)=0A
of MMUSIC session a= t IETF-83 is available.=0A
=0A
You can watch it by either clicking = the proper link on the remote =0Aparticipation page =0A(http://www.ietf.org/meeting/83/remote-participation.h= tml#Meetecho), or =0Aby directly accessing the following URL:=0A
<= a class=3D"moz-txt-link-freetext" href=3D"http://ietf83.conf.meetecho.com= /index.php/Recorded_Sessions#XRBLOCK_IETF83">http://ietf83.conf.meetecho.= com/index.php/Recorded_Sessions#MMUSIC_IETF83=0A
=0A
For the ch= air(s): please feel free to put the link to the recording in =0Athe minut= es, if you think this might be useful.=0A
=0A
In case of problems w= ith the playout, just drop an e-mail to=0A
team@meetecho.com.=0A
=0A
Cheers,=0A=
the Meetecho team =0A
 
Meetecho s.r.l.=
Web Conferencing and Collaboration Tools
www.meetech= o.com
 
=0A
=0A --_=__=_XaM3_.1333463634.2A.468187.42.24781.52.42.007.1312405235-- From vsingh.ietf@gmail.com Tue Apr 3 08:35:22 2012 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 ABFBD11E80F6 for ; Tue, 3 Apr 2012 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, 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 WVj+KboFIf2N for ; Tue, 3 Apr 2012 08:35:22 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A52E911E80E6 for ; Tue, 3 Apr 2012 08:35:21 -0700 (PDT) Received: by werb10 with SMTP id b10so3051136wer.31 for ; Tue, 03 Apr 2012 08:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=rWPjS5C5FZXBeKRTC5CSMob5UQ6eJOFQzHEHew7jrkM=; b=IkzZ+LlQxHCWfD01/5maD+kXfc9PjsO08wjxxTEKGqqtzwTyOg53bVvg0tGSpzx0Wk 3ZiYPFK1kDLUcB/vB32wo9AotBElqEQLiqvNnDxwHKPT7CC4MFoOFtWxpel3C/HeKImp zhBJ8SgevhixiQfL3eWlqfySj1AYT8jtWVxipRX4z/sABnsDsv7PJEYK73WnYCz6LseT OLUHSr8RAmJGo/fs+920XwZTaVyq3l7GC/HB8/8tAU+tbXns9qCLZcrbnXzlfcKWUY3Z eSIFMQczsupa3FZaerZTT986ZJWrakxFz4tZiI+Xai2/vSsRqwQ1tsf4fF8NBKEI9VaJ ezYg== Received: by 10.180.98.8 with SMTP id ee8mr37717196wib.14.1333467320637; Tue, 03 Apr 2012 08:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.2.10 with HTTP; Tue, 3 Apr 2012 08:35:00 -0700 (PDT) In-Reply-To: <454A16E4DA86094EB66BB2C1DBBBC0180765E90B@XMB-BGL-41B.cisco.com> References: <454A16E4DA86094EB66BB2C1DBBBC0180765E609@XMB-BGL-41B.cisco.com> <454A16E4DA86094EB66BB2C1DBBBC0180765E90B@XMB-BGL-41B.cisco.com> From: Varun Singh Date: Tue, 3 Apr 2012 18:35:00 +0300 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?J=F6rg_Ott?= , mmusic@ietf.org, "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] Comments on draft-singh-avtcore-mprtp-04 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, 03 Apr 2012 15:35:22 -0000 Hi Tiru, Clarifications inline. On Fri, Mar 23, 2012 at 13:35, Tirumaleswar Reddy (tireddy) wrote: > >> >> Hi Tiru, >> >> Response inline. >> >> On Wed, Mar 21, 2012 at 20:07, Tirumaleswar Reddy (tireddy) >> wrote: >> > Hi Varun - >> > >> > I have few comments related to the draft >> > >> > a)How is the situation handled when new network paths become >> > available/disabled after the call is setup ? >> > >> > =A0=A0=A0 (3G enabled/disabled after the call is setup) >> > >> >> This is a local decision and MPRTP will use all available paths. >> Either the application or ICE or something else needs to tell MPRTP >> when an interface is available or unavailable. >> >> At the media level (in the worst case) the sending endpoint will >> discover a path is unavailable when a subflow reports 100% loss and it >> will stop using it. Alternatively, if the endpoint discovers that one >> of its interface is disabled it can advertise a new set of interfaces >> (excluding the disabled interface from the set) to the other endpoint. > > Please refer RFC 6419 on the problems and behavior of various OS related = to MIF. For example Section 3.1.2 Connection Manager only selects the best = possible connection for the app based on the destination. The default conne= ction manager always prefers wired over wireless. > You are right that the connection manager chooses the interface but this is probably true for any protocol that tries to do multipath. The application probably needs to either override this behavior (e.g., sudo/ raw sockets/ kernel configuration) or the scheduling algorithm needs to make sure that it does not cause congestion by assuming multipath and sending too much data. >> >> > b)There is little information related to IPv6. How SIP Client would >> pick >> > among list of ULA, link-local addresses, IPv6 global addresses with >> > different precedence using ICE (refer to >> > draft-keranen-mmusic-ice-adress-selection) ? >> > >> >> It is also a local decision. This should not be different from the >> choices made by an endpoint using a single path. if an endpoint is >> using ICE then it just inherits the ICE priorities. > > For example consider a IPv6 Mobile Node making SIP call in PMIPv6. This n= ode could be assigned both MAG and LMA prefixes. Let's say the destination = is reachable through both the prefixes. But the issue is only LMA prefix wo= uld offer mobility if Mobile Node moves out of the hotspot MAG prefix will = not be available. In a different region he may get a different MAG prefix. = But if we consider a branch with multiple ISP - such complexities may not a= rise. The problem in this case would be the SIP client being provided the l= ist of host candidate addresses with the preference provided by RFC 3484 (a= nd using ICE). You will need support from OS to achieve this. > Yes, support from the OS or some rules (described in the aforementioned RFC/drafts) are needed to restrict the list of interface candidates. We will make this clear in the upcoming drafts. Cheers, Varun --=20 http://www.netlab.tkk.fi/~varun/ From miguel.a.garcia@ericsson.com Wed Apr 4 03:20:13 2012 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 0CC0721F86A1 for ; Wed, 4 Apr 2012 03:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 5G9ovVp9atAU for ; Wed, 4 Apr 2012 03:20:12 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC7521F869E for ; Wed, 4 Apr 2012 03:20:11 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-c1-4f7c205a0303 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 39.78.25560.A502C7F4; Wed, 4 Apr 2012 12:20:10 +0200 (CEST) Received: from [159.107.48.214] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012 12:20:10 +0200 Message-ID: <4F7C2058.6080601@ericsson.com> Date: Wed, 4 Apr 2012 12:20:08 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Brett Tate References: <4F7AEE82.5030704@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1E2AF95C@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1E2AF95C@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mmusic Subject: Re: [MMUSIC] Feedback on draft-boucadair-mmusic-altc-04 as Independent Submission 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, 04 Apr 2012 10:20:13 -0000 Hi Brett. Notice that this draft has been sent directly to the RFC Editor for publication in the Independent Stream. This means that it can only be published as Informational or Experimental. Additionally, MMUSIC has been requested for comments, but bear in mind, that this document is not the produce of the IETF. /Miguel On 03/04/2012 15:30, Brett Tate wrote: > The functionality provided by draft-boucadair-mmusic-altc is useful. I prefer that this draft progress to be an RFC. It should progress as standard track; however publishing as Informational is adequate (especially if can reserve the "altc" option-tag) if no IETF working group is willing to work on the draft. > > If the option-tag issue causes concern, it currently appears to provide little value other than a hint. Thus, it could be removed or uselessly communicated by other means (such as defining a "ns-supported" header to mean the same thing as "supported" when non standard track). > > Thanks, > Brett > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From brett@broadsoft.com Wed Apr 4 05:42:31 2012 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 9246121F8592 for ; Wed, 4 Apr 2012 05:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 tiaFRWME3OqM for ; Wed, 4 Apr 2012 05:42:30 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id B33B621F8462 for ; Wed, 4 Apr 2012 05:42:30 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Apr 2012 05:44:14 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Wed, 4 Apr 2012 05:44:13 -0700 From: Brett Tate To: "Miguel A. Garcia" , mmusic Date: Wed, 4 Apr 2012 05:42:27 -0700 Thread-Topic: [MMUSIC] Feedback on draft-boucadair-mmusic-altc-04 as Independent Submission Thread-Index: Ac0STNsHpLqLaH6JS1erq2APVAN8bgABog/Q Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1E2AFB28@EXMBXCLUS01.citservers.local> References: <4F7AEE82.5030704@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1E2AF95C@EXMBXCLUS01.citservers.local> <4F7C2058.6080601@ericsson.com> In-Reply-To: <4F7C2058.6080601@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Feedback on draft-boucadair-mmusic-altc-04 as Independent Submission 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, 04 Apr 2012 12:42:31 -0000 > Notice that this draft has been sent directly to the RFC Editor for > publication in the Independent Stream. This means that it can only be > published as Informational or Experimental. >=20 > Additionally, MMUSIC has been requested for comments, but bear in mind, > that this document is not the produce of the IETF. I agree. My mentioning of "standard track" and "no IETF working group is w= illing to work on the draft" was mostly just an attempt to reconcile why an= Informational draft defines a new option-tag even though IANA (per RFC 326= 1 and RFC 5727) may disallow registering/reserving the new option-tag. As = highlighted within IETF 77 minutes (and thread http://www.ietf.org/mail-arc= hive/web/mmusic/current/msg09016.html), the attempts to get MMUSIC to adopt= altc or other ICE alternatives (for IPv4/IPv6 transition) have failed. For what it's worth, I'd actually prefer that the new option-tag be removed= from the draft since it is mostly only a hint and complicates things for s= ome B2BUA/3PCC situations. However as indicated, the draft is an independe= nt submission. Thus, my preference is likely of little value unless the ne= w option-tag prevents the draft from becoming an RFC (and becoming an RFC c= ontinues to be preferred by the authors). > On 03/04/2012 15:30, Brett Tate wrote: > > The functionality provided by draft-boucadair-mmusic-altc is useful. > I prefer that this draft progress to be an RFC. It should progress as > standard track; however publishing as Informational is adequate > (especially if can reserve the "altc" option-tag) if no IETF working > group is willing to work on the draft. > > > > If the option-tag issue causes concern, it currently appears to > provide little value other than a hint. Thus, it could be removed or > uselessly communicated by other means (such as defining a "ns- > supported" header to mean the same thing as "supported" when non > standard track). From miguel.a.garcia@ericsson.com Tue Apr 10 00:18:31 2012 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 B56AF21F8452 for ; Tue, 10 Apr 2012 00:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Wdk5NG12y9lN for ; Tue, 10 Apr 2012 00:18:31 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C2E5721F848E for ; Tue, 10 Apr 2012 00:18:30 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-ff-4f83dec11a04 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2C.E9.03534.1CED38F4; Tue, 10 Apr 2012 09:18:25 +0200 (CEST) Received: from [159.107.24.229] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Apr 2012 09:18:25 +0200 Message-ID: <4F83DEC0.6080309@ericsson.com> Date: Tue, 10 Apr 2012 09:18:24 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mmusic References: <4F79A716.3080804@ericsson.com> In-Reply-To: <4F79A716.3080804@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" , Flemming Andreasen Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 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, 10 Apr 2012 07:18:31 -0000 A short note: A reviewer of Media MIME types team sent some minor/editorial comments to Section 13 of the draft. The review is available here: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01649.html /Miguel On 02/04/2012 15:18, Miguel A. Garcia wrote: > This is to start a 2-week Working Group Last Call for > > draft-ietf-mmusic-media-loopback-18.txt > > The WGLC ends on April 16th, 2012. > > Please reply to this e-mail to send comments, so that the authors and the > mailing list are all copied. > > /Miguel > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From fandreas@cisco.com Tue Apr 10 09:39:38 2012 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 5374D11E8117 for ; Tue, 10 Apr 2012 09:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Jm7Qlya29Vax for ; Tue, 10 Apr 2012 09:39:37 -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 3420411E80E8 for ; Tue, 10 Apr 2012 09:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=9475; q=dns/txt; s=iport; t=1334075977; x=1335285577; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ztYGQ+pHHziKoS1sB2H1KgebuUvxYU2XbK/LNf3VzG4=; b=eadN+QXbosFBE6e4RPkQzTp1VWultL8MPTxJ9KJiRBG1EmPYBkxwCtty aMEXlA1dslulgdEiv58CQqZ9l73LCnNoVJvM+GoWiTzjuke+mxHYFtGP9 XhNXx3dgatz3XF8KcQkOYhR30QdUF+6r6Uqjg7c2UER906QWr3bdQU2yJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAH1hhE+tJXG8/2dsb2JhbABEgka2ZYEHggkBAQEEEgEKUQoBEAsYCQwKDwkDAgECAUUGDQEHAQEeh2yaZ6BCiyKCD4MwBJVsjk2BaYMDgUA X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208,217";a="73533988" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 10 Apr 2012 16:39:36 +0000 Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.3) with ESMTP id q3AGdZGE004184; Tue, 10 Apr 2012 16:39:36 GMT Message-ID: <4F846247.8010309@cisco.com> Date: Tue, 10 Apr 2012 12:39:35 -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: "Miguel A. Garcia" References: <4F79A716.3080804@ericsson.com> In-Reply-To: <4F79A716.3080804@ericsson.com> Content-Type: multipart/alternative; boundary="------------050407090007050902030204" Cc: draft-ietf-mmusic-media-loopback.authors@tools.ietf.org, mmusic Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 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, 10 Apr 2012 16:39:38 -0000 This is a multi-part message in MIME format. --------------050407090007050902030204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have reviewed loopback-18 and have a couple of comments: General: - I'm missing considerations around SRTP. It needs to be described in here how that works (e.g. what do you copy for RTP packet loopback and just be clear that each side does its normaly SRTP processing on both send and receive). Specific sections: - Abstract and Introduction: Says it defines new SDP media attributes. Should also mention it defines new MIME types - 3.2, first paragraph: Change "specific media types" to "specific media descriptions" I believe the "MAY" should be a "MUST" - 4.1, first paragraph Change "property media attribute" to "value media attribute" and add reference to [RFC4566] - 4.2, first paragraph Change "value media attribute" to "property media attribute" and add reference to [RFC4566] - 5.1, third paragraph Instead of "terminate the session", we should rather just talk about "reject the offer". - 5.2, first paragraph add "and hence MUST NOT be used" to the end. - 5.2 The first two examples use RFC 2119 language ("MUST") whereas the last one does not. Given these are examples, I think they should all use lower-case "must" -6, third paragraph rtp-media-loopback gets congestion considerations, whereas rtp-pkt-loopback in the the preceding paragraph does not. I believe it applies equally well to both. - 7, second paragraph Overall, I find this paragraph difficult to follow - it would be helpful to rephrase and/or elaborate. To keep the implementation of loopback-mirrors simple it is mandated that no payload format other than encapsulated or direct loopback formats can be used in the packets generated by a loopback-mirror. As described in RFC 3550 [RFC3550], sequence numbers and timestamps in the RTP header are generated with initial random values for security reasons. If this were not mandated and the source payload is sequence number aware, the loopback-mirror will be required to understand that payload format to generate looped back packets that do not violate RFC 3550 [RFC3550]. Requiring looped back packets to be in one of the two formats means loopback-mirror does not have to look into the actual payload received before generating the loopback packets. Some specific questions: a) If this is only an issue for the loopback-mirror, then why do we need to mandate it ? If it affects the source, then we need to elaborate on this in the O/A section, since it presumably imposes restrictions on the answerer operation (that were not called out there). Also, if we keep it as "mandated", then we need to use RFC 2119 language instead. b) What does "this" refer to in the third sentence. The immediately preceding sentence, or the one before it ? c) The paragraph does not seem to account for the "media loopback" case. This is probably because it is the payload format section where media loopback is not defined and hence it's not intended to. It's confusing as it reads though. - 11, second paragraph s/recommended/RECOMMENDED - 11, third paragraph The "infinite looping" attack seems to suggest there should be some form of rate limiting at the mirror (would be helpful at the source as well of course) - 13.2 Change from MIME to Media Type registration of RTP payload formats per RFC 4855. Text in registrations need to be updated accordingly (s/MIME/media type/). I have a few additional nit fixes which I will forward directly to the authors. Thanks -- Flemming On 4/2/12 9:18 AM, Miguel A. Garcia wrote: > This is to start a 2-week Working Group Last Call for > > draft-ietf-mmusic-media-loopback-18.txt > > The WGLC ends on April 16th, 2012. > > Please reply to this e-mail to send comments, so that the authors and > the mailing list are all copied. > > /Miguel > --------------050407090007050902030204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed loopback-18 and have a couple of comments:


General:
- I'm missing considerations around SRTP. It needs to be described in here how that works (e.g. what do you copy for RTP packet loopback and just be clear that each side does its normaly SRTP processing on both send and receive).


Specific sections:
- Abstract and Introduction: Says it defines new SDP media attributes. Should also mention it defines new MIME types

- 3.2, first paragraph:
Change "specific media types" to "specific media descriptions"
I believe the "MAY" should be a "MUST"

- 4.1, first paragraph
Change "property media attribute" to "value media attribute" and add reference to [RFC4566]

- 4.2, first paragraph
Change "value media attribute" to "property media attribute" and add reference to [RFC4566]

- 5.1, third paragraph
Instead of "terminate the session", we should rather just talk about "reject the offer".

- 5.2, first paragraph
add "and hence MUST NOT be used" to the end.

- 5.2
The first two examples use RFC 2119 language ("MUST") whereas the last one does not. Given these are examples, I think they should all use lower-case "must"

-6, third paragraph
rtp-media-loopback gets congestion considerations, whereas rtp-pkt-loopback in the the preceding paragraph does not. I believe it applies equally well to both.

- 7, second paragraph
Overall, I find this paragraph difficult to follow - it would be helpful to rephrase and/or elaborate.
<quote>
To keep the implementation of loopback-mirrors simple it is
    mandated that no payload format other than encapsulated or direct
    loopback formats can be used in the packets generated by a
    loopback-mirror. As described in RFC 3550 [RFC3550], sequence
    numbers and timestamps in the RTP header are generated with initial
    random values for security reasons. If this were not mandated and
    the source payload is sequence number aware, the loopback-mirror
    will be required to understand that payload format to generate
    looped back packets that do not violate RFC 3550 [RFC3550].
    Requiring looped back packets to be in one of the two formats means
    loopback-mirror does not have to look into the actual payload
    received before generating the loopback packets.
</quote>
Some specific questions:
a) If this is only an issue for the loopback-mirror, then why do we need to mandate it ? If it affects the source, then we need to elaborate on this in the O/A section, since it presumably imposes restrictions on the answerer operation (that were not called out there). Also, if we keep it as "mandated", then we need to use RFC 2119 language instead.

b) What does "this" refer to in the third sentence. The immediately preceding sentence, or the one before it ?

c) The paragraph does not seem to account for the "media loopback" case. This is probably because it is the payload format section where media loopback is not defined and hence it's not intended to. It's confusing as it reads though.


- 11, second paragraph
s/recommended/RECOMMENDED

- 11, third paragraph
The "infinite looping" attack seems to suggest there should be some form of rate limiting at the mirror (would be helpful at the source as well of course)

- 13.2
Change from MIME to Media Type registration of RTP payload formats per RFC 4855.  Text in registrations need to be updated accordingly (s/MIME/media type/).


I have a few additional nit fixes which I will forward directly to the authors.

Thanks

-- Flemming






On 4/2/12 9:18 AM, Miguel A. Garcia wrote:
This is to start a 2-week Working Group Last Call for

       draft-ietf-mmusic-media-loopback-18.txt

The WGLC ends on April 16th, 2012.

Please reply to this e-mail to send comments, so that the authors and the mailing list are all copied.

/Miguel

--------------050407090007050902030204-- From prvs=3447c7ef00=aallen@rim.com Tue Apr 10 12:15:45 2012 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 E950C11E8117 for ; Tue, 10 Apr 2012 12:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 ntL-tWCd4x8u for ; Tue, 10 Apr 2012 12:15:45 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3468A11E810C for ; Tue, 10 Apr 2012 12:15:45 -0700 (PDT) X-AuditID: 0a412830-b7f726d000002d4e-e6-4f8486df87a9 Received: from XCT103CNC.rim.net (xct103cnc.rim.net [10.65.161.203]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 83.F7.11598.FD6848F4; Tue, 10 Apr 2012 19:15:44 +0000 (GMT) Received: from XCT101ADS.rim.net (10.67.111.42) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 10 Apr 2012 15:15:19 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.01.0339.001; Tue, 10 Apr 2012 14:15:18 -0500 From: Andrew Allen To: "mmusic@ietf.org" Thread-Topic: Issue in draft-ietf-mmusic-sdp-cs Thread-Index: Ac0XTkQL53Q0Ca5YS+W77ZFiesz0Vw== Date: Tue, 10 Apr 2012 19:15:18 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsXC5bjwtO6DthZ/g4ZGboupyx+zODB6LFny kymAMaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScx Mze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb7 61pYmFrqGirZ6SZ08mScudjGWLCbteLv00PMDYxLWboYOTkkBEwkzh94xQphi0lcuLeerYuR i0NIoI9J4s3KN6wQzgpGieNLpkFltjBK9H/awgbSwiagLLH89wxGEFtEQF3i694eZhBbWEBL YvuSR6wQcX2J5ttPgWwOIFtP4m0zN4jJIqAqMe0QWCevgJvE9L2/wDoZBWQldp+9zgRiMwuI S9x6Mp8J4jgBiSV7zjND2KISLx//gzpaUWLZiZNsEPV6EjemToGytSWWLXzNDDFfUOLkzCdg DwsJSEvsOLmGcQKj6CwkK2YhaZ+FpH0WkvYFjCyrGAVzM4oNzAyT85L1ijJz9fJSSzYxgmNf w2AH44S9WocYBTgYlXh4Oepb/IVYE8uKK3MPMUpwMCuJ8J7KAwrxpiRWVqUW5ccXleakFh9i tAAGxERmKe7kfGBayiuJNzYwQOEoifPG3q71FxJIB6aY7NTUgtQimFYmDk6Q0VxSIsXARJFa lFhakhEPSmfxxcCEJtXAqP5Pg+GwbdXKe6v1Nv+1W7zij4u+ybOjv/IPT9x36dv/S5IN+xsX y4YstFy559jbqdw1OyXijk25ovC00OVlbFDcaTeBxMAuxoL+oLR3BwJbZx7zlWfP5ufzWhss eLmqLalA6/Hsqn8Od/QS5H5vfbxsolTx3N7DGwKWO+z3lPliJMk+q3XhSiWW4oxEQy3mouJE ACnmjGsxAwAA Subject: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs 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, 10 Apr 2012 19:15:46 -0000 In 5.2.1 of the draft it shows: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 c=3D PSTN - - =A0 as a valid syntax however in section 5.6.1 it states: The endpoint MUST set the in the "c=3D" line to "PSTN", and the to "E164".=A0 Offline discussions with the authors indicates that they believe this is a bug in 5.6.1, and that the text should say that if the endpoint is not aware= of its E.164 number, both the and should be= set to "-". It is proposed that a change is made to paragraph in 5.6.1 to clearly separate the cases when the endpoint is aware of its E.164 number an= d when it is not. Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From miguel.a.garcia@ericsson.com Tue Apr 10 23:21:20 2012 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 072A921F86C1 for ; Tue, 10 Apr 2012 23:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 h8rVDrTNHBH1 for ; Tue, 10 Apr 2012 23:21:18 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4A85C21F86C3 for ; Tue, 10 Apr 2012 23:21:17 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-4f-4f8522dcb758 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5F.C3.03534.CD2258F4; Wed, 11 Apr 2012 08:21:16 +0200 (CEST) Received: from [159.107.105.88] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Wed, 11 Apr 2012 08:21:16 +0200 Message-ID: <4F8522DB.1030102@ericsson.com> Date: Wed, 11 Apr 2012 08:21:15 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Andrew Allen References: 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" Subject: Re: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs 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, 11 Apr 2012 06:21:20 -0000 As an author, I acknowledge that the draft should be clear, and somehow, contradicts itself. What the draft tries to say is what Andrew just pointed out: if the endpoint is not aware of its E.164 address, but just that there is a Circuit-Switched connection, then the c line should be: c=PSTN - - /Miguel On 10/04/2012 21:15, Andrew Allen wrote: > > In 5.2.1 of the draft it shows: > > c= PSTN - - > > as a valid syntax however in section 5.6.1 it states: > > The endpoint MUST set the in the "c=" line to "PSTN", and the to "E164". > > Offline discussions with the authors indicates that they believe this is a > bug in 5.6.1, and that the text should say that if the endpoint is not aware of its E.164 number, both the and should be set to "-". > > It is proposed that a change is made to paragraph in 5.6.1 to > clearly separate the cases when the endpoint is aware of its E.164 number and when it is not. > > Andrew > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From zhou.sujing@zte.com.cn Wed Apr 11 22:53:24 2012 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 6708121F859E; Wed, 11 Apr 2012 22:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.438 X-Spam-Level: X-Spam-Status: No, score=-96.438 tagged_above=-999 required=5 tests=[AWL=3.647, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 Q2bmvFEsLf3W; Wed, 11 Apr 2012 22:53:23 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 22F2821F859A; Wed, 11 Apr 2012 22:53:21 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201201904546; Thu, 12 Apr 2012 13:14:46 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 21215.1230242606; Thu, 12 Apr 2012 13:53:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3C5r6lE010501; Thu, 12 Apr 2012 13:53:06 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <4F8522DB.1030102@ericsson.com> To: "Miguel A. Garcia" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 12 Apr 2012 13:52:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-12 13:53:08, Serialize complete at 2012-04-12 13:53:08 Content-Type: multipart/alternative; boundary="=_alternative 00205A20482579DE_=" X-MAIL: mse02.zte.com.cn q3C5r6lE010501 Cc: "mmusic@ietf.org" , mmusic-bounces@ietf.org Subject: [MMUSIC] on draft-zhou-mmusic-sdes-keymod 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, 12 Apr 2012 05:53:24 -0000 This is a multipart message in MIME format. --=_alternative 00205A20482579DE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrE1pZ3VlbA0KICAgSSBnYXZlIGEgcHJlc2VudGF0aW9uIG9uIG15IGRyYWZ0ICIgZHJhZnQt emhvdS1tbXVzaWMtc2Rlcy1rZXltb2QiIGJ1dCANCmdvdCBubyByZXNwb25zZSBpbiB0aGUgbWFp bGluZyBsaXN0Lg0KQnV0IGFjY29yZGluZyB0byB0aGUgcGFyYWdyYXBoIGluIDNncHAncyBUUiB3 aXRoIHJlc3BlY3QgdG8gdGhlIGFib3ZlIA0KZHJhZnSjug0KDQpodHRwOi8vd3d3LjNncHAub3Jn L2Z0cC9TcGVjcy9odG1sLWluZm8vMzM4MjkuaHRtDQowLjAuMTAgdmVyc2lvbiAgIDkuMy4xLjMg U0RFUyBzb2x1dGlvbiAyIA0KSXQgaXMgcmVxdWlyZWQgdGhhdCChsEVkaXRvcqGvcyBOb3RlOiBG dXJ0aGVyIHdvcmsgaW4gSUVURiB3aWxsIGJlIA0KcmVxdWlyZWQgYmVmb3JlIHRoaXMgY29tZXMg dG8gdGhlIG5vcm1hdGl2ZSB0ZXh0LqGxDQoNCkkgd29uZGVyIHdoYXQgY2FuIEmhoWRvID8gDQog DQoNClJlZ2FyZHMsDQpTdWppbmcgDQo= --=_alternative 00205A20482579DE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaaOsTWlndWVsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mbmJzcDsgJm5ic3A7SSBnYXZlIGEgcHJlc2VudGF0aW9uIG9uIG15IGRyYWZ0 ICZxdW90Ow0KZHJhZnQtemhvdS1tbXVzaWMtc2Rlcy1rZXltb2QmcXVvdDsgYnV0IGdvdCBubyBy ZXNwb25zZSBpbiB0aGUgbWFpbGluZw0KbGlzdC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPkJ1dCBhY2NvcmRpbmcgdG8gdGhlIHBhcmFncmFwaCBpbiAzZ3BwJ3MgVFIgd2l0aCBy ZXNwZWN0DQp0byB0aGUgYWJvdmUgZHJhZnSjujwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+aHR0cDovL3d3dy4zZ3BwLm9yZy9mdHAvU3BlY3MvaHRtbC1pbmZvLzMzODI5 Lmh0bTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+MC4wLjEwIHZlcnNpb24gJm5i c3A7IDkuMy4xLjMgU0RFUyBzb2x1dGlvbiAyIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+SXQgaXMgcmVxdWlyZWQgdGhhdCChsEVkaXRvcqGvcyBOb3RlOiBGdXJ0aGVyIHdvcmsN CmluIElFVEYgd2lsbCBiZSByZXF1aXJlZCBiZWZvcmUgdGhpcyBjb21lcyB0byB0aGUgbm9ybWF0 aXZlIHRleHQuobE8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgd29u ZGVyIHdoYXQgY2FuIEmhoWRvID8gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlJlZ2FyZHMsPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5TdWppbmcgPC9mb250PjwvdHQ+DQo= --=_alternative 00205A20482579DE_=-- From wwwrun@rfc-editor.org Thu Apr 12 09:07:11 2012 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 7BCAA21F856C for ; Thu, 12 Apr 2012 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 pFYz8BLsyLo3 for ; Thu, 12 Apr 2012 09:07:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C070021F852C for ; Thu, 12 Apr 2012 09:07:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2C189B1E002; Thu, 12 Apr 2012 09:06:31 -0700 (PDT) To: miguel.a.garcia@ericsson.com, markus.isomaki@nokia.com, Gonzalo.Camarillo@ericsson.com, Salvatore.Loreto@ericsson.com, pkyzivat@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, fandreas@cisco.com, miguel.a.garcia@ericsson.com From: RFC Errata System Message-Id: <20120412160631.2C189B1E002@rfc-editor.org> Date: Thu, 12 Apr 2012 09:06:31 -0700 (PDT) Cc: rfc-editor@rfc-editor.org, bruno.chatras@orange.com, mmusic@ietf.org Subject: [MMUSIC] [Technical Errata Reported] RFC5547 (3190) 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, 12 Apr 2012 16:07:11 -0000 The following errata report has been submitted for RFC5547, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5547&eid=3190 -------------------------------------- Type: Technical Reported by: Bruno CHATRAS Section: GLOBAL Original Text ------------- Section 9.1., paragraph 7: OLD: --boundary71 Content-Type: application/sdp Content-Length: [length of SDP] NEW: --boundary71 Content-Type: application/sdp Section 9.1., paragraph 9: OLD: --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Length: [length of image] Content-Disposition: icon NEW: --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Disposition: icon Section 9.2., paragraph 24: OLD: --boundary71 Content-Type: application/sdp Content-Length: [length of SDP] NEW: --boundary71 Content-Type: application/sdp Section 9.2., paragraph 26: OLD: --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Length: [length of image] Content-Disposition: icon NEW: --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Disposition: icon Corrected Text -------------- Notes ----- A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored. This was discussed on both the SIP Implementors and SIP Core mailing lists. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5547 (draft-ietf-mmusic-file-transfer-mech-11) -------------------------------------- Title : A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer Publication Date : May 2009 Author(s) : M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From magnus.westerlund@ericsson.com Fri Apr 13 05:22:07 2012 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 F39A921F8494 for ; Fri, 13 Apr 2012 05:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.192 X-Spam-Level: X-Spam-Status: No, score=-106.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 cpb2N33PBPix for ; Fri, 13 Apr 2012 05:22:06 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D21ED21F8496 for ; Fri, 13 Apr 2012 05:22:05 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-2d-4f881a6cb675 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D8.FC.03534.C6A188F4; Fri, 13 Apr 2012 14:22:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012 14:22:04 +0200 Message-ID: <4F881A6B.7080308@ericsson.com> Date: Fri, 13 Apr 2012 14:22:03 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4F79A716.3080804@ericsson.com> In-Reply-To: <4F79A716.3080804@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" , Flemming Andreasen , mmusic Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 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, 13 Apr 2012 12:22:07 -0000 Hi, I have reviewed the version in WGLC. I have some few comments: 1. Section 5.5: "Note that for any form of NAT traversal to function, symmetric RTP/RTCP MUST be used." Any reason to no reference RFC 4961 here? 2. Section 7.1.1 to 7.1.3 and 7.2.1 to 7.2.3 all are missing a space between the section number and the section title. 3. Section 6: A loopback mirror that is compliant to this specification and accepts media with rtp-pkt-loopback loopback-type MUST loopback the incoming RTP packets using either the encapsulated RTP payload format or the direct loopback RTP payload format as defined in section 7 of this specification. I don't think this has addressed my previous WG last call comment about that the MUST needs an escape clause or at least a pointer to the issue of congestion control. Because if you have no escape clause then the loopback source MUST perform congestion control not only on the path from the source to the mirror, but also on the mirror to the source. 4. Section 7.1.2: The outer RTP header of the encapsulating packet MUST be followed by the payload header defined in this section. If the received RTP packet has to be looped back in multiple encapsulating packets due to fragmentation, the encapsulating RTP header in each packet MUST be followed by the payload header defined in this section. I think this is are unfortunate formulations as it actually defines that RTP header extensions and CSRC lists are not allowed. Especially header extensions should not be disallowed. I would suggest a formulation saying: The RTP payload of the encapsulating RTP packet starts with the payload header defined in this section. And go on and define the payload structure in relation to the start of the payload. 5. Section 7.1.2: The Receive timestamp MUST be based on the same clock used by the loopback-source. I still think this formulation is extremely wrong. One alternative is the same clocks source, like if they where using the same NTP server. Or is it actually "clock rate" that is intended here? Se my previous comment 28 for more input about this: http://www.ietf.org/mail-archive/web/mmusic/current/msg08971.html 6. I can't locate any answer to my issue number 30: 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. Can you please summarize any discussion that has happened? 7. I also don't see any changes related to my comment 34: "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." This is coupled to issue 3 above. If that above MUST stands you absolutely have to have more detailed discussion about dealing with the whole loop, rather than a single leg that is the norm. 8. Section 11. The amplification or reflection this allows has at least been sufficiently discussed. I am far from certain that the mitigation is clear enough. I do support Flemming's comment about the SRTP implications of using loopback are. 9. Another not addressed issue: 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. 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 vnagarjuna@saperix.com Fri Apr 13 05:39:31 2012 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 17FE121F861D for ; Fri, 13 Apr 2012 05:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 bKbUluvze0JQ for ; Fri, 13 Apr 2012 05:39:30 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84AFF21F861B for ; Fri, 13 Apr 2012 05:39:30 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1758713yhk.31 for ; Fri, 13 Apr 2012 05:39:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6BKfLCdQ30YTR6x20klGhTy49rex9Eggsqvz4kXnstw=; b=ffq48oLVEUUjmmm3ZeWNAAjmfiS/ppuJcJFYFzRhcBYvSOkp5gED+Qz81UtYGmdIwm fNk74dq2UPGDecaib0cc+GvFlGphzYAfoCQYGeF5Blv4TOakfRmEYhkR/5aRNf2iIrr6 iC2dfM58n3a4bL9416u56rGnI6+b1rfCuWnnN5Dk8E8LKDpN+ODpjkLnNjFvaJzjylPr mMnPlG2bCj5ZWG88tyJGb/37Y+cXjg88t6IPX2Raj5iSYyrMIieHdNXactz/uKRzObGW uBFSeYDBNqXgbFgLUDuYZ10nx6wpNnhmWbZNFJ/gU08QlXL0vDVBgz7tlmWPs26EhnqH 55NA== MIME-Version: 1.0 Received: by 10.236.193.1 with SMTP id j1mr1450064yhn.40.1334320769955; Fri, 13 Apr 2012 05:39:29 -0700 (PDT) Received: by 10.146.46.41 with HTTP; Fri, 13 Apr 2012 05:39:29 -0700 (PDT) In-Reply-To: <4F881A6B.7080308@ericsson.com> References: <4F79A716.3080804@ericsson.com> <4F881A6B.7080308@ericsson.com> Date: Fri, 13 Apr 2012 08:39:29 -0400 Message-ID: From: Nagarjuna Venna To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf3056397d82769e04bd8ec33c X-Gm-Message-State: ALoCoQmOQla7Z5F0VN73sqLTeE798zdlzwQrz95HvAuxObST5Utop5cRXfj7zk2Rx8chH3BGt/GZ X-Mailman-Approved-At: Fri, 13 Apr 2012 08:06:16 -0700 Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" , Flemming Andreasen , mmusic Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 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, 13 Apr 2012 12:40:29 -0000 --20cf3056397d82769e04bd8ec33c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 8:22 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > > 5. Section 7.1.2: > The > Receive timestamp MUST be based on the same clock used by the > loopback-source. > > I still think this formulation is extremely wrong. One alternative is > the same clocks source, like if they where using the same NTP server. Or > is it actually "clock rate" that is intended here? > > Se my previous comment 28 for more input about this: > http://www.ietf.org/mail-archive/web/mmusic/current/msg08971.html > > Magnus, This was intended to be "clock rate" not clock. Regards, nagarjuna --20cf3056397d82769e04bd8ec33c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 13, 2012 at 8:22 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wrote:

5. Section 7.1.2:
=A0 =A0The
=A0 =A0Receive timestamp MUST be based on the same clock used by the
=A0 =A0loopback-source.

I still think this formulation is extremely wrong. One alternative is
the same clocks source, like if they where using the same NTP server. Or is it actually "clock rate" that is intended here?

Se my previous comment 28 for more input about this:
http://www.ietf.org/mail-archive/web/mmusic/current/ms= g08971.html


Magnus,

This = was intended to be "clock rate" not clock.

Regards,
nagarjuna=A0
--20cf3056397d82769e04bd8ec33c-- From thomas.belling@nsn.com Fri Apr 13 08:06:49 2012 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 976C321F86D9 for ; Fri, 13 Apr 2012 08:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 zrTorygRHUL9 for ; Fri, 13 Apr 2012 08:06:47 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 28A1F21F876E for ; Fri, 13 Apr 2012 08:06:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q3DF6ilS017929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Apr 2012 17:06:44 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3DF6fKf003392; Fri, 13 Apr 2012 17:06:43 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Apr 2012 17:05:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2012 17:05:23 +0200 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F01413FCB@DEMUEXC014.nsn-intra.net> In-Reply-To: <4F8522DB.1030102@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs Thread-Index: Ac0Xq0MWPw6Y1OgLQFiUTm3rWIMM6wB207HA References: <4F8522DB.1030102@ericsson.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Miguel A. Garcia" , "Andrew Allen" X-OriginalArrivalTime: 13 Apr 2012 15:05:24.0320 (UTC) FILETIME=[DA592600:01CD1986] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2534 X-purgate-ID: 151667::1334329604-00003570-582B4CB8/0-0/0-0 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs 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, 13 Apr 2012 15:06:49 -0000 Dear Miguel, Might be a matter of taste and can certainly be overcome with clear descriptive text, but: For me a dash instead of E.164 somehow sounds like the host not even knowing its addresstype. Thomas -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Miguel A. Garcia Sent: Wednesday, April 11, 2012 8:21 AM To: Andrew Allen Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs As an author, I acknowledge that the draft should be clear, and somehow, contradicts itself. What the draft tries to say is what Andrew just pointed out: if the endpoint is not aware of its E.164 address, but just that there is a Circuit-Switched connection, then the c line should be: c=3DPSTN - - /Miguel On 10/04/2012 21:15, Andrew Allen wrote: > > In 5.2.1 of the draft it shows: > > c=3D PSTN - - > > as a valid syntax however in section 5.6.1 it states: > > The endpoint MUST set the in the "c=3D" line to "PSTN", and the to "E164". > > Offline discussions with the authors indicates that they believe this=20 > is a bug in 5.6.1, and that the text should say that if the endpoint is not aware of its E.164 number, both the and should be set to "-". > > It is proposed that a change is made to paragraph in 5.6.1 to=20 > clearly separate the cases when the endpoint is aware of its E.164 number and when it is not. > > Andrew > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From prvs=64501c9095=aallen@rim.com Fri Apr 13 11:17:58 2012 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 8DD0D21F85E4 for ; Fri, 13 Apr 2012 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.252 X-Spam-Level: X-Spam-Status: No, score=-5.252 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396, 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 xZe7Dziq5mqC for ; Fri, 13 Apr 2012 11:17:57 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5B57A21F85D1 for ; Fri, 13 Apr 2012 11:17:43 -0700 (PDT) X-AuditID: 0a412830-b7f436d000000c01-ef-4f886dc65d15 Received: from XCT105CNC.rim.net (xct105cnc.rim.net [10.65.161.205]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 04.FB.03073.6CD688F4; Fri, 13 Apr 2012 18:17:42 +0000 (GMT) Received: from XCT104ADS.rim.net (10.67.111.45) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 13 Apr 2012 14:17:41 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.01.0339.001; Fri, 13 Apr 2012 13:17:41 -0500 From: Andrew Allen To: "Belling, Thomas (NSN - DE/Munich)" , "ext Miguel A. Garcia" Thread-Topic: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs Thread-Index: Ac0XTkQL53Q0Ca5YS+W77ZFiesz0VwAhvEOAAHbjU4AAA+zD8A== Date: Fri, 13 Apr 2012 18:17:40 +0000 Message-ID: References: <4F8522DB.1030102@ericsson.com> <1A8A7D59006A8240B27FF63C794CA57F01413FCB@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F01413FCB@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsXC5bjwrO6x3A5/g4N3FS3WfFrBbjF1+WMW i7Zd+xgdmD1+fb3K5rFkyU8mj5/rr7IHMEc1MNokJZaUBWem5+nb2STm5eWXJJakKqSkFifb KvmkpifmKAQUZZYlJlcquGQWJ+ckZuamFikpZKbYKpkoKRTkJCan5qbmldgqJRYUpOalKNlx KWAAG6CyzDyF1Lzk/JTMvHRbJc9gf10LC1NLXUMlO92ETp6MR+evsxXckar40LKKpYFxp2gX IyeHhICJxKWJ+5kgbDGJC/fWs3UxcnEICfQxSczp+sUM4axglLj0+xwLhLOFUeLXpjNgLWwC yhLLf89gBLFFBColXn+aB9TBwcEsoC5xdXEQSFhYwFzi46xzrBAlFhKre59ClTtJfHs0Bcxm EVCV2DJxFTOIzSvgJrHtw0tWiF3rGCXOXdrDBjKTUyBA4thpcZAaRqBLv59aA3YCs4C4xK0n 86E+EJBYsuc8M4QtKvHy8T9WCFtRYtmJk2wQ9ToSC3Z/grK1JZYtfA21V1Di5MwnLCC2kIC0 xI6TaxgnMErMQrJiFpL2WUjaZyFpX8DIsopRMDej2MDMMDkvWa8oM1cvL7VkEyM42WgY7GCc sFfrEKMAB6MSD++0tA5/IdbEsuLK3EOMEhzMSiK84dFAId6UxMqq1KL8+KLSnNTiQ4wWwBCa yCzFnZwPTIR5JfHGBgYoHCVx3tjbtf5CAunAZJWdmlqQWgTTysTBCTKaS0qkGJhyUosSS0sy 4kGJMb4YmBqlGhhzV3BO/mDo8ET3VvuxM3J/ly1N7EyZvWfzbIlH/O6GT6/e3rR13yeuPt7f VxqkVTPX3D99omblQtuT1U7thqx/DMR0S3K0ln3PbL7wmZvbZUvqmiOHt3ucFfh59JTk//I9 X3vVO/ZdOOjtPOPeXpYbky1u/M8XEmvvN9ybzGt/c82e+aGXDif/UGIpzkg01GIuKk4EAHrX yhFqAwAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs 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, 13 Apr 2012 18:17:58 -0000 Thomas That's certainly one way you can look at it. However I think the approach the authors have taken is that the address type= is the type of the connectionaddress value that follows. Since the connecti= onaddress has no value ("-") putting the value E164 in the address type is p= ointless. Having "PSTN - -" syntax is consistent with the current 3GPP documentation t= oo so I would prefer to keep it that way. Andrew > -----Original Message----- > From: Belling, Thomas (NSN - DE/Munich) [mailto:thomas.belling@nsn.com] > Sent: Friday, April 13, 2012 10:05 AM > To: ext Miguel A. Garcia; Andrew Allen > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs > > Dear Miguel, > > Might be a matter of taste and can certainly be overcome with clear > descriptive text, but: > > For me a dash instead of E.164 somehow sounds like the host not even > knowing its addresstype. > > Thomas > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of ext Miguel A. Garcia > Sent: Wednesday, April 11, 2012 8:21 AM > To: Andrew Allen > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs > > As an author, > > I acknowledge that the draft should be clear, and somehow, contradicts > itself. What the draft tries to say is what Andrew just pointed out: if > the endpoint is not aware of its E.164 address, but just that there is a > Circuit-Switched connection, then the c line should be: > > c=3DPSTN - - > > /Miguel > > > On 10/04/2012 21:15, Andrew Allen wrote: > > > > In 5.2.1 of the draft it shows: > > > > c=3D PSTN - - > > > > as a valid syntax however in section 5.6.1 it states: > > > > The endpoint MUST set the in the "c=3D" line to "PSTN", and > the to "E164". > > > > Offline discussions with the authors indicates that they believe this > > is a bug in 5.6.1, and that the text should say that if the endpoint > is not aware of its E.164 number, both the > and should be set to "-". > > > > It is proposed that a change is made to paragraph in 5.6.1 to > > clearly separate the cases when the endpoint is aware of its E.164 > number and when it is not. > > > > Andrew > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From HKaplan@acmepacket.com Sat Apr 14 04:52:41 2012 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 EBA6021F8611 for ; Sat, 14 Apr 2012 04:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 oknkc09MgXqZ for ; Sat, 14 Apr 2012 04:52:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B7FE221F8577 for ; Sat, 14 Apr 2012 04:52:40 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 14 Apr 2012 07:52:38 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.74]) by Mail1.acmepacket.com ([169.254.1.36]) with mapi id 14.02.0283.003; Sat, 14 Apr 2012 07:52:38 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 Thread-Index: AQHNGjUWP4kcEnXmc0mBcW0k/og3iw== Date: Sat, 14 Apr 2012 11:52:38 +0000 Message-ID: References: <4F79A716.3080804@ericsson.com> <4F881A6B.7080308@ericsson.com> In-Reply-To: <4F881A6B.7080308@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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" , Flemming Andreasen , mmusic Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 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, 14 Apr 2012 11:52:42 -0000 Hey Magnus, inline... On Apr 13, 2012, at 8:22 AM, Magnus Westerlund wrote: > Hi, >=20 > I have reviewed the version in WGLC. I have some few comments: >=20 > 1. Section 5.5: > "Note that for any form of NAT traversal to function, symmetric > RTP/RTCP MUST be used." >=20 > Any reason to no reference RFC 4961 here? Will do. >=20 > 2. Section 7.1.1 to 7.1.3 and 7.2.1 to 7.2.3 all are missing a space > between the section number and the section title. Ya the formatting got screwed up by the generic text printing of the MS Wor= d doc. >=20 > 3. Section 6: > A loopback mirror that is compliant to this specification and > accepts media with rtp-pkt-loopback loopback-type MUST loopback the > incoming RTP packets using either the encapsulated RTP payload > format or the direct loopback RTP payload format as defined in > section 7 of this specification. >=20 > I don't think this has addressed my previous WG last call comment about > that the MUST needs an escape clause or at least a pointer to the issue > of congestion control. Because if you have no escape clause then the > loopback source MUST perform congestion control not only on the path > from the source to the mirror, but also on the mirror to the source. OK. >=20 > 4. Section 7.1.2: > The outer RTP header of the encapsulating packet MUST be followed > by the payload header defined in this section. If the received RTP > packet has to be looped back in multiple encapsulating packets due > to fragmentation, the encapsulating RTP header in each packet MUST > be followed by the payload header defined in this section. >=20 > I think this is are unfortunate formulations as it actually defines that > RTP header extensions and CSRC lists are not allowed. Especially header > extensions should not be disallowed. I would suggest a formulation saying= : >=20 > The RTP payload of the encapsulating RTP packet starts with the payload > header defined in this section. >=20 > And go on and define the payload structure in relation to the start of > the payload. Ah sorry I thought I cleaned up that wording to make it clear. I'll fix th= at. >=20 > 5. Section 7.1.2: > The > Receive timestamp MUST be based on the same clock used by the > loopback-source. >=20 > I still think this formulation is extremely wrong. One alternative is > the same clocks source, like if they where using the same NTP server. Or > is it actually "clock rate" that is intended here? >=20 > Se my previous comment 28 for more input about this: > http://www.ietf.org/mail-archive/web/mmusic/current/msg08971.html Sorry I meant clock rate - will change. >=20 >=20 > 6. I can't locate any answer to my issue number 30: >=20 > 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. >=20 > 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. >=20 > Can you please summarize any discussion that has happened? Actually there has been no discussion on this topic as far as I know - it w= as not a SHOULD to allow copying, it's a SHOULD because it's a SHOULD in RF= C 3550. If you'd prefer, I can just say MUST follow RFC 3550. >=20 > 7. I also don't see any changes related to my comment 34: >=20 > "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." >=20 > This is coupled to issue 3 above. If that above MUST stands you > absolutely have to have more detailed discussion about dealing with the > whole loop, rather than a single leg that is the norm. OK we should start a thread on this. >=20 > 8. Section 11. >=20 > The amplification or reflection this allows has at least been > sufficiently discussed. I am far from certain that the mitigation is > clear enough. >=20 > I do support Flemming's comment about the SRTP implications of using > loopback are. Yup. >=20 > 9. Another not addressed issue: >=20 > 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. OK. From HKaplan@acmepacket.com Sat Apr 14 04:59:11 2012 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 2670021F852D for ; Sat, 14 Apr 2012 04:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 GR70Ekv+MmBp for ; Sat, 14 Apr 2012 04:59:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6590721F8460 for ; Sat, 14 Apr 2012 04:59:10 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 14 Apr 2012 07:59:09 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.74]) by Mail1.acmepacket.com ([169.254.1.36]) with mapi id 14.02.0283.003; Sat, 14 Apr 2012 07:59:09 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: media-loopback congestion Thread-Index: AQHNGjX/e/vqQ+bNIE6DOhiiL5p/Kg== Date: Sat, 14 Apr 2012 11:59:08 +0000 Message-ID: <1DB4397F-D929-49FD-9462-095DF9196172@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" Subject: [MMUSIC] media-loopback congestion 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, 14 Apr 2012 11:59:11 -0000 Magnus has raised a comment/concern as follows: Currently section 6 says this: A loopback mirror that is compliant to this specification and accepts media with rtp-pkt-loopback loopback-type MUST loopback the incoming RTP packets using either the encapsulated RTP payload format or the direct loopback RTP payload format as defined in section 7 of this specification. And section 9 about Congestion Control says this: All the participants in a loopback session SHOULD implement congestion control mechanisms as defined by the RTP profile under which the loopback mechanism is implemented. For audio video profiles, implementations SHOULD conform to the mechanism defined in Section 2 of RFC 3551. Magnus' comment is this: This section [9] 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. From HKaplan@acmepacket.com Sat Apr 14 05:09:47 2012 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 C1D1A21F8618 for ; Sat, 14 Apr 2012 05:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 NvoEa3abqzZP for ; Sat, 14 Apr 2012 05:09:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 16BC121F84DC for ; Sat, 14 Apr 2012 05:09:46 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 14 Apr 2012 08:09:43 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.74]) by Mail1.acmepacket.com ([169.254.1.36]) with mapi id 14.02.0283.003; Sat, 14 Apr 2012 08:09:43 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" , Magnus Westerlund Thread-Topic: [MMUSIC] media-loopback congestion Thread-Index: AQHNGjd5gMcui0APZUKSxLAlR+27PQ== Date: Sat, 14 Apr 2012 12:09:42 +0000 Message-ID: <581DCD23-A142-4414-8662-05B84FD8AA50@acmepacket.com> References: <1DB4397F-D929-49FD-9462-095DF9196172@acmepacket.com> In-Reply-To: <1DB4397F-D929-49FD-9462-095DF9196172@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: <95F30F4D63EC394CAA9FFE028163F04E@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" Subject: Re: [MMUSIC] media-loopback congestion 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, 14 Apr 2012 12:09:47 -0000 One of Magnus concerns for below is that section 6's MUST statement does no= t have an escape clause allowing the mirror to not mirror a packet back if = it perceives congestion. I propose to put in the following at the end of t= he section 6 shown below: ..., when it can send packets back. Since congestion might be detected by = the mirror, for example, the loopback mirror might not necessarily loopback= all incoming RTP packets. Does this work for everyone for this section? There still needs to be discussion on section 9. -hadriel On Apr 14, 2012, at 7:59 AM, Hadriel Kaplan wrote: > Magnus has raised a comment/concern as follows: >=20 > Currently section 6 says this: > A loopback mirror that is compliant to this specification and > accepts media with rtp-pkt-loopback loopback-type MUST loopback the > incoming RTP packets using either the encapsulated RTP payload > format or the direct loopback RTP payload format as defined in > section 7 of this specification. From gunnar.hellstrom@omnitor.se Sat Apr 14 07:07:47 2012 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 623C321F85B9 for ; Sat, 14 Apr 2012 07:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 SLlE9BHwVhIU for ; Sat, 14 Apr 2012 07:07:46 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id E0EAC21F85AE for ; Sat, 14 Apr 2012 07:07:44 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sat, 14 Apr 2012 16:07:29 +0200 (CEST) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id CF82E3A04B; Sat, 14 Apr 2012 16:07:29 +0200 (CEST) Message-ID: <4F8984A4.7030507@omnitor.se> Date: Sat, 14 Apr 2012 16:07:32 +0200 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4F79A716.3080804@ericsson.com> In-Reply-To: <4F79A716.3080804@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mmusic-media-loopback.authors@tools.ietf.org, Flemming Andreasen , mmusic Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 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, 14 Apr 2012 14:07:47 -0000 I had concerns with the NAT traversal and keep-alive in earlier versions. I am happy with the current version when the new comments and answers during WGLC are taken into account. Good to see progress. /Gunnar Miguel A. Garcia skrev 2012-04-02 15:18: > This is to start a 2-week Working Group Last Call for > > draft-ietf-mmusic-media-loopback-18.txt > > The WGLC ends on April 16th, 2012. > > Please reply to this e-mail to send comments, so that the authors and > the mailing list are all copied. > > /Miguel > From mperumal@cisco.com Sun Apr 15 23:04:44 2012 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 244D921F869D for ; Sun, 15 Apr 2012 23:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 G4e+WUGQyiG1 for ; Sun, 15 Apr 2012 23:04:43 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id CD9D421F8678 for ; Sun, 15 Apr 2012 23:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2253; q=dns/txt; s=iport; t=1334556283; x=1335765883; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SpvMOT/dWbtM+QcTlntj4QlUrHKk4Lk/zlsJiOyUmJc=; b=nDXLqUeoKYRqRHk3ygfaCbzigH9eaiUmJOoBDeGJEez0Aui52zS/NfRe Dcj/6p1yAe5B9pqqbqrvEyTYxGnLfol+mwR4Cw5JgVwV/Lo0o3rEhm9vp c52nvYYjYVHbxCxUjXFVu6BEnTdd8f1tYNQvQ7VtNKgcxbACANf91N5Bj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAEC1i09Io8UY/2dsb2JhbABEtD2CCQEBAQQBAQEPAR0KNAsMBAIBCA4DBAEBCwYXAQYBJh8JCAIEAQoICBqHbAuYeZ5/BIs3hS9jBIhYm2GBaYJvgUwHAQ X-IronPort-AV: E=Sophos;i="4.75,426,1330905600"; d="scan'208";a="10128717" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 16 Apr 2012 06:04:39 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3G64dNK010502; Mon, 16 Apr 2012 06:04:39 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 11:34:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Apr 2012 11:34:38 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020827EB48@XMB-BGL-414.cisco.com> In-Reply-To: <581DCD23-A142-4414-8662-05B84FD8AA50@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] media-loopback congestion Thread-Index: AQHNGjd5gMcui0APZUKSxLAlR+27PZac9nUQ References: <1DB4397F-D929-49FD-9462-095DF9196172@acmepacket.com> <581DCD23-A142-4414-8662-05B84FD8AA50@acmepacket.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Hadriel Kaplan" , "mmusic (E-mail)" , "Magnus Westerlund" X-OriginalArrivalTime: 16 Apr 2012 06:04:39.0974 (UTC) FILETIME=[CF401460:01CD1B96] Cc: draft-ietf-mmusic-media-loopback.authors@tools.ietf.org Subject: Re: [MMUSIC] media-loopback congestion 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, 16 Apr 2012 06:04:44 -0000 Hadriel, |..., when it can send packets back. This looks open for interpretation since there can be other reasons apart from congestions where the mirror can't send packets back. My suggestion is to state explicitly that congestion in the only exception: A loopback mirror that is compliant to this specification and accepts media with rtp-pkt-loopback loopback-type MUST loopback the incoming RTP packets using either the encapsulated RTP payload format or the direct loopback RTP payload format as defined in section 7 of this specification, except when the loopback mirror=20 perceives congestion. When the loopback mirror perceives congestion it might not necessarily loopback all incoming RTP packets. Muthu |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Hadriel Kaplan |Sent: Saturday, April 14, 2012 5:40 PM |To: mmusic (E-mail); Magnus Westerlund |Cc: draft-ietf-mmusic-media-loopback.authors@tools.ietf.org |Subject: Re: [MMUSIC] media-loopback congestion | | |One of Magnus concerns for below is that section 6's MUST statement does not have an escape clause |allowing the mirror to not mirror a packet back if it perceives congestion. I propose to put in the |following at the end of the section 6 shown below: |..., when it can send packets back. Since congestion might be detected by the mirror, for example, |the loopback mirror might not necessarily loopback all incoming RTP packets. | |Does this work for everyone for this section? | |There still needs to be discussion on section 9. | |-hadriel | | |On Apr 14, 2012, at 7:59 AM, Hadriel Kaplan wrote: | |> Magnus has raised a comment/concern as follows: |> |> Currently section 6 says this: |> A loopback mirror that is compliant to this specification and |> accepts media with rtp-pkt-loopback loopback-type MUST loopback the |> incoming RTP packets using either the encapsulated RTP payload |> format or the direct loopback RTP payload format as defined in |> section 7 of this specification. | |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Mon Apr 16 00:44:57 2012 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 328A321F8656 for ; Mon, 16 Apr 2012 00:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 STsPLcu3Az89 for ; Mon, 16 Apr 2012 00:44:56 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0644021F8653 for ; Mon, 16 Apr 2012 00:44:55 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-36-4f8bcdf6b299 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B4.BA.26681.6FDCB8F4; Mon, 16 Apr 2012 09:44:55 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 09:44:53 +0200 Message-ID: <4F8BCDF4.6010307@ericsson.com> Date: Mon, 16 Apr 2012 09:44:52 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <4F8522DB.1030102@ericsson.com> <1A8A7D59006A8240B27FF63C794CA57F01413FCB@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F01413FCB@DEMUEXC014.nsn-intra.net> 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] Issue in draft-ietf-mmusic-sdp-cs 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, 16 Apr 2012 07:44:57 -0000 Hi Thomas: Please see below. On 13/04/2012 17:05, Belling, Thomas (NSN - DE/Munich) wrote: > Dear Miguel, > > Might be a matter of taste and can certainly be overcome with clear > descriptive text, but: > > For me a dash instead of E.164 somehow sounds like the host not even > knowing its addresstype. And certainly that is the case. The device knows it is behind a circuit switched connection. It doesn't know any address, not an E.164, or not any other addressing scheme (say, E.212). So, if it doesn't know it, let's signal it with a dash. I don't see the point in indicating that the devices knows it has an E.164 address allocated to it, when it does not really know it. /Miguel > Thomas > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of ext Miguel A. Garcia > Sent: Wednesday, April 11, 2012 8:21 AM > To: Andrew Allen > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Issue in draft-ietf-mmusic-sdp-cs > > As an author, > > I acknowledge that the draft should be clear, and somehow, contradicts > itself. What the draft tries to say is what Andrew just pointed out: if > the endpoint is not aware of its E.164 address, but just that there is a > Circuit-Switched connection, then the c line should be: > > c=PSTN - - > > /Miguel > > > On 10/04/2012 21:15, Andrew Allen wrote: >> >> In 5.2.1 of the draft it shows: >> >> c= PSTN - - >> >> as a valid syntax however in section 5.6.1 it states: >> >> The endpoint MUST set the in the "c=" line to "PSTN", and > the to "E164". >> >> Offline discussions with the authors indicates that they believe this >> is a bug in 5.6.1, and that the text should say that if the endpoint > is not aware of its E.164 number, both the > and should be set to "-". >> >> It is proposed that a change is made to paragraph in 5.6.1 to >> clearly separate the cases when the endpoint is aware of its E.164 > number and when it is not. >> >> Andrew >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > 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 Mon Apr 16 02:10:51 2012 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 69F8321F8722 for ; Mon, 16 Apr 2012 02:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 wg+11cCD7g7R for ; Mon, 16 Apr 2012 02:10:50 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61D21F8713 for ; Mon, 16 Apr 2012 02:10:50 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-a0-4f8be2194781 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 75.72.03534.912EB8F4; Mon, 16 Apr 2012 11:10:49 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 11:10:47 +0200 Message-ID: <4F8BE215.7030108@ericsson.com> Date: Mon, 16 Apr 2012 11:10:45 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: RFC Errata System References: <20120412160631.2C189B1E002@rfc-editor.org> In-Reply-To: <20120412160631.2C189B1E002@rfc-editor.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" , "pkyzivat@cisco.com" , Gonzalo Camarillo , "markus.isomaki@nokia.com" , "fandreas@cisco.com" , "bruno.chatras@orange.com" Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5547 (3190) 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, 16 Apr 2012 09:10:51 -0000 Hi: According to the discussion in SIPCORE, I agree with the reported errata. It should be moved to status "verified". Thanks to Bruno and Paul for reporting it. /Miguel On 12/04/2012 18:06, RFC Errata System wrote: > > The following errata report has been submitted for RFC5547, > "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5547&eid=3190 > > -------------------------------------- > Type: Technical > Reported by: Bruno CHATRAS > > Section: GLOBAL > > Original Text > ------------- > Section 9.1., paragraph 7: > > OLD: > > > > --boundary71 > > Content-Type: application/sdp > > Content-Length: [length of SDP] > > > > NEW: > > > > --boundary71 > > Content-Type: application/sdp > > > > > > Section 9.1., paragraph 9: > > OLD: > > > > --boundary71 > > Content-Type: image/jpeg > > Content-Transfer-Encoding: binary > > Content-ID: > > Content-Length: [length of image] > > Content-Disposition: icon > > > > NEW: > > > > --boundary71 > > Content-Type: image/jpeg > > Content-Transfer-Encoding: binary > > Content-ID: > > Content-Disposition: icon > > > > > > Section 9.2., paragraph 24: > > OLD: > > > > --boundary71 > > Content-Type: application/sdp > > Content-Length: [length of SDP] > > > > NEW: > > > > --boundary71 > > Content-Type: application/sdp > > > > > > Section 9.2., paragraph 26: > > OLD: > > > > --boundary71 > > Content-Type: image/jpeg > > Content-Transfer-Encoding: binary > > Content-ID: > > Content-Length: [length of image] > > Content-Disposition: icon > > > > NEW: > > > > --boundary71 > > Content-Type: image/jpeg > > Content-Transfer-Encoding: binary > > Content-ID: > > Content-Disposition: icon > > > > Corrected Text > -------------- > > > Notes > ----- > A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored. > > > > This was discussed on both the SIP Implementors and SIP Core mailing lists. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5547 (draft-ietf-mmusic-file-transfer-mech-11) > -------------------------------------- > Title : A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer > Publication Date : May 2009 > Author(s) : M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat > Category : PROPOSED STANDARD > Source : Multiparty Multimedia Session Control > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Mon Apr 16 02:15:32 2012 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 6DF5321F865B for ; Mon, 16 Apr 2012 02:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 azNuMCf833ul for ; Mon, 16 Apr 2012 02:15:31 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7199721F8628 for ; Mon, 16 Apr 2012 02:15:31 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-a1-4f8be3324386 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 89.8B.26681.233EB8F4; Mon, 16 Apr 2012 11:15:30 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 11:15:29 +0200 Message-ID: <4F8BE32F.7070501@ericsson.com> Date: Mon, 16 Apr 2012 11:15:27 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <20120412160631.2C189B1E002@rfc-editor.org> <4F8BE215.7030108@ericsson.com> In-Reply-To: <4F8BE215.7030108@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" , Gonzalo Camarillo , Paul Kyzivat , "markus.isomaki@nokia.com" , "fandreas@cisco.com" , "bruno.chatras@orange.com" , RFC Errata System Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5547 (3190) 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, 16 Apr 2012 09:15:32 -0000 Resending with Paul's correct e-mail address. On 16/04/2012 11:10, Miguel A. Garcia wrote: > Hi: > > According to the discussion in SIPCORE, I agree with the reported errata. > It should be moved to status "verified". > > Thanks to Bruno and Paul for reporting it. > > /Miguel > > On 12/04/2012 18:06, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC5547, >> "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5547&eid=3190 >> >> -------------------------------------- >> Type: Technical >> Reported by: Bruno CHATRAS >> >> Section: GLOBAL >> >> Original Text >> ------------- >> Section 9.1., paragraph 7: >> >> OLD: >> >> >> >> --boundary71 >> >> Content-Type: application/sdp >> >> Content-Length: [length of SDP] >> >> >> >> NEW: >> >> >> >> --boundary71 >> >> Content-Type: application/sdp >> >> >> >> >> >> Section 9.1., paragraph 9: >> >> OLD: >> >> >> >> --boundary71 >> >> Content-Type: image/jpeg >> >> Content-Transfer-Encoding: binary >> >> Content-ID: >> >> Content-Length: [length of image] >> >> Content-Disposition: icon >> >> >> >> NEW: >> >> >> >> --boundary71 >> >> Content-Type: image/jpeg >> >> Content-Transfer-Encoding: binary >> >> Content-ID: >> >> Content-Disposition: icon >> >> >> >> >> >> Section 9.2., paragraph 24: >> >> OLD: >> >> >> >> --boundary71 >> >> Content-Type: application/sdp >> >> Content-Length: [length of SDP] >> >> >> >> NEW: >> >> >> >> --boundary71 >> >> Content-Type: application/sdp >> >> >> >> >> >> Section 9.2., paragraph 26: >> >> OLD: >> >> >> >> --boundary71 >> >> Content-Type: image/jpeg >> >> Content-Transfer-Encoding: binary >> >> Content-ID: >> >> Content-Length: [length of image] >> >> Content-Disposition: icon >> >> >> >> NEW: >> >> >> >> --boundary71 >> >> Content-Type: image/jpeg >> >> Content-Transfer-Encoding: binary >> >> Content-ID: >> >> Content-Disposition: icon >> >> >> >> Corrected Text >> -------------- >> >> >> Notes >> ----- >> A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored. >> >> >> >> This was discussed on both the SIP Implementors and SIP Core mailing lists. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5547 (draft-ietf-mmusic-file-transfer-mech-11) >> -------------------------------------- >> Title : A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer >> Publication Date : May 2009 >> Author(s) : M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat >> Category : PROPOSED STANDARD >> Source : Multiparty Multimedia Session Control >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From magnus.westerlund@ericsson.com Mon Apr 16 02:47:19 2012 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 2CED421F8633 for ; Mon, 16 Apr 2012 02:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.203 X-Spam-Level: X-Spam-Status: No, score=-106.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ibsAYfII8oA1 for ; Mon, 16 Apr 2012 02:47:18 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 508A621F8554 for ; Mon, 16 Apr 2012 02:47:18 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-2d-4f8beaa5abaf Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 46.88.03534.5AAEB8F4; Mon, 16 Apr 2012 11:47:17 +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.213.0; Mon, 16 Apr 2012 11:47:16 +0200 Message-ID: <4F8BEAA4.4090906@ericsson.com> Date: Mon, 16 Apr 2012 11:47:16 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <1DB4397F-D929-49FD-9462-095DF9196172@acmepacket.com> <581DCD23-A142-4414-8662-05B84FD8AA50@acmepacket.com> <1D062974A4845E4D8A343C65380492020827EB48@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020827EB48@XMB-BGL-414.cisco.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] media-loopback congestion 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, 16 Apr 2012 09:47:19 -0000 On 2012-04-16 08:04, Muthu Arul Mozhi Perumal (mperumal) wrote: > Hadriel, > > |..., when it can send packets back. > > This looks open for interpretation since there can be other reasons > apart from congestions where the mirror can't send packets back. My > suggestion is to state explicitly that congestion in the only exception: > > A loopback mirror that is compliant to this specification and > accepts media with rtp-pkt-loopback loopback-type MUST loopback the > incoming RTP packets using either the encapsulated RTP payload > format or the direct loopback RTP payload format as defined in > section 7 of this specification, except when the loopback mirror > perceives congestion. When the loopback mirror perceives congestion > it might not necessarily loopback all incoming RTP packets. To start with Hadriel's question if this is sufficient. I don't think so. The reasons is that unless you have a media level loopback capable of doing transcoding to a format with variable bit-rate the loopback case is such that you don't want to modify the packets in the return path. From the perspective of reaching the goals of loopback it would actually be best to put all the responsibility of the congestion control on the media source. And it needs to take both the forward and return path into account when making congestion control decisions. Actually this is in many ways simpler than having one way control. This as the packet sender and receiver are the same. The source will know what it sent and when and can make accurate full RTT measurements to determine delay variations. It is also certain of all the packets it sent. If the mirror is truly deterministic in its behavior then you can accurately model for these conditions. In fact having the mirror detect and stop sending when it sees congestion actually makes the source work more difficult. So I see several approaches here. 1) Specify that the source is sole responsible for both paths. 2) Specify that the source is sole responsible and have the mirror verify compliance by running a circuit breaker algorithm to verify that at least the return path isn't seriously messing things up. 3) Specify that each side runs independent congestion control and then discuss the impact on the return path when there is congestion in that direction and not the forward one. 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 mperumal@cisco.com Mon Apr 16 22:53:00 2012 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 58D0C11E80A2 for ; Mon, 16 Apr 2012 22:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 G8T3rowFszSO for ; Mon, 16 Apr 2012 22:52:56 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2A27021F85D4 for ; Mon, 16 Apr 2012 22:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=5291; q=dns/txt; s=iport; t=1334641975; x=1335851575; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/dTE4K8+comDkaCtuTPLVO09OsvBlYn50OboBXSLYrs=; b=T0ojzTtC+SROB1VF+bzWrO48VQPSJz/482/V4EPFaIrPouY29n8Xs8v/ j1Rj1JvoSp0l288e7+DvtPWZT0h82AhIZJas2QT1FsGUzDEx+9n9icaZ5 LZX5oCG/D8QYPXCarxfMmbN+eciGGzRjU0f7Cv96ALtO2P23WgazLTL5P E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAOcDjU9Io8UY/2dsb2JhbABEsj2CCQEBAQQMBgEdSQwCAgIBCBEEAQELBgUSAQYBGisJCAEBBAsICBqHbJldoA0EizOCYoJNYwSIJzGbYYFpgm+BTAcBDw X-IronPort-AV: E=Sophos;i="4.75,432,1330905600"; d="scan'208";a="10224285" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 17 Apr 2012 05:52:53 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3H5qrFZ019212; Tue, 17 Apr 2012 05:52:53 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 11:22:53 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 11:22:51 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020827EEA1@XMB-BGL-414.cisco.com> In-Reply-To: <4F8BEAA4.4090906@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] media-loopback congestion Thread-Index: Ac0btfZZvTzR6TCkQrm1AZZfU8vyywAnkabQ References: <1DB4397F-D929-49FD-9462-095DF9196172@acmepacket.com> <581DCD23-A142-4414-8662-05B84FD8AA50@acmepacket.com> <1D062974A4845E4D8A343C65380492020827EB48@XMB-BGL-414.cisco.com> <4F8BEAA4.4090906@ericsson.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Magnus Westerlund" X-OriginalArrivalTime: 17 Apr 2012 05:52:53.0312 (UTC) FILETIME=[5475C400:01CD1C5E] Cc: draft-ietf-mmusic-media-loopback.authors@tools.ietf.org, "mmusic \(E-mail\)" Subject: Re: [MMUSIC] media-loopback congestion 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, 17 Apr 2012 05:53:00 -0000 |From the perspective of reaching the goals of loopback it would |actually be best to put all the responsibility of the congestion=20 |control on the media source. And it needs to take both the forward |and return path into account when making congestion control decisions. I agree. The purpose of the packet loopback mode is to provide a simple = mechanism to test how good the media path is and not to test how good = the mirror can respond to network congestion, IMHO. If there is packet = loss due to congestion, so it be -- the loopback source will know that. = It might then want to repeat the test to see if this is a temporary = issue. If subsequent tests produce packet loss, it might conclude that = the media path isn't good for making an audio/video call using the coded = it used. Requiring the mirror to implement congestion control to conceal packet = loss would be of little value for this case. Worse, if were a mechanism = different from what the mirror endpoint might use when it actually = renders and generates media -- it might give a false impression about = the quality of the media path. |2) Specify that the source is sole responsible and have the mirror |verify compliance by running a circuit breaker algorithm to verify |that at least the return path isn't seriously messing things up. I agree the source should be made responsible for congestion control for = both the paths. In addition, a mirror running circuit breaker could be = useful if it does the same when it renders and generates media -- might = help the user to determine using packet loopback at point media stops = working. On the other hand, if the purpose of the test is to see how = seriously the return path is messed up, then a circuit breaker at the = mirror may not be needed. So, the draft could specify that the mirror = MAY run a circuit breaker, I think. On similar lines, having the mirror report congestion to the source = might be useful as well. Muthu |-----Original Message----- |From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] |Sent: Monday, April 16, 2012 3:17 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: Hadriel Kaplan; mmusic (E-mail); = draft-ietf-mmusic-media-loopback.authors@tools.ietf.org |Subject: Re: [MMUSIC] media-loopback congestion | |On 2012-04-16 08:04, Muthu Arul Mozhi Perumal (mperumal) wrote: |> Hadriel, |> |> |..., when it can send packets back. |> |> This looks open for interpretation since there can be other reasons |> apart from congestions where the mirror can't send packets back. My |> suggestion is to state explicitly that congestion in the only = exception: |> |> A loopback mirror that is compliant to this specification and |> accepts media with rtp-pkt-loopback loopback-type MUST loopback = the |> incoming RTP packets using either the encapsulated RTP payload |> format or the direct loopback RTP payload format as defined in |> section 7 of this specification, except when the loopback mirror |> perceives congestion. When the loopback mirror perceives = congestion |> it might not necessarily loopback all incoming RTP packets. | | |To start with Hadriel's question if this is sufficient. I don't think |so. The reasons is that unless you have a media level loopback capable |of doing transcoding to a format with variable bit-rate the loopback |case is such that you don't want to modify the packets in the return |path. From the perspective of reaching the goals of loopback it would |actually be best to put all the responsibility of the congestion = control |on the media source. And it needs to take both the forward and return |path into account when making congestion control decisions. | |Actually this is in many ways simpler than having one way control. This |as the packet sender and receiver are the same. The source will know |what it sent and when and can make accurate full RTT measurements to |determine delay variations. It is also certain of all the packets it |sent. If the mirror is truly deterministic in its behavior then you can |accurately model for these conditions. In fact having the mirror detect |and stop sending when it sees congestion actually makes the source work |more difficult. | |So I see several approaches here. | |1) Specify that the source is sole responsible for both paths. | |2) Specify that the source is sole responsible and have the mirror |verify compliance by running a circuit breaker algorithm to verify that |at least the return path isn't seriously messing things up. | |3) Specify that each side runs independent congestion control and then |discuss the impact on the return path when there is congestion in that |direction and not the forward one. | |Cheers | |Magnus Westerlund | |---------------------------------------------------------------------- |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 zhou.sujing@zte.com.cn Tue Apr 17 19:49:10 2012 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 96B0A21F857F for ; Tue, 17 Apr 2012 19:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.655 X-Spam-Level: X-Spam-Status: No, score=-96.655 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 RRYoH3FosenE for ; Tue, 17 Apr 2012 19:49:06 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id BC37F21F857D for ; Tue, 17 Apr 2012 19:49:05 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 28620978252052; Wed, 18 Apr 2012 10:09:46 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 96035.2712434073; Wed, 18 Apr 2012 10:49:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3I2mt4H003881; Wed, 18 Apr 2012 10:48:55 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <034c01cd1cb0$b6add5c0$24098140$@com> To: "Dan Wing" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 18 Apr 2012 10:48:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-18 10:48:57, Serialize complete at 2012-04-18 10:48:57 Content-Type: multipart/alternative; boundary="=_alternative 000F7DFF482579E4_=" X-MAIL: mse02.zte.com.cn q3I2mt4H003881 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hi, May I ask for your opinion on draft-zhou-mmusic-sdes-keymod-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: Wed, 18 Apr 2012 02:49:10 -0000 This is a multipart message in MIME format. --=_alternative 000F7DFF482579E4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCg0KIkRhbiBXaW5nIiA8ZHdpbmdAY2lzY28uY29t PiDQtNPaIDIwMTItMDQtMTcgMjM6NDI6MzY6DQoNCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+IEZyb206IHpob3Uuc3VqaW5nQHp0ZS5jb20uY24gW21haWx0bzp6aG91LnN1amlu Z0B6dGUuY29tLmNuXQ0KPiA+IFNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgMTA6MTAgUE0N Cj4gPiBUbzogRGFuIFdpbmcNCj4gPiBTdWJqZWN0OiC08Li0OiBSRTogSGksIE1heSBJIGFzayBm b3IgeW91ciBvcGluaW9uIG9uIA0KZHJhZnQtemhvdS1tbXVzaWMtDQo+ID4gc2Rlcy1rZXltb2Qt MDE/DQo+ID4gDQo+ID4gDQo+ID4gWWVzo6x0aGUgb2ZmZXIgY2Fubm90IGRldGVybWluIGlmIHJl LXRyYWdldGluZyBvciBmb3JraW5nIGFyZSANCm9jY3VyaW5nLg0KPiA+IEkgYWRkZWQgYSBuZXcg cGFyYW1ldGVyICJrZXltb2QiIHdpdGggTlVMTKGhdmFsdWUgaW4gdGhlIG9mZmVyIG1lc3NhZ2UN Cj4gPiAoaW4gMDEgdmVyc2lvbikgbm8gbWF0dGVyIHdpY2ggc2NlbmFyaW9zLA0KPiA+IHRvIGlu Zm9ybSB0aGUgYW5zd2VyZXIgdGhhdA0KPiA+IA0KPiA+ICAiSGksIEkgYW0ga2luZCBvZiBjb25j ZXJuZWQgYWJvdXQgbXkgb3V0Z29pbmcNCj4gPiBtZXNzYWdlIGJlIGludGVyY2VwdCBieSBzb21l IGludGVybWVkaWF0ZXMsIHNvIEkgYW0gcmVhZHkgdG8gYWNjZXB0IA0KYW55DQo+ID4gYW5zd2Vy IG1lc3NhZ2Ugd2l0aA0KPiA+IGtleW1vZCBwYXJhbWV0ZXIsIGlmIHlvdSBzZW5kIHZhbHVlcyBp biBrZXltb2QgcGFyYW1ldGVyLCBJIGNhbiB1cGRhdGUNCj4gPiBteSBrZXkgYWNjb3JkaW5nbHki DQo+ID4gDQo+ID4gSXQgaXMgdXAgdG8gdGhlIGFuc3dlcmVyIHRvIGRlY2lkZSBpZiBpdCB3aWxs IHNlbmQga2V5bW9kIHBhcmFtZXRlcg0KPiA+IHdpdGggdmFsaWQgdmFsdWUuDQo+ID4gDQo+ID4g SWYgdGhlIGFuc3dlciBkb2VzIG5vdCBjYXJlLCBpdCBjYW4gc2VuZCBrZXltb2Qgd2l0aCBOVUxM IHZhbHVlLCBhbmQNCj4gPiB0aGlzIGNhc2UgaXMgdGhlIHNhbWUgYXMgdGhlIGN1cnJlbnQgU0RF UzsNCj4gPiBJZiB0aGUgYW5zd2VyIGNhcmVzLCBpdCBjYW4gc2VuZCBrZXltb2Qgd2l0aCBub24t TlVMTCB2YWx1ZSwgYW5kIHRoaXMNCj4gPiBjYXNlIGlzIHdoYXQgb3VyIGRvY3VtZW50IGlzIHNv bHZpbmcuDQo+ID4gDQo+ID4gVGhlIGFuc3dlcmVyIG1heSBiZSBhYmxlIHRvIGRldGVjdCBpdCBp cyBpbiBhIHJlLXRhcmdldGluZy9mb3JraW5nDQo+ID4gc2NlbmFyaW8sIGFuZCBiZSB0cmlnZ2Vy ZWQgdG8gc2VuZCBrZXltb2Q7DQo+ID4gT3IsIHRoZSBhbnN3ZXJlciBjb3VsZCBub3QgZGV0ZWN0 IHRoZSBzaXR1YXRpb24sIGFuZCBiZSBlbmNvdXJhZ2VkIHRvDQo+ID4gc2VuZCBrZXltb2QsIGJl Y2F1c2Ugb2ZmZXJlciBhc2tlZCBmb3IuDQo+IA0KPiBUaGUgb2ZmZXJlciBzaG91bGQganVzdCBh bHdheXMgaXNzdWUgYSByZS1JbnZpdGUgd2l0aCBhIG5ldyBhPWNyeXB0byANCmtleS4gDQo+IA0K PiBJIGd1ZXNzIHlvdSBhcmUgdHJ5aW5nIHRvIG9wdGltaXplIHRoYXQgc28gdGhhdCB0aGUgb2Zm ZXJlciBhbmQgYW5zd2VyZXINCj4gc29tZWhvdyBkZXRlcm1pbmUgaWYgYSByZS1JbnZpdGUgbWln aHQgYmUgbmVjZXNzYXJ5PyAgV2h5IG5vdCBnZW5lcmFsaXplDQo+IHRoYXQgb3B0aW1pemF0aW9u LCBzbyB0aGF0IHRoZSBhbnN3ZXJlciBpbmRpY2F0ZXMgInJlLWRpcmVjdCBvY2N1cnJlZCIgDQph bmQNCj4gaW5kaWNhdGVzICJmb3JraW5nIG9jY3VycmVkIj8gIFRoYXQgY291bGQgYmUgdXNlZnVs IGZvciB0aGlzIFNERVNDIA0KcmUtSW52aXRlDQo+IG9wdGltaXphdGlvbiwgYW5kIGNvdWxkIGJl IHVzZWZ1bCBlbHNld2hlcmUuICBIb3dldmVyLCBJIGJlbGlldmUgaXQgaXMNCj4gaW1wb3NzaWJs ZSBmb3IgdGhlIEFuc3dlcmVyIHRvIHJlbGlhYmx5IGRldGVybWluZSBpZiBhIHJlLWRpcmVjdCAN Cm9jY3VycmVkIG9yDQo+IGlmIGZvcmtpbmcgb2NjdXJyZWQsIHdoaWNoIGlzIHdoeSBJIGhhdmUg ZG91YnQgdGhhdCB0aGUgcHJvcG9zYWwgaW4geW91ciANCkktRA0KPiBjYW4gd29yayBhcyB5b3Ug aG9wZS4NCj4gDQo+IC1kDQogDQpMZXQgdGhlIG9mZmVyZXIgc2VuZCBhIHJlLUludml0ZSBvciBh biBVUERBVEUgd2l0aCBhIG5ldyBhPWNyeXB0byBrZXkgaXMgDQppbmRlZWQgYW4gc29sdXRpb24u DQpCdXQgaXQgcmVxdWlyZSBtb3JlIHJvdW5kdHJpcHMuDQoNCk91ciBtb3RpdmF0aW9ucyBhcmUg DQotdG8gb3B0aW1pemUgdGhlIHByb2NlZHVyZQ0KLXRvIGVuaGFuY2UgdGhlIHNlY3VyaXR5IG9m IFNERVMNCg0KeW91ciBxdWVzdGlvbiBpcyBhcm91bmQgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhl IG9wdGltaXplZCBwcm9jZWR1cmUuDQpJbiB0aGUgY2FzZSBvZiByZS1kaXJlY3Qgb2NjdXJzLCB0 aGUgYW53c2VyIGFsd2F5cyBrbm93cyBpdCBpcyBhIA0KcmUtZGlyZWN0ZWQgY2FsbCxzaG91bGQg bm8gcHJvYmxlbSwgb3VyIDAwIGRyYWZ0IHdvcmtzLg0KSW4gdGhlIGNhc2UgIG9mIGZvcmtpbmcs IHRoZSBhbnN3ZXIgZG9lcyBub3Qga25vdyBpdCBpcyBhIGZvcmtlZCBjYWxsLCBvdXIgDQowMCBk cmFmdCBkb2VzIG5vdCB3b3JrIGluIHRoaXMgY2FzZS4NCg0KT3VyIDAxIHZlcmlvbiBkb2VzIG5v dCBsZXQgYW5zd2VyIGFsb25lIHRvIGRldGVybWluIGlmIGEgcmUtZGlyZWN0IG9yIGEgDQpmb3Jr aW5nIG9jY3VyLg0KSW5zdGVhZCwgb3VyIDAxIHZlcnNpb24gaXMgYSBnZW5lcmFsIHVwZ3JhZGUg dG8gY3VycmVudCBTREVTIHByb3RvY29sLCANCnRoYXQgd2lsbCBjb21lIHRvIG91cg0KYW5vdGhl ciBtb3RpdmF0aW9uIDplbmhhbmNlIHRoZSBzZWN1cml0eSBvZiBTREVTDQoNCkdlbmVyYWx5IGl0 IGlzIHByZWZlcmFibGUgdGhlIHNlc3Npb24ga2V5ICBiZXR3ZWVuIHR3byBwZWVycyAgYmUgDQpl c3RhYmxpc2hlZCB3aXRoIGNvbnRyaWJ1dGlvbiBmcm9tIGJvdGggcGVlcnMsb3RoZXJ3aXNlIHdl IHdpbGwgZ2V0ICBpbnRvIA0KdHJvdWJsZSANCmFzICBTREVTIG5vdyBpbiB0aGUgc2NlbmFyaW9z IG9mIHJlLXRhcmdldHRpbmcgYW5kIGZvcmtpbmcuDQpPdXIgMDEgdmVyc2lvbiBhY3R1YWxseSBz dWdnZXN0cyB0byBjaGFuZ2UgdGhlIHVuaWRpcmVjdGlvbmFsIGtleSANCnRyYW5zcG9ydCBpbiBT REVTIGludG8gYSBrZXkgYWdyZWVtZW50KGluZGljYXRlZCBieSAia2V5bW9kIik6DQpvZmZlcmVy IHByb3ZpZGVzOiBrMSANCmFuc3dlciBwcm92aWRlczoga2V5bW9kIHZhbHVlDQp0aGUgb3V0Z29p bmcga2V5IGZyb20gb2ZmZXJlciB0byBhbnN3ZXJlciBpcyBkZXJpdmVkIGZyb20gazEgYW5kIGtl eW1vZCANCnZhbHVlIG5vIG1hdHRlciBpbiB3aGljaCBzaXR1YXRpb24uDQpSZS10YXJnZXRpbmcg YW5kIGZvcmtpbmcgIGhhcHBlbiB0byBiZSB0aGUgc2NlbmFyaW9zIHRoYXQgZXNwZWNpYWxseSAN CmJlbmVmaXQgZnJvbSB0aGUgY2hhbmdlLg0KDQoNCg0KPiANCj4gDQo+ID4gDQo+ID4gDQo+ID4g UmVnYXJkc35+fg0KPiA+IA0KPiA+IC1TdWppbmcgWmhvdQ0KPiA+IA0KPiA+ICJEYW4gV2luZyIg PGR3aW5nQGNpc2NvLmNvbT4g0LTT2iAyMDEyLTA0LTE3IDA1OjE0OjU4Og0KPiA+IA0KPiA+ID4g SSBkb24ndCBzZWUgaG93IHNlbmRpbmcgYWRkaXRpb25hbCBwYXJhbWV0ZXJzIHNvbHZlcyB0aGUg cHJvYmxlbS4NCj4gPiA+DQo+ID4gPiBUaGUgcHJvYmxlbSBpcyB0aGUgb2ZmZXJlciBjYW5ub3Qg ZGV0ZXJtaW5lIGlmIHJlLXRhcmdldGluZyBvcg0KPiA+IGZvcmtpbmcNCj4gPiA+IG9jY3VycmVk LCBhbmQgdGh1cyBjYW5ub3QgZGV0ZXJtaW5lIGlmIGl0IG5lZWRzIHRvIHNlbmQgYSBuZXcNCj4g PiAodXBkYXRlZCkNCj4gPiA+IG9mZmVyLiAgVGhlIG9ubHkgc29sdXRpb24gaXMgdG8gYWx3YXlz IHNlbmQgYSBuZXcgb2ZmZXIuDQo+ID4gPg0KPiA+ID4gLWQNCj4gPiA+DQo+ID4gPg0KPiA+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiB6aG91LnN1amluZ0B6 dGUuY29tLmNuIFttYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbl0NCj4gPiA+ID4gU2VudDog TW9uZGF5LCBBcHJpbCAxNiwgMjAxMiAxMjoyOSBBTQ0KPiA+ID4gPiBUbzogRGFuIFdpbmcNCj4g PiA+ID4gU3ViamVjdDogSGksIE1heSBJIGFzayBmb3IgeW91ciBvcGluaW9uIG9uIGRyYWZ0LXpo b3UtbW11c2ljLXNkZXMtDQo+ID4gPiA+IGtleW1vZC0wMT8NCj4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+ID4gSGksIFdpbmcsDQo+ID4gPiA+DQo+ID4gPiA+ICAgSaGhaGF2ZSB1cGRhdGVkIG15IGRy YWZ0IGluY29ycG9yYXRpbmcgeW91ciBxdWVzdGlvbi4NCj4gPiA+ID4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhvdS1tbXVzaWMtc2Rlcy1rZXltb2QtMDENCj4gPiA+ID4gICBN YXkgSSBhc2sgZm9yIHlvdXIgb3BpbmlvbiBhbmQgaW50ZXJlc3QgaW4gaXQ/DQo+ID4gPiA+DQo+ ID4gPiA+IFRoYW5rIHlvdSENCj4gPiA+ID4NCj4gPiA+ID4gUmVnYXJkc35+fg0KPiA+ID4gPg0K PiA+ID4gPiAtU3VqaW5nIFpob3UNCj4gPiA+ID4NCj4gPiA+ID4gbW11c2ljLWJvdW5jZXNAaWV0 Zi5vcmcg0LTT2iAyMDEyLTAzLTIxIDA5OjMyOjQwOg0KPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gSGmjrCBXaW5nDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAgICAgWW91ciBwb2ludCBpcyBn b29kLCBJIG1heSB1cGRhdGUgb3VyIGRyYWZ0IChpbiAwMSB2ZXJzaW9uKQ0KPiA+IGxpa2UNCj4g PiA+ID4gPiB0aGUgZm9sbG93aW5nIHBhcmFncmFwaDoNCj4gPiA+ID4gPiAiIDMuMS4gIEdlbmVy YXRpbmcgdGhlIEluaXRpYWwgT2ZmZXIgLSBVbmljYXN0IFN0cmVhbXMNCj4gPiA+ID4gPg0KPiA+ ID4gPiA+ICAgIFRoZSBnZW5lcmF0aW9uIG9mIHRoZSBpbml0aWFsIG9mZmVyIGZvciBhIHVuaWNh c3Qgc3RyZWFtIE1VU1QNCj4gPiA+ID4gZm9sbG93DQo+ID4gPiA+ID4gICAgdGhhdCBvZiB0aGUg Y3J5cHRvIGF0dHJpYnV0ZSBSRkM0NTY4IFtSRkM0NTY4XSwgYW5kIE1BWQ0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gICAgYWxzbyBpbmNsdWRlIGFuIGFkZGl0aW9uYWwgImtleW1vZCIgcGFyYW1ldGVy IHdpdGgga2V5bW9kLXZhbA0KPiA+ID4gPiBiZWluZw0KPiA+ID4gPiA+ICAgIE5VTEwuICBJdCBp bmRpY2F0ZXMgdG8gdGhlIHVsdGltYXRlIGFuc3dlcmVyIHRoYXQgdGhlIG9mZmVyZXINCj4gPiA+ ID4gd2FudHMNCj4gPiA+ID4gPiAgICB0byBlbXBsb3kgdGhlIG1lY2hhbmlzbSBzcGVjaWZpZWQg aW4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIHRoaXMgZG9jdW1lbnQsIGEga2V5IGFncmVlbWVu dCBtZWNoYW5pc20gd2l0aCBhIGhpZ2hlcg0KPiA+IHNlY3VyaXR5DQo+ID4gPiA+IGxldmVsDQo+ ID4gPiA+ID4gICAgdGhhbiB0aGUgb3JpZ2luYWwgU0RFUy4NCj4gPiA+ID4gPiAiDQo+ID4gPiA+ ID4gU28gdGhhdCBhbnN3ZXJlciBkb2VzIG5vdCBuZWVkIHRvIGtub3cgaXQgaXMgaW4gYSByZS10 YXJnZXRpbmcgDQpvcg0KPiA+ID4gPiA+IGZvcmtpbmcgc2NlbmFyaW8sDQo+ID4gPiA+ID4gaXQg aXMgb2ZmZXJlciBzdWdnZXN0aW5nIHVzZSBrZXltb2QgbWVjaGFuaXNtLg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFJlZ2FyZHN+fn4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IC1TdWppbmcgWmhvdQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gIkRhbiBXaW5nIiA8ZHdp bmdAY2lzY28uY29tPiDQtNPaIDIwMTItMDMtMTggMTA6NDM6NDI6DQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IFRvIGJlIGVmZmVjdGl2ZSwgZHJhZnQtemhvdS1tbXVzaWMtc2Rlcy1rZXltb2QgbmVl ZHMgdGhlDQo+ID4gQW5zd2VyZXINCj4gPiA+ID4gdG8gc2VuZA0KPiA+ID4gPiA+ID4gdGhlICJr ZXltb2QiIGV4dGVuc2lvbiBpZiBpdCBrbm93cywgb3IgYmVsaWV2ZXMsIHRoZSBJTlZJVEUgDQp3 YXMNCj4gPiByZS0NCj4gPiA+ID4gdGFyZ2V0ZWQNCj4gPiA+ID4gPiA+IG9yIGZvcmtlZC4gIEkg aGF2ZSB0d28gcXVlc3Rpb25zOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEkgc2VlIGZvciB0 aGUgZGVzY3JpYmVkIHJlLXRhcmdldGluZyBjYXNlIChTZWN0aW9uIDUuMSBvZg0KPiA+ID4gPiA+ ID4gZHJhZnQtemhvdS1tbXVzaWMtc2Rlcy1rZXltb2QtMDApLCBhICJjYXVzZSIgcGFyYW1ldGVy DQo+ID4gW1JGQzQ0NThdDQo+ID4gPiA+IGNhbiBiZSBhDQo+ID4gPiA+ID4gPiB1c2VmdWwgaW5k aWNhdG9yIHRoYXQgYSBjYWxsIHdhcyByZS10YXJnZXRlZC4gIElzIHRoZSAiY2F1c2UiDQo+ID4g PiA+IHBhcmFtZXRlcg0KPiA+ID4gPiA+ID4gYWx3YXlzIHByZXNlbnQgd2hlbiBhIGNhbGwgaXMg cmUtdGFyZ2V0ZWQ/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSG93IGRvZXMgdGhlIEFuc3dl cmVyIGtub3cgaWYgYSBjYWxsIHdhcyBmb3JrZWQ/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g LWQNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+ID4gPiA+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBtbXVzaWNAaWV0Zi5v cmcNCj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp Yw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiANCj4gDQo+IA0KDQo= --=_alternative 000F7DFF482579E4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+ DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtE YW4gV2luZyZxdW90OyAmbHQ7ZHdpbmdAY2lzY28uY29tJmd0OyDQtNPaDQoyMDEyLTA0LTE3IDIz OjQyOjM2Ojxicj4NCjxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgJmd0OyBGcm9tOiB6aG91LnN1amluZ0B6dGUuY29tLmNuIFttYWlsdG86emhvdS5z dWppbmdAenRlLmNvbS5jbl08YnI+DQomZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBBcHJpbCAxNiwg MjAxMiAxMDoxMCBQTTxicj4NCiZndDsgJmd0OyBUbzogRGFuIFdpbmc8YnI+DQomZ3Q7ICZndDsg U3ViamVjdDogtPC4tDogUkU6IEhpLCBNYXkgSSBhc2sgZm9yIHlvdXIgb3BpbmlvbiBvbiBkcmFm dC16aG91LW1tdXNpYy08YnI+DQomZ3Q7ICZndDsgc2Rlcy1rZXltb2QtMDE/PGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgWWVzo6x0aGUgb2ZmZXIgY2Fubm90 IGRldGVybWluIGlmIHJlLXRyYWdldGluZyBvciBmb3JraW5nIGFyZQ0Kb2NjdXJpbmcuPGJyPg0K Jmd0OyAmZ3Q7IEkgYWRkZWQgYSBuZXcgcGFyYW1ldGVyICZxdW90O2tleW1vZCZxdW90OyB3aXRo IE5VTEyhoXZhbHVlDQppbiB0aGUgb2ZmZXIgbWVzc2FnZTxicj4NCiZndDsgJmd0OyAoaW4gMDEg dmVyc2lvbikgbm8gbWF0dGVyIHdpY2ggc2NlbmFyaW9zLDxicj4NCiZndDsgJmd0OyB0byBpbmZv cm0gdGhlIGFuc3dlcmVyIHRoYXQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyZxdW90O0hpLCBJIGFtIGtpbmQgb2YgY29uY2VybmVkIGFib3V0IG15IG91dGdvaW5nPGJyPg0K Jmd0OyAmZ3Q7IG1lc3NhZ2UgYmUgaW50ZXJjZXB0IGJ5IHNvbWUgaW50ZXJtZWRpYXRlcywgc28g SSBhbSByZWFkeSB0bw0KYWNjZXB0IGFueTxicj4NCiZndDsgJmd0OyBhbnN3ZXIgbWVzc2FnZSB3 aXRoPGJyPg0KJmd0OyAmZ3Q7IGtleW1vZCBwYXJhbWV0ZXIsIGlmIHlvdSBzZW5kIHZhbHVlcyBp biBrZXltb2QgcGFyYW1ldGVyLCBJIGNhbg0KdXBkYXRlPGJyPg0KJmd0OyAmZ3Q7IG15IGtleSBh Y2NvcmRpbmdseSZxdW90Ozxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSXQgaXMgdXAg dG8gdGhlIGFuc3dlcmVyIHRvIGRlY2lkZSBpZiBpdCB3aWxsIHNlbmQga2V5bW9kIHBhcmFtZXRl cjxicj4NCiZndDsgJmd0OyB3aXRoIHZhbGlkIHZhbHVlLjxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgSWYgdGhlIGFuc3dlciBkb2VzIG5vdCBjYXJlLCBpdCBjYW4gc2VuZCBrZXltb2Qg d2l0aCBOVUxMIHZhbHVlLA0KYW5kPGJyPg0KJmd0OyAmZ3Q7IHRoaXMgY2FzZSBpcyB0aGUgc2Ft ZSBhcyB0aGUgY3VycmVudCBTREVTOzxicj4NCiZndDsgJmd0OyBJZiB0aGUgYW5zd2VyIGNhcmVz LCBpdCBjYW4gc2VuZCBrZXltb2Qgd2l0aCBub24tTlVMTCB2YWx1ZSwNCmFuZCB0aGlzPGJyPg0K Jmd0OyAmZ3Q7IGNhc2UgaXMgd2hhdCBvdXIgZG9jdW1lbnQgaXMgc29sdmluZy48YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBhbnN3ZXJlciBtYXkgYmUgYWJsZSB0byBkZXRlY3Qg aXQgaXMgaW4gYSByZS10YXJnZXRpbmcvZm9ya2luZzxicj4NCiZndDsgJmd0OyBzY2VuYXJpbywg YW5kIGJlIHRyaWdnZXJlZCB0byBzZW5kIGtleW1vZDs8YnI+DQomZ3Q7ICZndDsgT3IsIHRoZSBh bnN3ZXJlciBjb3VsZCBub3QgZGV0ZWN0IHRoZSBzaXR1YXRpb24sIGFuZCBiZSBlbmNvdXJhZ2Vk DQp0bzxicj4NCiZndDsgJmd0OyBzZW5kIGtleW1vZCwgYmVjYXVzZSBvZmZlcmVyIGFza2VkIGZv ci48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIG9mZmVyZXIgc2hvdWxkIGp1c3QgYWx3YXlzIGlz c3VlIGEgcmUtSW52aXRlIHdpdGggYSBuZXcgYT1jcnlwdG8NCmtleS4gJm5ic3A7PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEkgZ3Vlc3MgeW91IGFyZSB0cnlpbmcgdG8gb3B0aW1pemUgdGhhdCBzbyB0 aGF0IHRoZSBvZmZlcmVyIGFuZCBhbnN3ZXJlcjxicj4NCiZndDsgc29tZWhvdyBkZXRlcm1pbmUg aWYgYSByZS1JbnZpdGUgbWlnaHQgYmUgbmVjZXNzYXJ5PyAmbmJzcDtXaHkgbm90DQpnZW5lcmFs aXplPGJyPg0KJmd0OyB0aGF0IG9wdGltaXphdGlvbiwgc28gdGhhdCB0aGUgYW5zd2VyZXIgaW5k aWNhdGVzICZxdW90O3JlLWRpcmVjdA0Kb2NjdXJyZWQmcXVvdDsgYW5kPGJyPg0KJmd0OyBpbmRp Y2F0ZXMgJnF1b3Q7Zm9ya2luZyBvY2N1cnJlZCZxdW90Oz8gJm5ic3A7VGhhdCBjb3VsZCBiZSB1 c2VmdWwNCmZvciB0aGlzIFNERVNDIHJlLUludml0ZTxicj4NCiZndDsgb3B0aW1pemF0aW9uLCBh bmQgY291bGQgYmUgdXNlZnVsIGVsc2V3aGVyZS4gJm5ic3A7SG93ZXZlciwgSSBiZWxpZXZlDQpp dCBpczxicj4NCiZndDsgaW1wb3NzaWJsZSBmb3IgdGhlIEFuc3dlcmVyIHRvIHJlbGlhYmx5IGRl dGVybWluZSBpZiBhIHJlLWRpcmVjdCBvY2N1cnJlZA0Kb3I8YnI+DQomZ3Q7IGlmIGZvcmtpbmcg b2NjdXJyZWQsIHdoaWNoIGlzIHdoeSBJIGhhdmUgZG91YnQgdGhhdCB0aGUgcHJvcG9zYWwgaW4N CnlvdXIgSS1EPGJyPg0KJmd0OyBjYW4gd29yayBhcyB5b3UgaG9wZS48YnI+DQomZ3Q7IDxicj4N CiZndDsgLWQ8YnI+DQogPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5MZXQgdGhl IG9mZmVyZXIgc2VuZCBhIHJlLUludml0ZSBvciBhbiBVUERBVEUgd2l0aA0KYSBuZXcgYT1jcnlw dG8ga2V5IGlzIGluZGVlZCBhbiBzb2x1dGlvbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPkJ1dCBpdCByZXF1aXJlIG1vcmUgcm91bmR0cmlwcy48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPk91ciBtb3RpdmF0aW9ucyBhcmUgPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4tdG8gb3B0aW1pemUgdGhlIHByb2NlZHVyZTwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+LXRvIGVuaGFuY2UgdGhlIHNlY3VyaXR5IG9mIFNERVM8 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnlvdXIgcXVlc3Rpb24gaXMg YXJvdW5kIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBvcHRpbWl6ZWQNCnByb2NlZHVyZS48L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkluIHRoZSBjYXNlIG9mIHJlLWRpcmVjdCBv Y2N1cnMsIHRoZSBhbndzZXIgYWx3YXlzDQprbm93cyBpdCBpcyBhIHJlLWRpcmVjdGVkIGNhbGws c2hvdWxkIG5vIHByb2JsZW0sIG91ciAwMCBkcmFmdCB3b3Jrcy48L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPkluIHRoZSBjYXNlICZuYnNwO29mIGZvcmtpbmcsIHRoZSBhbnN3ZXIg ZG9lcyBub3QNCmtub3cgaXQgaXMgYSBmb3JrZWQgY2FsbCwgJm5ic3A7b3VyIDAwIGRyYWZ0IGRv ZXMgbm90IHdvcmsgaW4gdGhpcyBjYXNlLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+T3VyIDAxIHZlcmlvbiBkb2VzIG5vdCBsZXQgYW5zd2VyIGFsb25lIHRvIGRldGVy bWluDQppZiBhIHJlLWRpcmVjdCBvciBhIGZvcmtpbmcgb2NjdXIuPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5JbnN0ZWFkLCBvdXIgMDEgdmVyc2lvbiBpcyBhIGdlbmVyYWwgdXBn cmFkZSB0byBjdXJyZW50DQpTREVTIHByb3RvY29sLCB0aGF0IHdpbGwgY29tZSB0byBvdXI8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmFub3RoZXIgbW90aXZhdGlvbiA6ZW5oYW5j ZSB0aGUgc2VjdXJpdHkgb2YgU0RFUzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+R2VuZXJhbHkgaXQgaXMgcHJlZmVyYWJsZSB0aGUgc2Vzc2lvbiBrZXkgJm5ic3A7YmV0 d2Vlbg0KdHdvIHBlZXJzICZuYnNwO2JlIGVzdGFibGlzaGVkIHdpdGggY29udHJpYnV0aW9uIGZy b20gYm90aCBwZWVycyxvdGhlcndpc2UNCndlIHdpbGwgZ2V0ICZuYnNwO2ludG8gdHJvdWJsZSA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmFzICZuYnNwO1NERVMgbm93IGluIHRo ZSBzY2VuYXJpb3Mgb2YgcmUtdGFyZ2V0dGluZw0KYW5kIGZvcmtpbmcuPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5PdXIgMDEgdmVyc2lvbiBhY3R1YWxseSBzdWdnZXN0cyB0byBj aGFuZ2UgdGhlIHVuaWRpcmVjdGlvbmFsDQprZXkgdHJhbnNwb3J0IGluIFNERVMgaW50byBhIGtl eSBhZ3JlZW1lbnQoaW5kaWNhdGVkIGJ5ICZxdW90O2tleW1vZCZxdW90Oyk6PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5vZmZlcmVyIHByb3ZpZGVzOiBrMSAmbmJzcDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5hbnN3ZXIgcHJvdmlkZXM6IGtleW1v ZCB2YWx1ZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+dGhlIG91dGdvaW5nIGtl eSBmcm9tIG9mZmVyZXIgdG8gYW5zd2VyZXIgaXMgZGVyaXZlZA0KZnJvbSBrMSBhbmQga2V5bW9k IHZhbHVlIG5vIG1hdHRlciBpbiB3aGljaCBzaXR1YXRpb24uPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5SZS10YXJnZXRpbmcgYW5kIGZvcmtpbmcgJm5ic3A7aGFwcGVuIHRvIGJl IHRoZSBzY2VuYXJpb3MNCnRoYXQgZXNwZWNpYWxseSBiZW5lZml0IGZyb20gdGhlIGNoYW5nZS48 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBSZWdhcmRzfn5+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAtU3VqaW5nIFpob3U8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O0RhbiBXaW5nJnF1b3Q7ICZsdDtk d2luZ0BjaXNjby5jb20mZ3Q7INC009ogMjAxMi0wNC0xNw0KMDU6MTQ6NTg6PGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgZG9uJ3Qgc2VlIGhvdyBzZW5kaW5nIGFkZGl0aW9u YWwgcGFyYW1ldGVycyBzb2x2ZXMgdGhlDQpwcm9ibGVtLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgVGhlIHByb2JsZW0gaXMgdGhlIG9mZmVyZXIgY2Fubm90IGRldGVy bWluZSBpZiByZS10YXJnZXRpbmcNCm9yPGJyPg0KJmd0OyAmZ3Q7IGZvcmtpbmc8YnI+DQomZ3Q7 ICZndDsgJmd0OyBvY2N1cnJlZCwgYW5kIHRodXMgY2Fubm90IGRldGVybWluZSBpZiBpdCBuZWVk cyB0byBzZW5kDQphIG5ldzxicj4NCiZndDsgJmd0OyAodXBkYXRlZCk8YnI+DQomZ3Q7ICZndDsg Jmd0OyBvZmZlci4gJm5ic3A7VGhlIG9ubHkgc29sdXRpb24gaXMgdG8gYWx3YXlzIHNlbmQgYSBu ZXcgb2ZmZXIuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAtZDxicj4N CiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBG cm9tOiB6aG91LnN1amluZ0B6dGUuY29tLmNuIFttYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5j bl08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIg MTI6MjkgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBEYW4gV2luZzxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogSGksIE1heSBJIGFzayBmb3IgeW91ciBvcGluaW9uIG9u IGRyYWZ0LXpob3UtbW11c2ljLXNkZXMtPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBrZXltb2Qt MDE/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhpLCBXaW5nLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBJoaFoYXZlIHVwZGF0ZWQgbXkgZHJhZnQg aW5jb3Jwb3JhdGluZyB5b3VyDQpxdWVzdGlvbi48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpob3UtbW11c2ljLXNkZXMta2V5bW9kLTAx PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgTWF5IEkgYXNrIGZvciB5b3VyIG9waW5p b24gYW5kIGludGVyZXN0IGluIGl0Pzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IFRoYW5rIHlvdSE8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBSZWdhcmRzfn5+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgLVN1amluZyBaaG91PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcg0LTT 2iAyMDEyLTAzLTIxIDA5OjMyOjQwOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSGmjrCBX aW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgWW91ciBwb2ludCBpcyBnb29kLCBJIG1heSB1cGRhdGUNCm91 ciBkcmFmdCAoaW4gMDEgdmVyc2lvbik8YnI+DQomZ3Q7ICZndDsgbGlrZTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyB0aGUgZm9sbG93aW5nIHBhcmFncmFwaDo8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJnF1b3Q7IDMuMS4gJm5ic3A7R2VuZXJhdGluZyB0aGUgSW5pdGlhbCBP ZmZlcg0KLSBVbmljYXN0IFN0cmVhbXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RoZSBnZW5lcmF0aW9uIG9m IHRoZSBpbml0aWFsIG9mZmVyDQpmb3IgYSB1bmljYXN0IHN0cmVhbSBNVVNUPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBmb2xsb3c8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwO3RoYXQgb2YgdGhlIGNyeXB0byBhdHRyaWJ1dGUgUkZDNDU2OA0KW1JGQzQ1NjhdLCBh bmQgTUFZPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDthbHNvIGluY2x1ZGUgYW4gYWRkaXRpb25hbCAmcXVvdDtr ZXltb2QmcXVvdDsNCnBhcmFtZXRlciB3aXRoIGtleW1vZC12YWw8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGJlaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtO VUxMLiAmbmJzcDtJdCBpbmRpY2F0ZXMgdG8gdGhlIHVsdGltYXRlDQphbnN3ZXJlciB0aGF0IHRo ZSBvZmZlcmVyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB3YW50czxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dG8gZW1wbG95IHRoZSBtZWNoYW5pc20gc3BlY2lm aWVkDQppbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dGhpcyBkb2N1bWVudCwgYSBrZXkgYWdyZWVtZW50IG1l Y2hhbmlzbQ0Kd2l0aCBhIGhpZ2hlcjxicj4NCiZndDsgJmd0OyBzZWN1cml0eTxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgbGV2ZWw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwO3RoYW4gdGhlIG9yaWdpbmFsIFNERVMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBTbyB0aGF0IGFuc3dlcmVy IGRvZXMgbm90IG5lZWQgdG8ga25vdyBpdCBpcyBpbg0KYSByZS10YXJnZXRpbmcgb3I8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZm9ya2luZyBzY2VuYXJpbyw8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgaXQgaXMgb2ZmZXJlciBzdWdnZXN0aW5nIHVzZSBrZXltb2QgbWVjaGFu aXNtLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyBSZWdhcmRzfn5+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IC1TdWppbmcgWmhvdTxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmcXVvdDtEYW4gV2luZyZx dW90OyAmbHQ7ZHdpbmdAY2lzY28uY29tJmd0OyDQtNPaDQoyMDEyLTAzLTE4IDEwOjQzOjQyOjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFRvIGJlIGVmZmVjdGl2ZSwgZHJhZnQtemhvdS1tbXVzaWMtc2Rlcy1rZXltb2QNCm5l ZWRzIHRoZTxicj4NCiZndDsgJmd0OyBBbnN3ZXJlcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg dG8gc2VuZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSAmcXVvdDtrZXlt b2QmcXVvdDsgZXh0ZW5zaW9uIGlmIGl0IGtub3dzLA0Kb3IgYmVsaWV2ZXMsIHRoZSBJTlZJVEUg d2FzPGJyPg0KJmd0OyAmZ3Q7IHJlLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGFyZ2V0ZWQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBvciBmb3JrZWQuICZuYnNwO0kgaGF2 ZSB0d28gcXVlc3Rpb25zOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSSBzZWUgZm9yIHRoZSBkZXNjcmliZWQgcmUt dGFyZ2V0aW5nIGNhc2UNCihTZWN0aW9uIDUuMSBvZjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGRyYWZ0LXpob3UtbW11c2ljLXNkZXMta2V5bW9kLTAwKSwgYSAmcXVvdDtjYXVz ZSZxdW90Ow0KcGFyYW1ldGVyPGJyPg0KJmd0OyAmZ3Q7IFtSRkM0NDU4XTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgY2FuIGJlIGE8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB1 c2VmdWwgaW5kaWNhdG9yIHRoYXQgYSBjYWxsIHdhcyByZS10YXJnZXRlZC4NCiZuYnNwO0lzIHRo ZSAmcXVvdDtjYXVzZSZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcGFyYW1ldGVyPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYWx3YXlzIHByZXNlbnQgd2hlbiBhIGNh bGwgaXMgcmUtdGFyZ2V0ZWQ/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBIb3cgZG9lcyB0aGUgQW5zd2VyZXIga25v dyBpZiBhIGNhbGwgd2FzDQpmb3JrZWQ/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAtZDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyBtbXVzaWNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8YnI+DQomZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 000F7DFF482579E4_=-- From miguel.a.garcia@ericsson.com Wed Apr 18 05:46:28 2012 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 C77F421F8593 for ; Wed, 18 Apr 2012 05:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 AGI4vxEVWeWy for ; Wed, 18 Apr 2012 05:46:28 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7E21F858E for ; Wed, 18 Apr 2012 05:46:27 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-a0-4f8eb7a222cb Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CA.A5.03534.2A7BE8F4; Wed, 18 Apr 2012 14:46:27 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Wed, 18 Apr 2012 14:46:26 +0200 Message-ID: <4F8EB7A1.2050208@ericsson.com> Date: Wed, 18 Apr 2012 14:46:25 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mmusic References: <4F79A716.3080804@ericsson.com> In-Reply-To: <4F79A716.3080804@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" , Flemming Andreasen Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 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, 18 Apr 2012 12:46:28 -0000 The WGLC of draft-ietf-mmusic-media-loopback-18.txt has concluded. Thanks to all who provided comments. Please authors, address the issues discussed in the last call and submit a new version of the document as early as you can. /Miguel On 02/04/2012 15:18, Miguel A. Garcia wrote: > This is to start a 2-week Working Group Last Call for > > draft-ietf-mmusic-media-loopback-18.txt > > The WGLC ends on April 16th, 2012. > > Please reply to this e-mail to send comments, so that the authors and the > mailing list are all copied. > > /Miguel > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Apr 18 06:02:09 2012 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 9C84921F84DC for ; Wed, 18 Apr 2012 06:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 1kS4TvKfjifs for ; Wed, 18 Apr 2012 06:02:09 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BFD2321F8483 for ; Wed, 18 Apr 2012 06:02:08 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-6b-4f8ebb4fdbb5 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2F.F7.03534.F4BBE8F4; Wed, 18 Apr 2012 15:02:07 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Wed, 18 Apr 2012 15:02:07 +0200 Message-ID: <4F8EBB4E.7080804@ericsson.com> Date: Wed, 18 Apr 2012 15:02:06 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.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-rfc2326bis.authors@tools.ietf.org Subject: [MMUSIC] WGLC of draft-ietf-mmusic-rfc2326bis-29.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: Wed, 18 Apr 2012 13:02:09 -0000 This is to start a 4-week Working Group Last Call for draft-ietf-mmusic-rfc2326bis-29.txt The WGLC ends on May 16th, 2012. Notice that this is a special 4-week WGLC due to the length of the document. We would especially like reviewers to focus on the changes since the last WGLC, which was for version -23. Please reply to this e-mail that includes the authors and the mailing list. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From dwing@cisco.com Wed Apr 18 06:34:51 2012 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 EE98E21F84FD for ; Wed, 18 Apr 2012 06:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.624 X-Spam-Level: X-Spam-Status: No, score=-107.624 tagged_above=-999 required=5 tests=[AWL=-2.975, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, MANGLED_DIET=2.3, MIME_CHARSET_FARAWAY=2.45, 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 U1F+4PVSoBgf for ; Wed, 18 Apr 2012 06:34:47 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4C52D21F84F0 for ; Wed, 18 Apr 2012 06:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=7654; q=dns/txt; s=iport; t=1334756087; x=1335965687; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=flvWt6DXpy7j27jKBxS6lS618DI9gJJka2+O5PjZ7m0=; b=PXBRvZzY2ZsBb8fCpFUamTyFQSa89CDvYdLwWinSk66ZfqgMIJdCHTxd 8QjXJNKpICYQ/nzpFrDdPKz7PS5v/YwI2nfkShAU2NGCpbUQs3iVDOUlU dBNNEBaGqs2jLz8uLNZ3sQTus2RQo5l5BlVI3Mc57IqI7GBwQTYD54lsq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswGAHnCjk+rRDoG/2dsb2JhbABEhWabWY4LgXOBB4IJAQEBBAEBAQUKARdECwwBAwIHAg8CBAEBBSMFAhkOFQoJCAEBBBMLEAeHbAyaE40KCJMXgSuOIYEcBIhchRWJD41AgWmDB4E0Bw X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="38505730" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 18 Apr 2012 13:34:47 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3IDYkfY031391; Wed, 18 Apr 2012 13:34:46 GMT From: "Dan Wing" To: References: <034c01cd1cb0$b6add5c0$24098140$@com> In-Reply-To: Date: Wed, 18 Apr 2012 06:34:46 -0700 Message-ID: <079c01cd1d68$05710670$10531350$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0dDdDkXF46y+EFSzu5YpSjubGVjAAWf01A Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hi, May I ask for your opinion on draft-zhou-mmusic-sdes-keymod-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: Wed, 18 Apr 2012 13:34:52 -0000 > -----Original Message----- > From: zhou.sujing@zte.com.cn [mailto:zhou.sujing@zte.com.cn] > Sent: Tuesday, April 17, 2012 7:49 PM > To: Dan Wing > Cc: mmusic@ietf.org > Subject: RE: RE: RE: Hi, May I ask for your opinion on draft-zhou- > mmusic-sdes-keymod-01? >=20 >=20 > Regards~~~ >=20 > -Sujing Zhou >=20 > "Dan Wing" =D0=B4=D3=DA 2012-04-17 23:42:36: >=20 > > > -----Original Message----- > > > From: zhou.sujing@zte.com.cn [mailto:zhou.sujing@zte.com.cn] > > > Sent: Monday, April 16, 2012 10:10 PM > > > To: Dan Wing > > > Subject: =B4=F0=B8=B4: RE: Hi, May I ask for your opinion on = draft-zhou- > mmusic- > > > sdes-keymod-01? > > > > > > > > > Yes=A3=ACthe offer cannot determin if re-trageting or forking are > occuring. > > > I added a new parameter "keymod" with NULL=A1=A1value in the offer > message > > > (in 01 version) no matter wich scenarios, > > > to inform the answerer that > > > > > > "Hi, I am kind of concerned about my outgoing > > > message be intercept by some intermediates, so I am ready to = accept > any > > > answer message with > > > keymod parameter, if you send values in keymod parameter, I can > update > > > my key accordingly" > > > > > > It is up to the answerer to decide if it will send keymod = parameter > > > with valid value. > > > > > > If the answer does not care, it can send keymod with NULL value, > and > > > this case is the same as the current SDES; > > > If the answer cares, it can send keymod with non-NULL value, and > this > > > case is what our document is solving. > > > > > > The answerer may be able to detect it is in a re-targeting/forking > > > scenario, and be triggered to send keymod; > > > Or, the answerer could not detect the situation, and be encouraged > to > > > send keymod, because offerer asked for. > > > > The offerer should just always issue a re-Invite with a new = a=3Dcrypto > key. > > > > I guess you are trying to optimize that so that the offerer and > answerer > > somehow determine if a re-Invite might be necessary? Why not > generalize > > that optimization, so that the answerer indicates "re-direct > occurred" and > > indicates "forking occurred"? That could be useful for this SDESC > re-Invite > > optimization, and could be useful elsewhere. However, I believe it > is > > impossible for the Answerer to reliably determine if a re-direct > occurred or > > if forking occurred, which is why I have doubt that the proposal in > your I-D > > can work as you hope. > > > > -d >=20 > Let the offerer send a re-Invite or an UPDATE with a new a=3Dcrypto = key > is indeed an solution. > But it require more roundtrips. >=20 > Our motivations are > -to optimize the procedure > -to enhance the security of SDES >=20 > your question is around the applicability of the optimized procedure. > In the case of re-direct occurs, the anwser always knows it is a re- > directed call,should no problem, our 00 draft works. > In the case of forking, the answer does not know it is a forked call, > our 00 draft does not work in this case. >=20 > Our 01 verion does not let answer alone to determin if a re-direct or = a > forking occur. > Instead, our 01 version is a general upgrade to current SDES protocol, > that will come to our > another motivation :enhance the security of SDES >=20 > Generaly it is preferable the session key between two peers be > established with contribution from both peers,otherwise we will get > into trouble > as SDES now in the scenarios of re-targetting and forking. > Our 01 version actually suggests to change the unidirectional key > transport in SDES into a key agreement(indicated by "keymod"): > offerer provides: k1 > answer provides: keymod value > the outgoing key from offerer to answerer is derived from k1 and = keymod > value no matter in which situation. > Re-targeting and forking happen to be the scenarios that especially > benefit from the change. Which involves the same number of (signaling) round-trips, right? -d >=20 >=20 >=20 > > > > > > > > > > > > > Regards~~~ > > > > > > -Sujing Zhou > > > > > > "Dan Wing" =D0=B4=D3=DA 2012-04-17 05:14:58: > > > > > > > I don't see how sending additional parameters solves the = problem. > > > > > > > > The problem is the offerer cannot determine if re-targeting or > > > forking > > > > occurred, and thus cannot determine if it needs to send a new > > > (updated) > > > > offer. The only solution is to always send a new offer. > > > > > > > > -d > > > > > > > > > > > > > -----Original Message----- > > > > > From: zhou.sujing@zte.com.cn [mailto:zhou.sujing@zte.com.cn] > > > > > Sent: Monday, April 16, 2012 12:29 AM > > > > > To: Dan Wing > > > > > Subject: Hi, May I ask for your opinion on draft-zhou-mmusic- > sdes- > > > > > keymod-01? > > > > > > > > > > > > > > > Hi, Wing, > > > > > > > > > > I=A1=A1have updated my draft incorporating your question. > > > > > http://tools.ietf.org/html/draft-zhou-mmusic-sdes-keymod-01 > > > > > May I ask for your opinion and interest in it? > > > > > > > > > > Thank you! > > > > > > > > > > Regards~~~ > > > > > > > > > > -Sujing Zhou > > > > > > > > > > mmusic-bounces@ietf.org =D0=B4=D3=DA 2012-03-21 09:32:40: > > > > > > > > > > > > > > > > > Hi=A3=AC Wing > > > > > > > > > > > > Your point is good, I may update our draft (in 01 > version) > > > like > > > > > > the following paragraph: > > > > > > " 3.1. Generating the Initial Offer - Unicast Streams > > > > > > > > > > > > The generation of the initial offer for a unicast stream > MUST > > > > > follow > > > > > > that of the crypto attribute RFC4568 [RFC4568], and MAY > > > > > > > > > > > > also include an additional "keymod" parameter with = keymod- > val > > > > > being > > > > > > NULL. It indicates to the ultimate answerer that the > offerer > > > > > wants > > > > > > to employ the mechanism specified in > > > > > > > > > > > > this document, a key agreement mechanism with a higher > > > security > > > > > level > > > > > > than the original SDES. > > > > > > " > > > > > > So that answerer does not need to know it is in a re- > targeting or > > > > > > forking scenario, > > > > > > it is offerer suggesting use keymod mechanism. > > > > > > > > > > > > > > > > > > > > > > > > Regards~~~ > > > > > > > > > > > > -Sujing Zhou > > > > > > > > > > > > "Dan Wing" =D0=B4=D3=DA 2012-03-18 = 10:43:42: > > > > > > > > > > > > > To be effective, draft-zhou-mmusic-sdes-keymod needs the > > > Answerer > > > > > to send > > > > > > > the "keymod" extension if it knows, or believes, the = INVITE > was > > > re- > > > > > targeted > > > > > > > or forked. I have two questions: > > > > > > > > > > > > > > I see for the described re-targeting case (Section 5.1 of > > > > > > > draft-zhou-mmusic-sdes-keymod-00), a "cause" parameter > > > [RFC4458] > > > > > can be a > > > > > > > useful indicator that a call was re-targeted. Is the > "cause" > > > > > parameter > > > > > > > always present when a call is re-targeted? > > > > > > > > > > > > > > How does the Answerer know if a call was forked? > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > mmusic mailing list > > > > > > mmusic@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > > > > From HKaplan@acmepacket.com Wed Apr 18 08:01:48 2012 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 C80DD21F85D2 for ; Wed, 18 Apr 2012 08:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 Bm4soxgGQark for ; Wed, 18 Apr 2012 08:01:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AAF7A21F84F1 for ; Wed, 18 Apr 2012 08:01:44 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 18 Apr 2012 11:01:43 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.74]) by Mail1.acmepacket.com ([169.254.1.36]) with mapi id 14.02.0283.003; Wed, 18 Apr 2012 11:01:43 -0400 From: Hadriel Kaplan To: "Miguel A. Garcia" Thread-Topic: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 Thread-Index: AQHNHXQp1xP3gqJliEW2DEnhPyPlqA== Date: Wed, 18 Apr 2012 15:01:41 +0000 Message-ID: <372F4488-3C2B-4062-B9BE-E5097ED88FB7@acmepacket.com> References: <4F79A716.3080804@ericsson.com> <4F8EB7A1.2050208@ericsson.com> In-Reply-To: <4F8EB7A1.2050208@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" , Flemming Andreasen , mmusic Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18 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, 18 Apr 2012 15:01:48 -0000 Roger, will do. We still have on open issue on the congestion stuff, however. -hadriel On Apr 18, 2012, at 8:46 AM, Miguel A. Garcia wrote: > The WGLC of draft-ietf-mmusic-media-loopback-18.txt has concluded. Thanks= to all who provided comments. >=20 > Please authors, address the issues discussed in the last call and submit = a new version of the document as early as you can. >=20 > /Miguel >=20 > On 02/04/2012 15:18, Miguel A. Garcia wrote: >> This is to start a 2-week Working Group Last Call for >>=20 >> draft-ietf-mmusic-media-loopback-18.txt >>=20 >> The WGLC ends on April 16th, 2012. >>=20 >> Please reply to this e-mail to send comments, so that the authors and th= e >> mailing list are all copied. >>=20 >> /Miguel >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From zhou.sujing@zte.com.cn Wed Apr 18 17:47:59 2012 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 2472221F847F for ; Wed, 18 Apr 2012 17:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.98 X-Spam-Level: X-Spam-Status: No, score=-98.98 tagged_above=-999 required=5 tests=[AWL=2.858, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 BwVJzrUBAHK2 for ; Wed, 18 Apr 2012 17:47:58 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 28F6B21F847E for ; Wed, 18 Apr 2012 17:47:58 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620978252052; Thu, 19 Apr 2012 08:08:49 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 89645.2712434073; Thu, 19 Apr 2012 08:47:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3J0lkUd092463; Thu, 19 Apr 2012 08:47:46 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <079c01cd1d68$05710670$10531350$@com> To: "Dan Wing" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 19 Apr 2012 08:47:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-19 08:47:46, Serialize complete at 2012-04-19 08:47:46 Content-Type: multipart/alternative; boundary="=_alternative 000465DE482579E5_=" X-MAIL: mse01.zte.com.cn q3J0lkUd092463 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hi, May I ask for your opinion on draft-zhou-mmusic-sdes-keymod-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: Thu, 19 Apr 2012 00:47:59 -0000 This is a multipart message in MIME format. --=_alternative 000465DE482579E5_= Content-Type: text/plain; charset="US-ASCII" > > > > Generaly it is preferable the session key between two peers be > > established with contribution from both peers,otherwise we will get > > into trouble > > as SDES now in the scenarios of re-targetting and forking. > > Our 01 version actually suggests to change the unidirectional key > > transport in SDES into a key agreement(indicated by "keymod"): > > offerer provides: k1 > > answer provides: keymod value > > the outgoing key from offerer to answerer is derived from k1 and keymod > > value no matter in which situation. > > Re-targeting and forking happen to be the scenarios that especially > > benefit from the change. > > Which involves the same number of (signaling) round-trips, right? In my opinion, the new method does not add extra round trips, it has the same round trips with the current SDES without re-INVITE or UPDATE. offerer-->answerer:INVITE a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 --->k1 keymod:rand|xor| offerer<--answerer:Response a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32; --->k2 keymod:rand|xor|WVNfX19zZW1jdGwgKCkgew== ->keymod value after the single round, k1 and keymod value-->k1' to protect session from offerer to answerer k2 --> to protect session from answerer to offerer > > -d --=_alternative 000465DE482579E5_= Content-Type: text/html; charset="US-ASCII"

> >
> > Generaly it is preferable the session key  between two peers  be
> > established with contribution from both peers,otherwise we will get
> > into trouble
> > as  SDES now in the scenarios of re-targetting and forking.
> > Our 01 version actually suggests to change the unidirectional key
> > transport in SDES into a key agreement(indicated by "keymod"):
> > offerer provides: k1
> > answer provides: keymod value
> > the outgoing key from offerer to answerer is derived from k1 and keymod
> > value no matter in which situation.
> > Re-targeting and forking  happen to be the scenarios that especially
> > benefit from the change.
>
> Which involves the same number of (signaling) round-trips, right?
In my opinion, the new method does not add extra round trips, it has the same round trips with
the current SDES without re-INVITE or UPDATE.

offerer-->answerer:INVITE
       a=crypto:1 AES_CM_128_HMAC_SHA1_80
        inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 --->k1
        keymod:rand|xor|
offerer<--answerer:Response
       a=crypto:1 AES_CM_128_HMAC_SHA1_32
       inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32; --->k2
       keymod:rand|xor|WVNfX19zZW1jdGwgKCkgew==         ->keymod value

after the single round,
    k1 and keymod value-->k1' to protect session from offerer to answerer
   k2 -->  to protect session from answerer   to offerer

>
> -d
 --=_alternative 000465DE482579E5_=-- From dwing@cisco.com Wed Apr 18 18:32:45 2012 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 E566B11E80AD for ; Wed, 18 Apr 2012 18:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.607 X-Spam-Level: X-Spam-Status: No, score=-109.607 tagged_above=-999 required=5 tests=[AWL=0.992, BAYES_00=-2.599, 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 MOiwQ+935fjX for ; Wed, 18 Apr 2012 18:32:40 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B639011E809D for ; Wed, 18 Apr 2012 18:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2122; q=dns/txt; s=iport; t=1334799160; x=1336008760; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=lRYh/qXUFdg9F33U6udaEKU/dKFXLFwtQqN7QmTa4/0=; b=Tw0awpCrCkGP4dRNwpzUq750r4mbyP7A6aXWBs8N3AeejL+xY1PtAiYB ncAad2FVZ4sVo0g3fqjEaCUK4WRm+C49qrnEXi2LNroOr1Vj/S/kwPy4b qbUb+Ms2jy1bUJPwkgeN6IUPGeck0dCRgPFy/GOVMyI5Po4wCphyrvGgs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYGADZqj0+rRDoJ/2dsb2JhbABDoUiOCwGBcYEHggkBAQEECAoBFAMQPwwBAwIJDwIEAQEoBxkjCgkIAQEEEwsXh2yaWqArjRCDJQSIXIUVlk+BaYMH X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="41096256" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 19 Apr 2012 01:32:40 +0000 Received: from dwingWS ([10.154.161.65]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3J1WeUM012419; Thu, 19 Apr 2012 01:32:40 GMT From: "Dan Wing" To: References: <079c01cd1d68$05710670$10531350$@com> In-Reply-To: Date: Wed, 18 Apr 2012 18:32:40 -0700 Message-ID: <0b9d01cd1dcc$4f46db30$edd49190$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0dxhI39cuFZOe6Tt6wNzeqOwY8iwABcwiA Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hi, May I ask for your opinion on draft-zhou-mmusic-sdes-keymod-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: Thu, 19 Apr 2012 01:32:45 -0000 > -----Original Message----- > From: zhou.sujing@zte.com.cn [mailto:zhou.sujing@zte.com.cn] > Sent: Wednesday, April 18, 2012 5:48 PM > To: Dan Wing > Cc: mmusic@ietf.org > Subject: Re: RE: RE: RE: Hi, May I ask for your opinion on draft-zhou- > mmusic-sdes-keymod-01? > > > > > > > > > Generaly it is preferable the session key between two peers be > > > established with contribution from both peers,otherwise we will get > > > into trouble > > > as SDES now in the scenarios of re-targetting and forking. > > > Our 01 version actually suggests to change the unidirectional key > > > transport in SDES into a key agreement(indicated by "keymod"): > > > offerer provides: k1 > > > answer provides: keymod value > > > the outgoing key from offerer to answerer is derived from k1 and > keymod > > > value no matter in which situation. > > > Re-targeting and forking happen to be the scenarios that > especially > > > benefit from the change. > > > > Which involves the same number of (signaling) round-trips, right? > > In my opinion, the new method does not add extra round trips, it has > the same round trips with > the current SDES without re-INVITE or UPDATE. > > offerer-->answerer:INVITE > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 --- > >k1 > keymod:rand|xor| > offerer<--answerer:Response > a=crypto:1 AES_CM_128_HMAC_SHA1_32 > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32; --- > >k2 > keymod:rand|xor|WVNfX19zZW1jdGwgKCkgew== ->keymod value > > after the single round, > k1 and keymod value-->k1' to protect session from offerer to > answerer > k2 --> to protect session from answerer to offerer I now understand what you're proposing, thanks for explaining it this way. That avoids a signaling round trip, but does require the Offerer and Answerer support keymod. If either of them don't, the Offerer needs to always do a re-Invite. So this appears a reasonable optimization to avoid always doing a re-Invite. -d From zhou.sujing@zte.com.cn Wed Apr 18 20:14:12 2012 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 EEDD511E8086 for ; Wed, 18 Apr 2012 20:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.864 X-Spam-Level: X-Spam-Status: No, score=-94.864 tagged_above=-999 required=5 tests=[AWL=-2.074, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 2OXerN1LwmCQ for ; Wed, 18 Apr 2012 20:14:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C572111E80B5 for ; Wed, 18 Apr 2012 20:14:10 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620978252052; Thu, 19 Apr 2012 10:34:53 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 89645.2712434073; Thu, 19 Apr 2012 11:13:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3J3Dmgp079617; Thu, 19 Apr 2012 11:13:48 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <0b9d01cd1dcc$4f46db30$edd49190$@com> To: "Dan Wing" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 19 Apr 2012 11:13:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-19 11:13:49, Serialize complete at 2012-04-19 11:13:49 Content-Type: multipart/alternative; boundary="=_alternative 0011C4E5482579E5_=" X-MAIL: mse02.zte.com.cn q3J3Dmgp079617 Cc: mmusic@ietf.org Subject: [MMUSIC] =?gb2312?b?tPC4tDogUkU6IFJFOiBSRTogUkU6IEhpLCBNYXkgSSBh?= =?gb2312?b?c2sgZm9yIHlvdXIgb3BpbmlvbiBvbiBkcmFmdC16aG91LW1tdXNpYy1zZGVz?= =?gb2312?b?LWtleW1vZC0wMT8=?= 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, 19 Apr 2012 03:14:12 -0000 This is a multipart message in MIME format. --=_alternative 0011C4E5482579E5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlbiBkbyB5b3VyIHN1cHBvcnQgb3VyIGRyYWZ0IGJlaW5nIGNvbnNpZGVyZWQgaW50byBhIFdH o6htbXVzaWOjqSB3b3JrIA0KaXRlbaO/DQoNCg0KUmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UN Cg0KIkRhbiBXaW5nIiA8ZHdpbmdAY2lzY28uY29tPiDQtNPaIDIwMTItMDQtMTkgMDk6MzI6NDA6 DQoNCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHpob3Uuc3VqaW5n QHp0ZS5jb20uY24gW21haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuXQ0KPiA+IFNlbnQ6IFdl ZG5lc2RheSwgQXByaWwgMTgsIDIwMTIgNTo0OCBQTQ0KPiA+IFRvOiBEYW4gV2luZw0KPiA+IENj OiBtbXVzaWNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogUkU6IFJFOiBSRTogSGksIE1heSBJ IGFzayBmb3IgeW91ciBvcGluaW9uIG9uIGRyYWZ0LXpob3UtDQo+ID4gbW11c2ljLXNkZXMta2V5 bW9kLTAxPw0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ID4gPg0KPiA+ID4gPiBHZW5lcmFseSBpdCBp cyBwcmVmZXJhYmxlIHRoZSBzZXNzaW9uIGtleSAgYmV0d2VlbiB0d28gcGVlcnMgIGJlDQo+ID4g PiA+IGVzdGFibGlzaGVkIHdpdGggY29udHJpYnV0aW9uIGZyb20gYm90aCBwZWVycyxvdGhlcndp c2Ugd2Ugd2lsbCANCmdldA0KPiA+ID4gPiBpbnRvIHRyb3VibGUNCj4gPiA+ID4gYXMgIFNERVMg bm93IGluIHRoZSBzY2VuYXJpb3Mgb2YgcmUtdGFyZ2V0dGluZyBhbmQgZm9ya2luZy4NCj4gPiA+ ID4gT3VyIDAxIHZlcnNpb24gYWN0dWFsbHkgc3VnZ2VzdHMgdG8gY2hhbmdlIHRoZSB1bmlkaXJl Y3Rpb25hbCBrZXkNCj4gPiA+ID4gdHJhbnNwb3J0IGluIFNERVMgaW50byBhIGtleSBhZ3JlZW1l bnQoaW5kaWNhdGVkIGJ5ICJrZXltb2QiKToNCj4gPiA+ID4gb2ZmZXJlciBwcm92aWRlczogazEN Cj4gPiA+ID4gYW5zd2VyIHByb3ZpZGVzOiBrZXltb2QgdmFsdWUNCj4gPiA+ID4gdGhlIG91dGdv aW5nIGtleSBmcm9tIG9mZmVyZXIgdG8gYW5zd2VyZXIgaXMgZGVyaXZlZCBmcm9tIGsxIGFuZA0K PiA+IGtleW1vZA0KPiA+ID4gPiB2YWx1ZSBubyBtYXR0ZXIgaW4gd2hpY2ggc2l0dWF0aW9uLg0K PiA+ID4gPiBSZS10YXJnZXRpbmcgYW5kIGZvcmtpbmcgIGhhcHBlbiB0byBiZSB0aGUgc2NlbmFy aW9zIHRoYXQNCj4gPiBlc3BlY2lhbGx5DQo+ID4gPiA+IGJlbmVmaXQgZnJvbSB0aGUgY2hhbmdl Lg0KPiA+ID4NCj4gPiA+IFdoaWNoIGludm9sdmVzIHRoZSBzYW1lIG51bWJlciBvZiAoc2lnbmFs aW5nKSByb3VuZC10cmlwcywgcmlnaHQ/DQo+ID4gDQo+ID4gSW4gbXkgb3BpbmlvbiwgdGhlIG5l dyBtZXRob2QgZG9lcyBub3QgYWRkIGV4dHJhIHJvdW5kIHRyaXBzLCBpdCBoYXMNCj4gPiB0aGUg c2FtZSByb3VuZCB0cmlwcyB3aXRoDQo+ID4gdGhlIGN1cnJlbnQgU0RFUyB3aXRob3V0IHJlLUlO VklURSBvciBVUERBVEUuDQo+ID4gDQo+ID4gb2ZmZXJlci0tPmFuc3dlcmVyOklOVklURQ0KPiA+ ICAgICAgICBhPWNyeXB0bzoxIEFFU19DTV8xMjhfSE1BQ19TSEExXzgwDQo+ID4gICAgICAgICBp bmxpbmU6ZDBSbWRtY21WQ3NwZUVjM1FHWmlOV3BWTEZKaFFYMWNmSEF3SlNvanwyXjIwfDE6MzIg LS0tDQo+ID4gPmsxDQo+ID4gICAgICAgICBrZXltb2Q6cmFuZHx4b3J8DQo+ID4gb2ZmZXJlcjwt LWFuc3dlcmVyOlJlc3BvbnNlDQo+ID4gICAgICAgIGE9Y3J5cHRvOjEgQUVTX0NNXzEyOF9ITUFD X1NIQTFfMzINCj4gPiAgICAgICAgaW5saW5lOk56QjRkMUJJTlVBdkxFdzZVekYzV1NKK1BTZEZj R2RVSlNocFgxWmp8Ml4yMHwxOjMyOyAtLS0NCj4gPiA+azINCj4gPiAgICAgICAga2V5bW9kOnJh bmR8eG9yfFdWTmZYMTl6WlcxamRHd2dLQ2tnZXc9PSAgICAgICAgIC0+a2V5bW9kIHZhbHVlDQo+ ID4gDQo+ID4gYWZ0ZXIgdGhlIHNpbmdsZSByb3VuZCwNCj4gPiAgICAgazEgYW5kIGtleW1vZCB2 YWx1ZS0tPmsxJyB0byBwcm90ZWN0IHNlc3Npb24gZnJvbSBvZmZlcmVyIHRvDQo+ID4gYW5zd2Vy ZXINCj4gPiAgICBrMiAtLT4gIHRvIHByb3RlY3Qgc2Vzc2lvbiBmcm9tIGFuc3dlcmVyICAgdG8g b2ZmZXJlcg0KPiANCj4gSSBub3cgdW5kZXJzdGFuZCB3aGF0IHlvdSdyZSBwcm9wb3NpbmcsIHRo YW5rcyBmb3IgZXhwbGFpbmluZyBpdCB0aGlzIA0Kd2F5Lg0KPiANCj4gVGhhdCBhdm9pZHMgYSBz aWduYWxpbmcgcm91bmQgdHJpcCwgYnV0IGRvZXMgcmVxdWlyZSB0aGUgT2ZmZXJlciBhbmQNCj4g QW5zd2VyZXIgc3VwcG9ydCBrZXltb2QuICBJZiBlaXRoZXIgb2YgdGhlbSBkb24ndCwgdGhlIE9m ZmVyZXIgbmVlZHMgdG8NCj4gYWx3YXlzIGRvIGEgcmUtSW52aXRlLiAgU28gdGhpcyBhcHBlYXJz IGEgcmVhc29uYWJsZSBvcHRpbWl6YXRpb24gdG8gDQphdm9pZA0KPiBhbHdheXMgZG9pbmcgYSBy ZS1JbnZpdGUuDQo+IA0KPiAtZA0KPiANCj4gDQo+IA0KDQo= --=_alternative 0011C4E5482579E5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZW4gZG8geW91ciBzdXBwb3J0 IG91ciBkcmFmdCBiZWluZw0KY29uc2lkZXJlZCBpbnRvIGEgV0ejqG1tdXNpY6OpIHdvcmsgaXRl baO/PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5SZWdhcmRzfn5+PGJyPg0KPGJyPg0KLVN1amluZyBaaG91PC9mb250Pg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+JnF1b3Q7RGFuIFdpbmcmcXVvdDsgJmx0O2R3aW5nQGNpc2NvLmNvbSZn dDsg0LTT2g0KMjAxMi0wNC0xOSAwOTozMjo0MDo8YnI+DQo8YnI+DQomZ3Q7ICZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogemhvdS5zdWppbmdAenRl LmNvbS5jbiBbbWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY25dPGJyPg0KJmd0OyAmZ3Q7IFNl bnQ6IFdlZG5lc2RheSwgQXByaWwgMTgsIDIwMTIgNTo0OCBQTTxicj4NCiZndDsgJmd0OyBUbzog RGFuIFdpbmc8YnI+DQomZ3Q7ICZndDsgQ2M6IG1tdXNpY0BpZXRmLm9yZzxicj4NCiZndDsgJmd0 OyBTdWJqZWN0OiBSZTogUkU6IFJFOiBSRTogSGksIE1heSBJIGFzayBmb3IgeW91ciBvcGluaW9u IG9uIGRyYWZ0LXpob3UtPGJyPg0KJmd0OyAmZ3Q7IG1tdXNpYy1zZGVzLWtleW1vZC0wMT88YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBHZW5lcmFseSBpdCBpcyBwcmVm ZXJhYmxlIHRoZSBzZXNzaW9uIGtleSAmbmJzcDtiZXR3ZWVuDQp0d28gcGVlcnMgJm5ic3A7YmU8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGVzdGFibGlzaGVkIHdpdGggY29udHJpYnV0aW9uIGZy b20gYm90aCBwZWVycyxvdGhlcndpc2UNCndlIHdpbGwgZ2V0PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBpbnRvIHRyb3VibGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFzICZuYnNwO1NERVMg bm93IGluIHRoZSBzY2VuYXJpb3Mgb2YgcmUtdGFyZ2V0dGluZw0KYW5kIGZvcmtpbmcuPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBPdXIgMDEgdmVyc2lvbiBhY3R1YWxseSBzdWdnZXN0cyB0byBj aGFuZ2UgdGhlIHVuaWRpcmVjdGlvbmFsDQprZXk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRy YW5zcG9ydCBpbiBTREVTIGludG8gYSBrZXkgYWdyZWVtZW50KGluZGljYXRlZCBieQ0KJnF1b3Q7 a2V5bW9kJnF1b3Q7KTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9mZmVyZXIgcHJvdmlkZXM6 IGsxPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhbnN3ZXIgcHJvdmlkZXM6IGtleW1vZCB2YWx1 ZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIG91dGdvaW5nIGtleSBmcm9tIG9mZmVyZXIg dG8gYW5zd2VyZXIgaXMgZGVyaXZlZA0KZnJvbSBrMSBhbmQ8YnI+DQomZ3Q7ICZndDsga2V5bW9k PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB2YWx1ZSBubyBtYXR0ZXIgaW4gd2hpY2ggc2l0dWF0 aW9uLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgUmUtdGFyZ2V0aW5nIGFuZCBmb3JraW5nICZu YnNwO2hhcHBlbiB0byBiZSB0aGUgc2NlbmFyaW9zDQp0aGF0PGJyPg0KJmd0OyAmZ3Q7IGVzcGVj aWFsbHk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJlbmVmaXQgZnJvbSB0aGUgY2hhbmdlLjxi cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2hpY2ggaW52b2x2ZXMgdGhl IHNhbWUgbnVtYmVyIG9mIChzaWduYWxpbmcpIHJvdW5kLXRyaXBzLA0KcmlnaHQ/PGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbiBteSBvcGluaW9uLCB0aGUgbmV3IG1ldGhvZCBkb2Vz IG5vdCBhZGQgZXh0cmEgcm91bmQgdHJpcHMsDQppdCBoYXM8YnI+DQomZ3Q7ICZndDsgdGhlIHNh bWUgcm91bmQgdHJpcHMgd2l0aDxicj4NCiZndDsgJmd0OyB0aGUgY3VycmVudCBTREVTIHdpdGhv dXQgcmUtSU5WSVRFIG9yIFVQREFURS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IG9m ZmVyZXItLSZndDthbnN3ZXJlcjpJTlZJVEU8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7YT1jcnlwdG86MSBBRVNfQ01fMTI4X0hNQUNfU0hBMV84MDxicj4NCiZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5saW5lOmQwUm1kbWNtVkNzcGVFYzNR R1ppTldwVkxGSmhRWDFjZkhBd0pTb2p8Ml4yMHwxOjMyDQotLS08YnI+DQomZ3Q7ICZndDsgJmd0 O2sxPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBrZXltb2Q6cmFu ZHx4b3J8PGJyPg0KJmd0OyAmZ3Q7IG9mZmVyZXImbHQ7LS1hbnN3ZXJlcjpSZXNwb25zZTxicj4N CiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthPWNyeXB0bzoxIEFFU19DTV8x MjhfSE1BQ19TSEExXzMyPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2lubGluZTpOekI0ZDFCSU5VQXZMRXc2VXpGM1dTSitQU2RGY0dkVUpTaHBYMVpqfDJeMjB8MToz MjsNCi0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7azI8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7a2V5bW9kOnJhbmR8eG9yfFdWTmZYMTl6WlcxamRHd2dLQ2tnZXc9PQ0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7a2V5bW9kIHZhbHVlPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyBhZnRlciB0aGUgc2luZ2xlIHJvdW5kLDxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7IGsxIGFuZCBrZXltb2QgdmFsdWUtLSZndDtrMScgdG8gcHJvdGVjdCBz ZXNzaW9uDQpmcm9tIG9mZmVyZXIgdG88YnI+DQomZ3Q7ICZndDsgYW5zd2VyZXI8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwO2syIC0tJmd0OyAmbmJzcDt0byBwcm90ZWN0IHNlc3Npb24gZnJv bSBhbnN3ZXJlcg0KJm5ic3A7IHRvIG9mZmVyZXI8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBub3cg dW5kZXJzdGFuZCB3aGF0IHlvdSdyZSBwcm9wb3NpbmcsIHRoYW5rcyBmb3IgZXhwbGFpbmluZyBp dCB0aGlzDQp3YXkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYXQgYXZvaWRzIGEgc2lnbmFsaW5n IHJvdW5kIHRyaXAsIGJ1dCBkb2VzIHJlcXVpcmUgdGhlIE9mZmVyZXIgYW5kPGJyPg0KJmd0OyBB bnN3ZXJlciBzdXBwb3J0IGtleW1vZC4gJm5ic3A7SWYgZWl0aGVyIG9mIHRoZW0gZG9uJ3QsIHRo ZSBPZmZlcmVyDQpuZWVkcyB0bzxicj4NCiZndDsgYWx3YXlzIGRvIGEgcmUtSW52aXRlLiAmbmJz cDtTbyB0aGlzIGFwcGVhcnMgYSByZWFzb25hYmxlIG9wdGltaXphdGlvbg0KdG8gYXZvaWQ8YnI+ DQomZ3Q7IGFsd2F5cyBkb2luZyBhIHJlLUludml0ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgLWQ8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 0011C4E5482579E5_=-- From magnus.westerlund@ericsson.com Thu Apr 19 02:10:24 2012 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 041B121F85C3 for ; Thu, 19 Apr 2012 02:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 l2CH5BXnRfl9 for ; Thu, 19 Apr 2012 02:10:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ABB7921F8596 for ; Thu, 19 Apr 2012 02:10:19 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-14-4f8fd6792cf4 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FC.78.25560.976DF8F4; Thu, 19 Apr 2012 11:10:18 +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.213.0; Thu, 19 Apr 2012 11:10:17 +0200 Message-ID: <4F8FD679.9050304@ericsson.com> Date: Thu, 19 Apr 2012 11:10:17 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <4F8EBB4E.7080804@ericsson.com> In-Reply-To: <4F8EBB4E.7080804@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-rfc2326bis-29.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, 19 Apr 2012 09:10:24 -0000 On 2012-04-18 15:02, Miguel A. Garcia wrote: > This is to start a 4-week Working Group Last Call for > > draft-ietf-mmusic-rfc2326bis-29.txt > > The WGLC ends on May 16th, 2012. Notice that this is a special 4-week > WGLC due to the length of the document. > > We would especially like reviewers to focus on the changes since the last > WGLC, which was for version -23. > > Please reply to this e-mail that includes the authors and the mailing list. Hi, As an author I can post the link of the Diff between 23 and now: https://tools.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rfc2326bis-23&difftype=--html&submit=Go!&url2=draft-ietf-mmusic-rfc2326bis-29 This is quite a substantiall amount of changes. Unfortunately the section reordering makes it difficult to spot changes in some sub-sections. 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 dwing@cisco.com Thu Apr 19 08:26:09 2012 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 7765321F864C for ; Thu, 19 Apr 2012 08:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.63 X-Spam-Level: X-Spam-Status: No, score=-108.63 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 BvirtV3AdRBg for ; Thu, 19 Apr 2012 08:26:05 -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 DF7A121F863E for ; Thu, 19 Apr 2012 08:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2985; q=dns/txt; s=iport; t=1334849164; x=1336058764; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=mIwRvuYuOJ54A2P3GHdU4oUmMTq49G6Ub7nwcCGD5HA=; b=F96iL67w3D1a3FZBg3prxc/eYCy0WQapdFeJEBRpRTJt3eEzbodhZA64 MoOk6fRFx7RlAkvJ8+axlpwRD44JNqABX30RWgVA1FA/KsSjjPPMxCLXM g43QNIUFM+UCu5pQNUsmB3zMi8VWfYza6bZqvx6EcmB3fnfMMFZMSNydX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgGADQukE+rRDoI/2dsb2JhbABDhWWbYo4EAQGBdYEHggkBAQEDAQgKARQDTwwBAwIHAg8CBAEBBSMFAhkjCgkIAQEEEwsXh2gEmlKNCgiTFoEri22CCYEcBIhchRWWUIFpgwc X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="41274002" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 19 Apr 2012 15:26:03 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3JFQ34C023554; Thu, 19 Apr 2012 15:26:03 GMT From: "Dan Wing" To: References: <0b9d01cd1dcc$4f46db30$edd49190$@com> In-Reply-To: Date: Thu, 19 Apr 2012 08:26:03 -0700 Message-ID: <0d4a01cd1e40$bba18f40$32e4adc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0d2njHnAUOy8ujT4ivOMGscuEDLAAZjvlg Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hi, May I ask for your opinion on draft-zhou-mmusic-sdes-keymod-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: Thu, 19 Apr 2012 15:26:09 -0000 > -----Original Message----- > From: zhou.sujing@zte.com.cn [mailto:zhou.sujing@zte.com.cn] > Sent: Wednesday, April 18, 2012 8:14 PM > To: Dan Wing > Cc: mmusic@ietf.org > Subject: =B4=F0=B8=B4: RE: RE: RE: RE: Hi, May I ask for your opinion = on draft- > zhou-mmusic-sdes-keymod-01? >=20 >=20 > Then do your support our draft being considered into a = WG=A3=A8mmusic=A3=A9 > work item=A3=BF It should be considered, yes. -d >=20 > Regards~~~ >=20 > -Sujing Zhou >=20 > "Dan Wing" =D0=B4=D3=DA 2012-04-19 09:32:40: >=20 > > > -----Original Message----- > > > From: zhou.sujing@zte.com.cn [mailto:zhou.sujing@zte.com.cn] > > > Sent: Wednesday, April 18, 2012 5:48 PM > > > To: Dan Wing > > > Cc: mmusic@ietf.org > > > Subject: Re: RE: RE: RE: Hi, May I ask for your opinion on draft- > zhou- > > > mmusic-sdes-keymod-01? > > > > > > > > > > > > > > > > > > > Generaly it is preferable the session key between two peers > be > > > > > established with contribution from both peers,otherwise we = will > get > > > > > into trouble > > > > > as SDES now in the scenarios of re-targetting and forking. > > > > > Our 01 version actually suggests to change the unidirectional > key > > > > > transport in SDES into a key agreement(indicated by "keymod"): > > > > > offerer provides: k1 > > > > > answer provides: keymod value > > > > > the outgoing key from offerer to answerer is derived from k1 > and > > > keymod > > > > > value no matter in which situation. > > > > > Re-targeting and forking happen to be the scenarios that > > > especially > > > > > benefit from the change. > > > > > > > > Which involves the same number of (signaling) round-trips, = right? > > > > > > In my opinion, the new method does not add extra round trips, it > has > > > the same round trips with > > > the current SDES without re-INVITE or UPDATE. > > > > > > offerer-->answerer:INVITE > > > a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_80 > > > inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 = - > -- > > > >k1 > > > keymod:rand|xor| > > > offerer<--answerer:Response > > > a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32; = - > -- > > > >k2 > > > keymod:rand|xor|WVNfX19zZW1jdGwgKCkgew=3D=3D = ->keymod > value > > > > > > after the single round, > > > k1 and keymod value-->k1' to protect session from offerer to > > > answerer > > > k2 --> to protect session from answerer to offerer > > > > I now understand what you're proposing, thanks for explaining it = this > way. > > > > That avoids a signaling round trip, but does require the Offerer and > > Answerer support keymod. If either of them don't, the Offerer needs > to > > always do a re-Invite. So this appears a reasonable optimization to > avoid > > always doing a re-Invite. > > > > -d > > > > > > From harald@alvestrand.no Thu Apr 19 08:34:04 2012 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 EA45F21F86A8 for ; Thu, 19 Apr 2012 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.213 X-Spam-Level: X-Spam-Status: No, score=-110.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, 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 IS2weyxwcT1A for ; Thu, 19 Apr 2012 08:34:03 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CA17F21F8698 for ; Thu, 19 Apr 2012 08:34:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F66939E146 for ; Thu, 19 Apr 2012 17:34:02 +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 kC-l1vPdj5Yk for ; Thu, 19 Apr 2012 17:34:01 +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 ESMTPSA id 7306239E098 for ; Thu, 19 Apr 2012 17:34:01 +0200 (CEST) Message-ID: <4F903069.8030705@alvestrand.no> Date: Thu, 19 Apr 2012 17:34:01 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RFC 6263 - interpretation validation: "a=imageattr" is advisory, not mandatory 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, 19 Apr 2012 15:34:04 -0000 Hello MMUSICers, Roni Even and I just had a discussion on the rtcweb list, which led to an interesting conclusion with regard to the meaning of a=imageattr from RFC 6236. My question (part of a thread) was: > I interpret the example in 4.2.1 (second alternative) as consisting of > 4 messages; in an offer/answer exchange, this would look like: > > 1) Alice -> Bob: OFFER > a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \ > recv [x=330,y=250] > 2) Bob -> Alice: ANSWER > a=imageattr:97 recv [x=800,y=640,sar=1.1] \ > send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]] > 3) Alice -> Bob: OFFER (re-invite, probably) > a=imageattr:97 send [x=800,y=640,sar=1.1] \ > recv [x=336,y=256] > 4) Bob -> Alice: ANSWER > a=imageattr:97 recv [x=800,y=640,sar=1.1] \ > send [x=336,y=256] > > So after message 2, Bob cannot send anything, since he can't reproduce > what Alice asked for, right? > > And after message 2, Alice can only send 800x640 with a sar of 1.1, > right? It's forbidden for Alice to send a noncompensated image, or a > 640x480 image? > > Again, it's the use of the words "wishes" and "desires" that I want to > be sure I understand correctly - as used in RFC 6236, they both mean > "demand" / "require" / "MUST". Right? > Roni's response was: > This is a good question, my view will be that since Alice gave a preference > like profile and level (and maybe bandwidth) in the original offer than Bob > can send any video that will be within this level. The image attribute says > that Alice prefers to get something specific to help with processing (note > that Alice can limit the received video by using max-mbps and max-fs for > H.264). It may be good to discuss it with others from MMUSIC. > The usage of the image attribute in my view is more relevant to allow the > receiver to ask for a specific image size since this is not defined in H.264 > (in H.263 you can specify the common specific resolutions and frame rate > using the optional parameters in RFC 4629). This was a requirement to allow > a receiver to ask for a specific size. > The usage of "wish" was because H.264 encoder is not required to support > scale to a specific resolution and a compliant decoder must support > everything within the negotiated profile and level. So when a receiver asks > for a size it can happen only if the encoder can do it but if the encoder > cannot it is still compliant. If this interpretation is correct, it means that the imageattr attribute is useful only for carrying "desired" (non-mandatory) constraints on the incoming video stream, and cannot be used to require a specific resolution or range of resolutions from the sender (mandatory constraints). If RTCWEB wishes to have such mandatory constraints, it must propose a followup or extension to RFC 6236; it cannot simply refer to RFC 6236 for this. Is this a correct interpretation? Harald Alvestrand From miguel.a.garcia@ericsson.com Mon Apr 23 02:57:07 2012 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 7A25021F8619 for ; Mon, 23 Apr 2012 02:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 a5WoTJjDMZw8 for ; Mon, 23 Apr 2012 02:57:06 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7105521F85F7 for ; Mon, 23 Apr 2012 02:57:06 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-68-4f952771ce71 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9B.83.26681.177259F4; Mon, 23 Apr 2012 11:57:05 +0200 (CEST) Received: from [159.107.24.202] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 23 Apr 2012 11:57:04 +0200 Message-ID: <4F95276F.5030601@ericsson.com> Date: Mon, 23 Apr 2012 11:57:03 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mmusic , Flemming Andreasen Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Minutes of MMUSIC WG meeting at IETF 83, Paris 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, 23 Apr 2012 09:57:07 -0000 Hi, The minutes of the MMUSIC WG meeting at IETF 83 (Paris), have been posted: http://www.ietf.org/proceedings/83/minutes/minutes-83-mmusic.htm Please review them and send comments and corrections. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From mperumal@cisco.com Mon Apr 23 23:42:18 2012 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 84BBC11E80A6 for ; Mon, 23 Apr 2012 23:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 THA-Exm7Ar6k for ; Mon, 23 Apr 2012 23:42:17 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8164011E809B for ; Mon, 23 Apr 2012 23:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2466; q=dns/txt; s=iport; t=1335249736; x=1336459336; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=j7x+0CxYxrAmpP7jJRc9sAQJA0wdjokTBGEVfg817CA=; b=fypvMJBeuPULNKMgjqSrZIzgHw+NAuW1wPqQzF2SNLm79bwwgnkVGha7 YJmcfgBrWuZYhF2q8zzRNCf1n/ktzyM3QQKuG+e3OUfh6L1O7Ss5/osz5 2Xg7ie0TtSb0WR33Mudx1FpqorlckK4C6zSGHalfYHjQco+xjF//f3xMq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAAFLlk9Io8UY/2dsb2JhbABEsm+CCQEBAQQBAQEPAR0KNAsMBgEIEQQBAQsGFwEHJh8HAQEFBAEECwgIARmHbQuaMqA/iWeBD4V1YwSIYY4qii+DFYFpgnGBVA X-IronPort-AV: E=Sophos;i="4.75,472,1330905600"; d="scan'208";a="10751000" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 24 Apr 2012 06:42:14 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3O6gEck031382; Tue, 24 Apr 2012 06:42:14 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Apr 2012 12:12:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Apr 2012 12:12:12 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202083A110F@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-muthu-mmusic-offer-answer-g723-g729-00.txt Thread-Index: Ac0h3/V7nEkeb06AT02qA4kjwKYLPAABJ8aw From: "Muthu Arul Mozhi Perumal (mperumal)" To: "mmusic (E-mail)" X-OriginalArrivalTime: 24 Apr 2012 06:42:13.0806 (UTC) FILETIME=[61F18CE0:01CD21E5] Subject: [MMUSIC] FW: I-D Action: draft-muthu-mmusic-offer-answer-g723-g729-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, 24 Apr 2012 06:42:18 -0000 We have resubmitted the I-D clarifying the offer/answer considerations for the Annex A flavor of G.723 and the Annex B flavors of G.729, G.729D and G.729E, to the MMUSIC WG.=20 This clarification is missing in RFC4856, leading to interop issues, like: http://sipforum.org/pipermail/discussion/2008-January/004026.html The draft was earlier submitted to the Payload WG and discussed there: http://www.ietf.org/mail-archive/web/payload/current/msg00362.html The draft was presented at IETF-83 in the AVTEXT session (as a Payload item). Following instructions from the AD and chairs we are resubmitting it to MMUSIC. Comments welcome.. Muthu -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, April 24, 2012 11:33 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-muthu-mmusic-offer-answer-g723-g729-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Offer/Answer Considerations for G.723 Annex A and G.729 Annex B Author(s) : Muthu Arul Mozhi Perumal Parthasarathi Ravindran Filename : draft-muthu-mmusic-offer-answer-g723-g729-00.txt Pages : 8 Date : 2012-04-23 [RFC4856] describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the SDP offer and answer. This document provides the offer/answer considerations for these parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muthu-mmusic-offer-answer-g723 -g729-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-muthu-mmusic-offer-answer-g723- g729-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-muthu-mmusic-offer-answer-g723-g7 29/ _______________________________________________ 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 From yuepeiyu@huawei.com Tue Apr 24 19:26:55 2012 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 ECBA911E8087 for ; Tue, 24 Apr 2012 19:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.728 X-Spam-Level: X-Spam-Status: No, score=-99.728 tagged_above=-999 required=5 tests=[AWL=2.871, 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 VhN1dFQTyxEH for ; Tue, 24 Apr 2012 19:26:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24011E8074 for ; Tue, 24 Apr 2012 19:26:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFM79109; Tue, 24 Apr 2012 22:26:54 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 19:24:58 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 19:24:57 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.236]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 10:24:50 +0800 From: "Yuepeiyu (Roy)" To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC of draft-ietf-mmusic-rfc2326bis-29.txt Thread-Index: AQHNHWOZYhNweG6ZBk64tN+08x/BH5ahV5WAgAmCQwA= Date: Wed, 25 Apr 2012 02:24:48 +0000 Message-ID: References: <4F8EBB4E.7080804@ericsson.com> <4F8FD679.9050304@ericsson.com> In-Reply-To: <4F8FD679.9050304@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Magnus Westerlund Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-rfc2326bis-29.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: Wed, 25 Apr 2012 02:26:56 -0000 SGksDQoNCkkgaGF2ZSByZWFkIHRoZSBsYXRlc3QgZHJhZnQgYW5kIHRoaW5rIGl0IGlzIGdvb2Qg ZW5vdWdoIGZvciBwdWJsaWNhdGlvbi4NCg0KQlIsIFJveQ0KDQotLS0tLemCruS7tuWOn+S7ti0t LS0tDQrlj5Hku7bkuro6IG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bW11c2ljLWJv dW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBNYWdudXMgV2VzdGVybHVuZA0K5Y+R6YCB5pe26Ze0OiAy MDEy5bm0NOaciDE55pelIDE3OjEwDQrmlLbku7bkuro6IG1tdXNpY0BpZXRmLm9yZw0K5Li76aKY OiBSZTogW01NVVNJQ10gV0dMQyBvZiBkcmFmdC1pZXRmLW1tdXNpYy1yZmMyMzI2YmlzLTI5LnR4 dA0KDQpPbiAyMDEyLTA0LTE4IDE1OjAyLCBNaWd1ZWwgQS4gR2FyY2lhIHdyb3RlOg0KPiBUaGlz IGlzIHRvIHN0YXJ0IGEgNC13ZWVrIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvcg0KPiANCj4g ICAgICAgZHJhZnQtaWV0Zi1tbXVzaWMtcmZjMjMyNmJpcy0yOS50eHQNCj4gDQo+IFRoZSBXR0xD IGVuZHMgb24gTWF5IDE2dGgsIDIwMTIuIE5vdGljZSB0aGF0IHRoaXMgaXMgYSBzcGVjaWFsIDQt d2VlayANCj4gV0dMQyBkdWUgdG8gdGhlIGxlbmd0aCBvZiB0aGUgZG9jdW1lbnQuDQo+IA0KPiBX ZSB3b3VsZCBlc3BlY2lhbGx5IGxpa2UgcmV2aWV3ZXJzIHRvIGZvY3VzIG9uIHRoZSBjaGFuZ2Vz IHNpbmNlIHRoZSBsYXN0IA0KPiBXR0xDLCB3aGljaCB3YXMgZm9yIHZlcnNpb24gLTIzLg0KPiAN Cj4gUGxlYXNlIHJlcGx5IHRvIHRoaXMgZS1tYWlsIHRoYXQgaW5jbHVkZXMgdGhlIGF1dGhvcnMg YW5kIHRoZSBtYWlsaW5nIGxpc3QuDQoNCkhpLA0KDQpBcyBhbiBhdXRob3IgSSBjYW4gcG9zdCB0 aGUgbGluayBvZiB0aGUgRGlmZiBiZXR3ZWVuIDIzIGFuZCBub3c6DQoNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtbW11c2ljLXJmYzIzMjZiaXMtMjMmZGlm ZnR5cGU9LS1odG1sJnN1Ym1pdD1HbyEmdXJsMj1kcmFmdC1pZXRmLW1tdXNpYy1yZmMyMzI2Ymlz LTI5DQoNClRoaXMgaXMgcXVpdGUgYSBzdWJzdGFudGlhbGwgYW1vdW50IG9mIGNoYW5nZXMuIFVu Zm9ydHVuYXRlbHkgdGhlDQpzZWN0aW9uIHJlb3JkZXJpbmcgbWFrZXMgaXQgZGlmZmljdWx0IHRv IHNwb3QgY2hhbmdlcyBpbiBzb21lIHN1Yi1zZWN0aW9ucy4NCg0KQ2hlZXJzDQoNCk1hZ251cyBX ZXN0ZXJsdW5kDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmlj c3NvbiBSZXNlYXJjaCBFQUIvVFZNDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFcmljc3NvbiBBQiAgICAgICAg ICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KRsOkcsO2Z2F0YW4gNiAgICAgICAgICAg ICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVu fCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2lj IG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21tdXNpYw0K From magnus.westerlund@ericsson.com Thu Apr 26 01:11:40 2012 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 61FE521F8709 for ; Thu, 26 Apr 2012 01:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.14 X-Spam-Level: X-Spam-Status: No, score=-106.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 m1ZmEU3tfSoT for ; Thu, 26 Apr 2012 01:11:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A044A21F8707 for ; Thu, 26 Apr 2012 01:11:36 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-45-4f990337d0a9 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1A.A6.03534.733099F4; Thu, 26 Apr 2012 10:11:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Apr 2012 10:11:35 +0200 Message-ID: <4F990323.1010804@ericsson.com> Date: Thu, 26 Apr 2012 10:11:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20120426080800.8654.81808.idtracker@ietfa.amsl.com> In-Reply-To: <20120426080800.8654.81808.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------010107090306030105080008" X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Fwd: I-D Action: draft-westerlund-avtcore-max-ssrc-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 08:11:40 -0000 --------------010107090306030105080008 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, We have updated our individual draft for the maximum SSRC SDP signaling. The main change is that the fallback policy has been changed from a single SSRC to being application specific. Feedback much appreciated. Cheers Magnus Westerlund --------------010107090306030105080008 Content-Type: message/rfc822; name="I-D Action: draft-westerlund-avtcore-max-ssrc-01_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="I-D Action: draft-westerlund-avtcore-max-ssrc-01_txt.eml" X-Mozilla-Keys: Received: from sessmg10.ericsson.net (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.83) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Apr 2012 10:08:10 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id 46.05.09996.962099F4; Thu, 26 Apr 2012 10:08:10 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B92F21F86AD; Thu, 26 Apr 2012 01:08:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C03F21F86B3 for ; Thu, 26 Apr 2012 01:08:01 -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 8+wTOsafT2ML for ; Thu, 26 Apr 2012 01:08:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7660821F86A3 for ; Thu, 26 Apr 2012 01:08:00 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Sender: "i-d-announce-bounces@ietf.org" Date: Thu, 26 Apr 2012 10:08:00 +0200 Subject: I-D Action: draft-westerlund-avtcore-max-ssrc-01.txt Thread-Topic: I-D Action: draft-westerlund-avtcore-max-ssrc-01.txt Thread-Index: Ac0jg7htO74rObB8RTSBImaXVEwFGw== Message-ID: <20120426080800.8654.81808.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: esessmw0184.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb3e-b7f636d00000270c-6d-4f99026956a3 x-brightmail-tracker: H4sIAAAAAAAAA1WSa0gUURiGPTPr7LjN6HG9fVoZjUgqpQn9mELFFKIfoRUVUYFuOe2ul9V2 1rILpGZRdtEK1wu6hXaxVBSz0kSoLewmpaZGadrF8gIVBZZmWjvOlvXv4bzv977fORyaVF+n fGghwyQYDZpkjlIpGM8VvksSieLYpU9eufPZrxqUfFbfO4LPyhb5qvfRfGdtP8F/MP+k+F5L n5IvKp1Q8oWHw/nx5mrHSNXqH2Pd1Fq0RRWWICTrdwvGkIh4le5SyxlFmtklo6uwkcxEJ5hc 5EQDXgZfbphJmT2hvb+WykUqWo0bEdwfeTYjqHEhgoq7ayRW4CkSTk96ygNBcPnRc0I+D4Rf rUcc5eEGBJduDytlUwAUXWlHuYi2sQvUWP1k9ITSr2Gywxk6hscJmfdDx/E6pRzzEkH522b7 QtcQfG+uoiQXi13hYfGgQmIK+0LVqBlJ7I69oaStbKbXDYfD6cHX9lR3+NT9xn5LgPFzlaSc EwklddMKaSEF9odbF9WyhYNfR87a1/eG3JODM4wxBsuFJkJ+Ew7M5hcztQyOgrJP/YS0J4MP IcgusThKmQxeCTmTm2RPILx4arH7I+BqYYMyH/mX/HMbiUm8GM43f6VkXgA3P5aS5xF5FXmI giimaEOXBgtG/Q5RTDUEGwRTPbL9lTsNkxGNqOdNqBV50wTnwVZOF8WqnbenJuzVaURdnDE9 WRCtaC6t4LzYkQPpsWqs1ZiEJEFIE4x/1Hk0zQF7EBXHql2NglbI2KlPNs3KBO1kRUAznDsb KHlYMU2TIuq1sv4ILfTxYtdLApYEXbrh7+yf39yJ5vu4scjBwUHN2HpT9Kb/9VHkRSPOjd0l pTB6g+lv+qitmLAVf1tvlopNmlnJJxM9WGUYi4rZED/Q39JF5R9zWPdgTXle3ZmjVPfj3vqK yYLwOCM9J3zbz9qpGuFHwKmsnvTA1CZ9a32OX0Henn0TQu3ynnus3vJxXFkZFTx1uUJXFdaW 4JxY9zmrNWkDY9hakbZx7POQtdpyJW4gJtpiClm3OXNg7XBe/qKh6b1lfb6cQtRpQoNIo6j5 DQI+gZrIAwAA dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335427683; bh=dk3BkarFVocpE1deubUp4crIC9XEIxadZ3QlgjWfDsQ=; 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=ti6UW0Gsa2O/bLr3UhjZe75E/aM45ocSrvThagopARcKxb3WSDIoH+du1Tg5SqzjK b2MZKgbUUyZG/+j2MtPDgpjQtpg+4f66Fqgg9cvcZ9yUaHMmIuLnNIljEXkvvGlIbX tpHAKnI7xOPv2JQptLsVh1PZja8cyv+QCViKVpOM= 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.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] x-spam-score: -102.514 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 Synchronization sources (SSRC) in RTP Session S= ignaling Author(s) : Magnus Westerlund Bo Burman Fredrik Jansson Filename : draft-westerlund-avtcore-max-ssrc-01.txt Pages : 13 Date : 2012-04-26 RTP has always been a protocol that supports multiple participants each sending their own media streams in an RTP session. Unfortunately many implementations are designed only for point to point voice over IP with a single source in each end-point. Even client implementations aimed at video conferences have often been built with the assumption around central mixers that only deliver a single media stream per media type. Thus any application that wants to allow for more advance usage where multiple media streams are sent and received by an end-point has an issue with legacy implementations. This document describes the problem and proposes a signalling solution for how to use multiple SSRCs within one RTP session and at the same time handle the legacy issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westerlund-avtcore-max-ssrc-01.tx= t 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-max-ssrc-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-westerlund-avtcore-max-ssrc/ _______________________________________________ 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 --------------010107090306030105080008-- From magnus.westerlund@ericsson.com Thu Apr 26 08:56:39 2012 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 4BD7721E80C0 for ; Thu, 26 Apr 2012 08:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.129 X-Spam-Level: X-Spam-Status: No, score=-106.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 1KNaDqEMH4zk for ; Thu, 26 Apr 2012 08:56:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CAB8E21E8112 for ; Thu, 26 Apr 2012 08:56:36 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-cd-4f9970334009 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 68.7A.03534.330799F4; Thu, 26 Apr 2012 17:56:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Apr 2012 17:56:35 +0200 Message-ID: <4F99701E.1020806@ericsson.com> Date: Thu, 26 Apr 2012 17:56:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4F8EBB4E.7080804@ericsson.com> In-Reply-To: <4F8EBB4E.7080804@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen , "draft-ietf-mmusic-rfc2326bis.authors@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-rfc2326bis-29.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, 26 Apr 2012 15:56:39 -0000 Hi, I have to add a WG last call comment on my own document. This comes from a discussion on the AVTCORE ECN for RTP document with Pete Resnick regarding ABNF extension definitions and the qdtext definition of UTF-8. Fist of all it doesn't provide any escaping of strings including " and secondly its definition of UTF-8 and additional characters are in error. > quoted-string = ( DQ *qdtext DQ ) > qdtext = %x20-21 / %x23-7E / %x80-FF / UTF8-NONASCII > ; any UTF-8 TEXT except<"> > DQ = %x22 ; US-ASCII double-quote mark (34) > UTF8-NONASCII = %xC0-DF 1UTF8-CONT > / %xE0-EF 2UTF8-CONT > / %xF0-F7 3UTF8-CONT > / %xF8-FB 4UTF8-CONT > / %xFC-FD 5UTF8-CONT > UTF8-CONT = %x80-BF > First of all, I don't think you should be including %x80-FF not in the context of UTF-8. As you said, if you want binary content (or random octets), you can always BASE64 the thing. This should be for strings, and that means either US-ASCII or UTF-8 and nothing else. I think you should incorporate definitions from 5234 (DQUOTE) and 3629 (UTF8-1, UTF8-2, UTF8-3, and UTF8-4) and simply make this: quoted-string = ( DQUOTE *qdtext DQUOTE ) qdtext = %x20-21 / %x23-7E / UTF8-NONASCII UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 If you want to add the quoted-pair escaping mechanism, the simplest would be: quoted-string = ( DQUOTE *qdtext DQUOTE ) qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair / UTF8-NONASCII ; No DQUOTE and no "\" quoted-pair = "\\" / ( "\" DQUOTE ) UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 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 fluffy@iii.ca Sun Apr 29 08:49:24 2012 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 B142C21F859A for ; Sun, 29 Apr 2012 08:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 l9CnaF+wZv-0 for ; Sun, 29 Apr 2012 08:49:24 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3E57121F8599 for ; Sun, 29 Apr 2012 08:49:24 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AFBAB22E1F4; Sun, 29 Apr 2012 11:49:17 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Apr 2012 09:49:15 -0600 Message-Id: <00FD5DC6-859A-4155-A78D-CF676EADE895@iii.ca> To: "mmusic@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Flemming Andreasen Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-media-capabilities-13 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, 29 Apr 2012 15:49:24 -0000 I went thought this pretty carefully from the point of view of could I = implement it, does it work, does it meet the use cases I care about, and = are the corner cases where it won't work. As bizarre as this seems, I = have could not find any problems - I think this is ready to publish.=20 I did not do a careful check of grammar or stuff like that because 1) I = suck at that at 2) the RFC Ed will get that. I also did not check the = ABNF - someone should do that.=20 Look good, Cullen From christer.holmberg@ericsson.com Mon Apr 30 05:27:30 2012 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 500A321F861F for ; Mon, 30 Apr 2012 05:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=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 cM2P9qMdtSuM for ; Mon, 30 Apr 2012 05:27:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5659421F854B for ; Mon, 30 Apr 2012 05:27:28 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-aa-4f9e852f04d0 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CF.99.25560.F258E9F4; Mon, 30 Apr 2012 14:27:27 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Mon, 30 Apr 2012 14:27:27 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Date: Mon, 30 Apr 2012 14:27:25 +0200 Thread-Topic: [MMUSIC] Review of draft-ietf-mmusic-sdp-media-capabilities-13 Thread-Index: Ac0mzGxER0rMbjKOTUeOksP9gefMbw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C442AB5C5@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_7F2072F1E0DE894DA4B517B93C6A05852C442AB5C5ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Flemming Andreasen \(fandreas@cisco.com\)" Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-media-capabilities-13 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, 30 Apr 2012 12:27:30 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C442AB5C5ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Eventhough a very detailed mechanism, in the same way as Cullen I could not= come up with cases where the mechanism would not work. I also took a detailed look at the ABNF, where I have some comments. ----------------- General: SDP normally has a rather strict syntax. For example, elements are normally= separated explicitly with "SP". However, you use "1*WSP" in most places. I= s there a reason for having a more relaxed syntax in media cap? ---------------- Section 3.3.2.1: The section contains examples with a number of rmcap attributes: a=3Drmcap:1,2 audio G729/8000 a=3Drmcap:1 video H263-1998/90000 a=3Drmcap:2 video H263-2000/90000 However, I don't think these are valid according to the syntax in section 3= .3.1, which does not define the media type ("audio", "video", etc): a=3Drmcap: / = [/] --------------- Section 3.3.8: The example contains the following line: a=3Drmcap:51 * However, I don't think that is valid according to the syntax in section 3.3= .1, which mandates both encoding name and clock-rate: a=3Drmcap: / = [/] In addition, I find no definition of using "*" for the encoding-name (I ass= ume it is some kind of wildcard). --------------- Section 4.1: See issue on 3.3.8. --------------- a=3Domcap: There is no example showing the a=3Domcap attribute. I think it would be go= od to have one. --------------- a=3Dsescap: There is no example showing the usage of optional-configs. I think it would= be good to have one. --------------- Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C442AB5C5ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Eventhough a very detailed = mechanism, in the same way as Cullen I could not come up with cases where t= he mechanism would not work.

 

I also took a detailed look at the ABNF= , where I have some comments.

 

-----------------

 

 

Genera= l:

 

SDP normally has a rather strict syntax. For example, elements ar= e normally separated explicitly with “SP”. However, you use = 220;1*WSP” in most places. Is there a reason for having a more relaxe= d syntax in media cap?

 

 

----------------

=

 

 
Section 3.3.2.1:
 
The section contains examples with a number of rmca=
p attributes:
 
  =
     a=3Drmcap:1,2 audio G729/8000
       a=3Drmcap:1 video H263-1998/90000
       a=3Drmcap:2 video H2=
63-2000/90000
 
However, I d=
on’t think these are valid according to the syntax in section 3.3.1, =
which does not define the media type (“audio”, “videoR=
21;, etc):
 
  &nb=
sp;            a=3Dr=
mcap:<media-cap-num-list> <encoding-name>/<clock-rate> [/=
<encoding-parms>]
 
=

 
---------------
 <=
/o:p>
 
Section 3.3.8:
 
The example contains the following line:
 
    &nb=
sp;          a=3Drmcap:51 *
 
However, I don’t think=
 that is valid according to the syntax in section 3.3.1, which mandates bot=
h encoding name and clock-rate:
 
           &nb=
sp;   a=3Drmcap:<media-cap-num-list> <encoding-name>/=
<clock-rate> [/<encoding-parms>]
&nbs=
p;
 
In addition, I find no defin=
ition of using “*” for the encoding-name (I assume it is some k=
ind of wildcard).
 
<=
span style=3D'font-size:12.0pt;font-family:"Calibri","sans-serif"'>&nb=
sp;
---------------
 <=
/span>
 
Section 4.1:
<=
pre> 
See issue on 3.3.8.
&nbs=
p;
 
---------------
 
 
a=3Domcap:=

 
There is no example showi=
ng the a=3Domcap attribute. I think it would be good to have one.
 
 
=
-------=
--------
 
 =

a=3Dsescap:
 
<= pre>The= re is no example showing the usage of optional-configs. I think it would be= good to have one.
 
=
&n=
bsp;
---------------
 =

Regards,=

 

Christer<= /p>

= --_000_7F2072F1E0DE894DA4B517B93C6A05852C442AB5C5ESESSCMS0356e_-- From capelastegui@dit.upm.es Mon Apr 30 09:57:23 2012 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 D5A4221F8570 for ; Mon, 30 Apr 2012 09:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzzhTQEBIHk2 for ; Mon, 30 Apr 2012 09:57:20 -0700 (PDT) Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id 1491C21F8528 for ; Mon, 30 Apr 2012 09:57:18 -0700 (PDT) Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:7367]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id q3UGvHcA019481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Apr 2012 18:57:17 +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 q3UGv5rn030372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 30 Apr 2012 18:57:05 +0200 From: "Pedro Capelastegui" To: "IETF - MMUSIC" Date: Mon, 30 Apr 2012 18:57:17 +0200 Message-ID: <001201cd26f2$4d0bea20$e723be60$@dit.upm.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CD2703.10955660" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0m8OHepKs2Cg2wTgaNPbtEH6WYzQ== Content-Language: es Subject: [MMUSIC] Submission of draft-capelastegui-mmusic-3dv-sdp-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: Mon, 30 Apr 2012 16:57:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0013_01CD2703.10955660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I have submitted an individual draft to address the description of 3D video streams in SDP. The document is intended as an alternative to draft-ietf-mmusic-signal-3d-format-00, using a different mechanism based on decoding dependencies to indicate the relationship between different streams in a 3D video stream. The document can be found at https://datatracker.ietf.org/doc/draft-capelastegui-mmusic-3dv-sdp/ Comments are welcome. Regards, Pedro ------=_NextPart_000_0013_01CD2703.10955660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

I have submitted an individual draft to address the = description of 3D video streams in SDP. The document is intended as an = alternative to draft-ietf-mmusic-signal-3d-format-00, using a different = mechanism based on decoding dependencies to indicate the relationship = between different streams in a 3D video stream.

 

The document = can be found at

https://datatracker.ietf.org/doc/draft-capelastegui-mmusic-3dv-sdp/

 

Comments are welcome.

 

Regards,

Pedro

------=_NextPart_000_0013_01CD2703.10955660--