From harald@alvestrand.no Mon Jan 6 10:30:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3741AE17A for ; Mon, 6 Jan 2014 10:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.539 X-Spam-Level: X-Spam-Status: No, score=-5.539 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL-5yebelenQ for ; Mon, 6 Jan 2014 10:30:54 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 42AEF1AE179 for ; Mon, 6 Jan 2014 10:30:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B40039E286; Mon, 6 Jan 2014 19:30:50 +0100 (CET) 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 a-h2zwQjZ8Z8; Mon, 6 Jan 2014 19:30:49 +0100 (CET) Received: from [192.168.1.156] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 15F4E39E241; Mon, 6 Jan 2014 19:30:49 +0100 (CET) Message-ID: <52CAF652.7070404@alvestrand.no> Date: Mon, 06 Jan 2014 19:30:42 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Kyzivat References: <52AF101F.2000007@ericsson.com> <52AF115F.2070803@alvestrand.no> <52B0428F.2040905@ericsson.com> <52B0C9A1.6060301@alum.mit.edu> In-Reply-To: <52B0C9A1.6060301@alum.mit.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Some comments on draft-ietf-mmusic-msid-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2014 18:30:58 -0000 Thanks for the review! I'm now trying to get the -03 version out (at long last). The comments have been incorporated. Hope they work out to your satisfaction! On 12/17/2013 11:01 PM, Paul Kyzivat wrote: > In Vancouver I volunteered to look at this version of the msid draft, > especially wrt its relationship to the app-token draft. > > After looking, IMO some things can be done to this draft that will not > effect its substance, but will more clearly separate its concerns from > those of app-token and unified-plan. > > The unified-plan has gotten us to a point where individual source > streams each have their own m-line. > > The app-token draft is defining a mechanism that will provide allow a > level of indirection to SSRCs. That hasn't matured to the point of > being picked up in unified-plan, but I hope it eventually will be. > > The problem I see now is that this msid draft is still filled with > lots of reference to SSRCs, even though the mechanism it specifies no > longer is at all dependent on SSRCs. The mechanism is solely for the > purpose of attaching related identifiers to m-lines and groups of > m-lines. How those m-lines are associated with SSRCs and/or appids is > better left to other documents. > > If it is so decoupled, then it will be easy to progress this one. Then > we can leave it to unified-plan and app-token to do their thing. And > in the future, if new mechanisms are defined to bind streams to > m-lines, then this document will remain valid. > > Some specifics: > > * Section 1.2: > > The SDP grouping framework [RFC5888] can be used to group m-lines. > However, there is sometimes the need for an application to specify > some application-level information about the association between the > SSRC and the group. This is not possible using the SDP grouping > framework. > > s/SSRC/m-line/ Done. > > * Section 1.3: > > In the RTP specification, media streams are identified using the SSRC > field. Streams are grouped into RTP Sessions, and also carry a > CNAME. Neither CNAME nor RTP session correspond to a MediaStream. > Therefore, the association of an RTP media stream to MediaStreams > need to be explicitly signaled. > > I think this entire paragraph can be dropped. The following paragraph > is sufficient. This is background indicating why CNAME is not an appropriate mechanism. While this debate seems to be long over, I'd like to keep the paragraph. > > * Section 2: > > Endpoints can update the associations between SSRCs as expressed by > msid attributes at any time; the semantics and restrictions of such > grouping and ungrouping are application dependent. > > s/SSRCs/m-lines/ In this context, I prefer to use "RTP media streams". > > * Section 4: > > This section creates a new semantic for use with the framework > defined in Section 2, to be used for associating SSRCs representing > MediaStreamTracks within MediaStreams as defined in > [W3C.WD-webrtc-20120209]. > > s/SSRCs/m-lines/ Done. > > In a WebRTC-compatible SDP description, all SSRCs intending to be > sent from one peer will be identified in the SDP generated by that > entity. > > I'm not sure about the above. It's true now based on unified-plan. It > might be altered by the use of app-token. If unified-plan is changed, this will have to be changed too. But it doesn't matter for this specification, actually, so I'm deleting this paragraph. > > In addition to signaling that the track is closed when it disappears > from the SDP, the track will also be signaled as being closed when > all associated SSRCs have disappeared by the rules of [RFC3550] > section 6.3.4 (BYE packet received) and 6.3.5 (timeout). > > Another one I'm not sure about. If app-token is used to define > m-lines, then it ceases to be so clear when the track should close. > Maybe it should close if a BYE or timeout is received on the last SSRC > bound to the app-token. Or maybe not. This probably needs more work. > But is this the right draft to specify that? This is definitely not the right draft to describe the use of app-token. This text resulted from previous discussions, and was a question in an earlier version - I believe Colin Perkins suggested that the disappearance according to RTP rules should cause the ending of the track too. If one track is associated with multiple SSRCs, then it is logical that all the SSRCs have to disappear before it is ended; this is already in the text. No change. > > * Section 5: > > o The attribute gives an association over a set of m-lines. It can > be used to signal the relationship between a WebRTC MediaStream > and a set of SSRCs. > > s/SSRCs/m-lines/ Done. > > * Appendices: I'm ignoring them. > > Thanks, > Paul > > On 12/17/13 7:24 AM, Ari Keränen wrote: >> On 12/16/13 4:42 PM, Harald Alvestrand wrote: >>> On 12/16/2013 03:37 PM, Ari Keränen wrote: >>>> Hi Roni and Paul, >>>> >>>> At the Vancouver meeting we discussed that the MSID draft would need >>>> more review and input, also regarding it's relationship with the >>>> app-token draft. You guys volunteered to have a look at the new >>>> version Harald submitted during the meeting: >>>> http://tools.ietf.org/html/draft-ietf-mmusic-msid-02 >>>> >>>> When you have a chance, would be great if you can check out the draft >>>> and post your comments on the list. >>>> >>>> >>>> Thanks, >>>> Ari >>> There was also significant input on the document in the WEBRTC WG >>> meeting in Shenzhen - especially around the subject of non-signalled >>> SSRCs. >>> >>> I'll issue an updated version based on that; if you can get feedback in >>> soon I can incorporate that too. >>> >> >> Thanks for the update Harald! Could you summarize that input to the >> mailing list so that the WG is up to speed with the discussion? >> >> >> Cheers, >> Ari >> > -- Surveillance is pervasive. Go Dark. From internet-drafts@ietf.org Mon Jan 6 10:33:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8881AE194; Mon, 6 Jan 2014 10:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MaZ4JvLVmkO; Mon, 6 Jan 2014 10:33:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 410291AE181; Mon, 6 Jan 2014 10:33:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140106183351.27972.34383.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2014 10:33:51 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 18:33:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Cross Session Stream Identification in the Sessio= n Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-03.txt Pages : 15 Date : 2014-01-06 Abstract: This document specifies a grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "m-line" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-msid-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-msid-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Mon Jan 6 11:53:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B711AE1DE for ; Mon, 6 Jan 2014 11:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or5Q9tvQ9BMe for ; Mon, 6 Jan 2014 11:53:18 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 346801AE1EA for ; Mon, 6 Jan 2014 11:53:18 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta14.westchester.pa.mail.comcast.net with comcast id AcFJ1n0041ap0As5Ejt9h9; Mon, 06 Jan 2014 19:53:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id Ajt91n00B3ZTu2S3ijt9sG; Mon, 06 Jan 2014 19:53:09 +0000 Message-ID: <52CB09A5.6050906@alum.mit.edu> Date: Mon, 06 Jan 2014 14:53:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Harald Alvestrand , Roni Even , Jonathan Lennox References: <52AF101F.2000007@ericsson.com> <52AF115F.2070803@alvestrand.no> <52B0428F.2040905@ericsson.com> <52B0C9A1.6060301@alum.mit.edu> <52CAF652.7070404@alvestrand.no> In-Reply-To: <52CAF652.7070404@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389037989; bh=xi3A12siXfB1+XXFmb06rwS3IHRewM1Mrpfby3dtUbM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mdeu0TPbJk2EOu9tKAm7D3ApDxyM7wgr/3KBn6lIRGm74ZyBNpKnPFeivWi0z3Nnt /fBp+45WAMmgtdUDGM0Gjfne3V8F7/wsdviPgXQIzIefckuGVFRpB6Hc2UCfQeQ+Hk BtrCw7fmIT1WLn8Uxnw0IHniBk1mzzr8ib4CRhlJDLQETD0ptrTxrX896OP8MHyuHa vp5gNBsA/5Rr1q7GUsNrq7wrerDi3T/zSg3mRpDnGfM+W68ALS2p8SMiurg1Aaw0XD 2wVkuYHDRGa/xXxEVlbKwc15Ips8W1v0PNSREBoWBA+svEoWPuIrRSXm8Q83+2mD8U chakm6M7TjK0A== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Some comments on draft-ietf-mmusic-msid-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2014 19:53:20 -0000 More comments inline. I'm not commenting on things were we are in full agreement. *** Note to Roni and Jonathan: need input from you on this *** On 1/6/14 1:30 PM, Harald Alvestrand wrote: > Thanks for the review! I'm now trying to get the -03 version out (at > long last). > > The comments have been incorporated. Hope they work out to your > satisfaction! > > On 12/17/2013 11:01 PM, Paul Kyzivat wrote: >> In Vancouver I volunteered to look at this version of the msid draft, >> especially wrt its relationship to the app-token draft. >> >> After looking, IMO some things can be done to this draft that will not >> effect its substance, but will more clearly separate its concerns from >> those of app-token and unified-plan. >> >> The unified-plan has gotten us to a point where individual source >> streams each have their own m-line. >> >> The app-token draft is defining a mechanism that will provide allow a >> level of indirection to SSRCs. That hasn't matured to the point of >> being picked up in unified-plan, but I hope it eventually will be. >> >> The problem I see now is that this msid draft is still filled with >> lots of reference to SSRCs, even though the mechanism it specifies no >> longer is at all dependent on SSRCs. The mechanism is solely for the >> purpose of attaching related identifiers to m-lines and groups of >> m-lines. How those m-lines are associated with SSRCs and/or appids is >> better left to other documents. >> >> If it is so decoupled, then it will be easy to progress this one. Then >> we can leave it to unified-plan and app-token to do their thing. And >> in the future, if new mechanisms are defined to bind streams to >> m-lines, then this document will remain valid. >> >> Some specifics: >> >> * Section 1.2: >> >> The SDP grouping framework [RFC5888] can be used to group m-lines. >> However, there is sometimes the need for an application to specify >> some application-level information about the association between the >> SSRC and the group. This is not possible using the SDP grouping >> framework. >> >> s/SSRC/m-line/ > > Done. >> >> * Section 1.3: >> >> In the RTP specification, media streams are identified using the SSRC >> field. Streams are grouped into RTP Sessions, and also carry a >> CNAME. Neither CNAME nor RTP session correspond to a MediaStream. >> Therefore, the association of an RTP media stream to MediaStreams >> need to be explicitly signaled. >> >> I think this entire paragraph can be dropped. The following paragraph >> is sufficient. > > This is background indicating why CNAME is not an appropriate mechanism. > While this debate seems to be long over, I'd like to keep the paragraph. I can live with that. >> * Section 2: >> >> Endpoints can update the associations between SSRCs as expressed by >> msid attributes at any time; the semantics and restrictions of such >> grouping and ungrouping are application dependent. >> >> s/SSRCs/m-lines/ > > In this context, I prefer to use "RTP media streams". I think that still leaves things a bit confusing. There are two kinds of interesting changes possible: 1) the association between msid attributes and m-lines can be updated 2) the association between m-lines and RTP streams can be updated Of these, (1) is directly relevant to this draft, and should be made clear. Meanwhile, (2) is also important, and may also be worth pointing out in this draft. But the mechanics of doing so are in the scope of other drafts. >> * Section 4: >> >> This section creates a new semantic for use with the framework >> defined in Section 2, to be used for associating SSRCs representing >> MediaStreamTracks within MediaStreams as defined in >> [W3C.WD-webrtc-20120209]. >> >> s/SSRCs/m-lines/ > > Done. > >> >> In a WebRTC-compatible SDP description, all SSRCs intending to be >> sent from one peer will be identified in the SDP generated by that >> entity. >> >> I'm not sure about the above. It's true now based on unified-plan. It >> might be altered by the use of app-token. > > If unified-plan is changed, this will have to be changed too. But it > doesn't matter for this specification, actually, so I'm deleting this > paragraph. OK. >> >> In addition to signaling that the track is closed when it disappears >> from the SDP, the track will also be signaled as being closed when >> all associated SSRCs have disappeared by the rules of [RFC3550] >> section 6.3.4 (BYE packet received) and 6.3.5 (timeout). >> >> Another one I'm not sure about. If app-token is used to define >> m-lines, then it ceases to be so clear when the track should close. >> Maybe it should close if a BYE or timeout is received on the last SSRC >> bound to the app-token. Or maybe not. This probably needs more work. >> But is this the right draft to specify that? > > This is definitely not the right draft to describe the use of app-token. Or the use of Unified! > This text resulted from previous discussions, and was a question in an > earlier version - I believe Colin Perkins suggested that the > disappearance according to RTP rules should cause the ending of the > track too. I think this may now require further discussion. > If one track is associated with multiple SSRCs, then it is logical that > all the SSRCs have to disappear before it is ended; this is already in > the text. > No change. The problem, if there is one, is what it means for SSRCs to be associated with an m-line. IIUC, with appid there is only one SSRC associated with the m-line at any one time, but which SSRC it is may change. The problem would come if a BYE was received on the SSRC currently associated with the m-line based on appid, and then another packet came on a different SSRC and an appid token that ties it to this m-line. I don't know what should happen in this case. I'd like to hear from Roni and Jonathan about it. Clearly what should happen in that case is not something for this draft to address. I just don't want this draft to constrain what should happen in that case. >> * Section 5: >> >> o The attribute gives an association over a set of m-lines. It can >> be used to signal the relationship between a WebRTC MediaStream >> and a set of SSRCs. >> >> s/SSRCs/m-lines/ > > Done. Thanks, Paul From christer.holmberg@ericsson.com Thu Jan 9 04:25:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C291ADDCA for ; Thu, 9 Jan 2014 04:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXEwGdMvFcLh for ; Thu, 9 Jan 2014 04:25:19 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0011ADFD8 for ; Thu, 9 Jan 2014 04:25:16 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-ad-52ce95222c5a Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CB.79.15980.2259EC25; Thu, 9 Jan 2014 13:25:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 13:25:02 +0100 From: Christer Holmberg To: James Rafferty , "mmusic@ietf.org" , Gonzalo Salgueiro Thread-Topic: [MMUSIC] Review (Rafferty) of draft-ietf-mmusic-udptl-dtls-02 Thread-Index: AQHO/dNH5N4ZiaonFEabHHN0Tl+8lJp6+rPg Date: Thu, 9 Jan 2014 12:25:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5F29CF@ESESSMB209.ericsson.se> References: <52B4C55D.5060708@humancomm.com> In-Reply-To: <52B4C55D.5060708@humancomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvja7S1HNBBg3LhC3mTvGzWHLzJYvF 1OWPWRyYPab83sjq0b3lMrPHkiU/mQKYo7hsUlJzMstSi/TtErgybp48xlawRbbi0YGbLA2M 88S7GDk5JARMJM5cvMQOYYtJXLi3nq2LkYtDSOAQo0Tnx4WsEM5iRolJmzcDVXFwsAlYSHT/ 0wZpEBGolrh9/zYbiC0s4CVxcso9FpASEQFviVXfgiFKjCSWPbjKDGKzCKhITPhwmwXE5hXw lVh67xxYq5CAjkTfwvNgcU4BXYmT82eAxRmB7vl+ag0TiM0sIC5x68l8Jog7BSSW7DnPDGGL Srx8/I8VwlaUuDp9OVS9jsSC3Z/YIGxtiWULXzND7BWUODnzCcsERtFZSMbOQtIyC0nLLCQt CxhZVjGy5yZm5qSXm29iBMbGwS2/DXYwbrovdohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MIpOtFp8zmTz5DLMNj77Pt8NyH584HKtVDBSNrbdm23dS9fvvvz2frBTZ F1x1OR219LFDRsYpvTezrsoWxSrMUXlydorTrbPJ7tUnQhe8MtXZKXHRXdFL1HiKxnN/RoOz 8T2Lvdka039PeHwguSWj6+PKBxVc1bktEu8+udz0WPv1k4LstzRfJZbijERDLeai4kQA71xw PFsCAAA= Subject: Re: [MMUSIC] Review (Rafferty) of draft-ietf-mmusic-udptl-dtls-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2014 12:25:21 -0000 Hi James, Thanks for your review! Comments inline. > This is a review ofdraft-ietf-mmusic-udptl-dtls-02. In general, the=20 > draft is in good shape. My comments and suggestions are included below. > > Section 1 - first bullet: add "the" before application layer Ok. ------------------------ > Section 1, Page 2 - On the paragraph before Table 2, the current last se= ntence reads: "The protocol stack for integrity and confidentiality protec= ted fax transport using UDPTL over DTLS is shown in Table 2." > > A couple of word changes would make it read more clearly: > "The protocol stack which enhances fax transport to offer integrity and c= onfidentiality using UDPTL over DTLS is shown in Table 2." Looks ok. ------------------------ > Section 1, Page 3: Under the "primary motivations" , I'd suggest broaden= ing the applicability of the last bullet point to read: > > "3GPP and the IP fax community need a mechanism to transport UDPTL over D= TLS in order to provide secure fax in IMS and other SIP-based networks." Looks ok. ------------------------ > Section 2 > > for the 2nd sentence of the second paragraph, clarify by replacing "it" = by "session" Ok. ------------------------ > Section 5 - Security Considerations > > I think it would help to pull in material about the threat model before j= umping directly into the solution (my latest draft got dinged in the IESG s= ecurity review on this point). > > From a fax community perspective, the relevant threats seem to be: > > 1. Confidentiality - Address potential for 3rd parties to intercept and = decode messages > > 2. Integrity - Ensure that the parties exchanging the messages are prope= rly authenticated and that the message has not been altered during transpor= t. > > These points are addressed somewhat in the body of this section, but it w= ould be useful to start with the threats model and then identify how the so= lution meets the requirements. We'll look into it. ------------------------ > Section 6 - IANA Considerations > > For consistency with the IANA content for "proto" in RFC 4566, it looks = like the entry for the SDP name in Table 3 should be in quotes or "UDP/TLS/= UDPTL" Ok. ------------------------ > Example A.3 > > This is an important example, since most (if not all) current UDPTL sessi= ons will start as audio sessions. > > To highlight this point, I'd suggest adding a second sentence in this sec= tion such as: > > "By current conventions, most non-secured UDPTL sessions are initiated vi= a a re-INVITE after the SIP session has begun as an audio session and this = example shows to address this scenario for initiating UDPTL sessions secure= d via DTLS." In general I am ok with the suggestion, but perhaps we could replace "By cu= rrent conventions" with "Traditionally". Because, we don't know how things = will be done in the future. I also suggest some other editorial changes to the sentence. Something like= : OLD: Figure 6 focuses on T.38 fax securely transported using UDPTL over DTLS replacing audio media stream in an existing audio-only session. NEW: Traditionally, most session with non-secure transport of T.38 fax, transported using UDPTL, are established by modifying an ongoing=20 audio session into a fax session. Figure 6 shows an example message flow of modifying an existing audio session into a session with T.38 fax=20 securely transported using UDPTL over DTLS. ...or something like that. I'll need to make it "fit" into the existing tex= t :) ------------------------ > That concludes my comments on this draft. Thank You very much! :) Regards, Christer From 2mkristensen@gmail.com Fri Jan 10 02:50:35 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132021ADBCE for ; Fri, 10 Jan 2014 02:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1AjQhSAn4M8 for ; Fri, 10 Jan 2014 02:50:30 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A3ED61AD986 for ; Fri, 10 Jan 2014 02:50:30 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id o15so3937614qap.17 for ; Fri, 10 Jan 2014 02:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TTFJXva56wexvva2iauk0rouoGE1OYloiH/8k8OEIRE=; b=JEEtRSsPn6rFLP2YkWiWrFlUx7kt72rW3eMbIISBPgYEIQZYDzBjRIJljcWPD4bYcS Ecm24Atfoew+dMb4k3/IoCF2D74YtW52BAJHTSRCOpQdFmmvBVZdL7b3gbNmq/YOeUU/ a4mGyfT3tUnqYvqrASlGcTSOJZgQPGIBX5Y/X+fZdWAxTHk0qoiET/S9lSbWFQmtOl97 o3Szxi5Pzcre2N4Rkdecghv7IR40CzdsbmPiPTQtmaBm6OS6BJvR7V+5+SrrhXjtg6YP IpiNARez3Vj9Yc7+UhBCmJFWQGlVPlJVlh2UNjEjdbCYq96kHjG//h/kbbveY8ZlGBKo RxKw== MIME-Version: 1.0 X-Received: by 10.49.131.164 with SMTP id on4mr6026316qeb.16.1389351020681; Fri, 10 Jan 2014 02:50:20 -0800 (PST) Received: by 10.229.189.9 with HTTP; Fri, 10 Jan 2014 02:50:20 -0800 (PST) In-Reply-To: References: Date: Fri, 10 Jan 2014 11:50:20 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=047d7bd751320e5fae04ef9b7e23 Cc: Tom Kristensen , "bfcpbis-chairs@tools.ietf.org" , "draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org" , "" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2014 10:50:35 -0000 --047d7bd751320e5fae04ef9b7e23 Content-Type: text/plain; charset=ISO-8859-1 Great. Thanks for the review. Comments inline. On 20 December 2013 14:26, Ali C. Begen (abegen) wrote: > I am the assigned SDP directorate reviewer for this draft. For background > on the SDP directorate, please see the FAQ at > > http://www.ietf.org/iesg/directorate/sdp.html > > Please wait for direction from your document shepherd or AD before posting > a new version of the draft. > Aye aye, Captain! Summary: > - There are a few minor issues as indicated below. > > Issues: > 1) Section 3 uses m= and refers to 4566 > but 4566 actually uses m= . > > The newly defined 4 values (TCP/BFCP, TCP/TLS/BFCP and the UDP > equivalents) are actually the proto values that are registered with IANA > (not transport values). Thus, I recommend changing the text to reflect this. > I agree. This is inherited from RFC 4583, but as long as RFC 4566 is referenced we should use a corresponding definition. I will change. > 2) Definition of "floorctrl" attribute. I think the answer has to include > only one role if the offer had this attribute. If that is correct, I > suggest the following change: > > OLD: > If an SDP media description in an offer contains a 'floorctrl' > attribute, the answerer accepting that media MUST include one in the > corresponding media description of the answer. > > NEW: > If an SDP media description in an offer contains a 'floorctrl' > attribute, the answerer accepting that media MUST include only one in > the > corresponding media description of the answer. > Yes, the answer must have one - and only one - floorctrl attribute value, i.e. role. However, in the last sentence of Section 4 it is stated that: The following is an example of a 'floorctrl' attribute in an offer. When this attribute appears in an answer, it only carries one role: I think that is sufficient and we haven't seen any cases of misinterpretation of this in the field! 3) There are a few "SHOULD"s. I think they are OK but it is not clear when > it is OK to ignore that SHOULD. If there are no such use cases, maybe they > can be replaced with a "MUST"? > This is inherited from the original RFC 4583, that's the main reason for me to suggest not changing this in this draft. Hopefully, that's fine? -- Tom -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --047d7bd751320e5fae04ef9b7e23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Great. Thanks for the review. Comments inline.

On 20 December 2013 14:26= , Ali C. Begen (abegen) <abegen@cisco.com> wrote:
I am the assigned SDP directorate reviewer for this draft.= For background on the SDP directorate, please see the FAQ at

http://www.ietf.org/iesg/directorate/sdp.html

Please wait for direction from your document shepherd or AD before posting = a new version of the draft.

Aye a= ye, Captain!

Summary:
- There are a few minor issues as indicated below.

Issues:
1) Section 3 uses m=3D<media> <port> <transport> <fmt&= gt; and refers to 4566 but 4566 actually uses m=3D<media> <port>= ; <proto> <fmt> .

The newly defined 4 values (TCP/BFCP, TCP/TLS/BFCP and the UDP equivalents)= are actually the proto values that are registered with IANA (not transport= values). Thus, I recommend changing the text to reflect this.

=A0I agree. This is inherited from RFC 4583, but = as long as RFC 4566 is referenced we should use a corresponding definition.= I will change.
=A0
2) Definition of "floorctrl" attribute. I think the answer has to= include only one role if the offer had this attribute. If that is correct,= I suggest the following change:

OLD:
=A0 =A0If an SDP media description in an offer contains a 'floorctrl= 9;
=A0 =A0attribute, the answerer accepting that media MUST include one in the=
=A0 =A0corresponding media description of the answer.

NEW:
=A0 =A0If an SDP media description in an offer contains a 'floorctrl= 9;
=A0 =A0attribute, the answerer accepting that media MUST include only one i= n the
=A0 =A0corresponding media description of the answer.
= =A0
Yes, the answer must have one - and only one - floorctr= l attribute value, i.e. role. However, in the last sentence of Section 4 it= is stated that:=A0

   The following is an examp=
le of a 'floorctrl' attribute in an offer.
   When this attribute appears in an answer, it only carries one role:

I think that is sufficient and we ha= ven't seen any cases of misinterpretation of this in the field!

3) There are a few "SHOULD"s. I think they are OK but it is not c= lear when it is OK to ignore that SHOULD. If there are no such use cases, m= aybe they can be replaced with a "MUST"?

This is inherited from the original RFC 4583, that'= ;s the main reason for me to suggest not changing this in this draft. Hopef= ully, that's fine?

-- T= om

--
# Cisco =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 | =A0h= ttp://www.cisco.com/telepresence/
## tomkrist@cisco.com =A0| =A0http://www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/
--047d7bd751320e5fae04ef9b7e23-- From trac+mmusic@trac.tools.ietf.org Fri Jan 10 04:27:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5966E1AD9B8 for ; Fri, 10 Jan 2014 04:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yVnF265kl40 for ; Fri, 10 Jan 2014 04:27:33 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 336781ACCE6 for ; Fri, 10 Jan 2014 04:27:33 -0800 (PST) Received: from localhost ([127.0.0.1]:33754 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W1bBD-0006xz-Ry; Fri, 10 Jan 2014 13:27:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "mmusic issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: hkaplan@acmepacket.com, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Fri, 10 Jan 2014 12:27:15 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/mmusic/trac/ticket/2#comment:2 Message-ID: <078.8958e9bd17aab684aa369b503bc5d8d8@trac.tools.ietf.org> References: <063.2ea57b41e0be5050c487b56fc2e0d848@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <063.2ea57b41e0be5050c487b56fc2e0d848@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, ari.keranen@ericsson.com, fandreas@cisco.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #2: Rules for Answerer payload type selection X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 12:27:35 -0000 #2: Rules for Answerer payload type selection Changes (by fandreas@cisco.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------ Reporter: hkaplan@acmepacket.com | Owner: hkaplan@acmepacket.com Type: defect | Status: closed Priority: major | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: fixed | Keywords: -------------------------------------+------------------------------------ Ticket URL: mmusic From ari.keranen@ericsson.com Fri Jan 10 08:00:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB881AE0E9 for ; Fri, 10 Jan 2014 08:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsF3rfEwSfUa for ; Fri, 10 Jan 2014 08:00:28 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DD1BD1AE0E7 for ; Fri, 10 Jan 2014 08:00:27 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-f4-52d0191193a6 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 7E.D6.27941.11910D25; Fri, 10 Jan 2014 17:00:17 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.347.0; Fri, 10 Jan 2014 17:00:17 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CB8121102D0; Fri, 10 Jan 2014 18:00:16 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 564F956501; Fri, 10 Jan 2014 18:00:13 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 05F4B56335; Fri, 10 Jan 2014 18:00:12 +0200 (EET) Message-ID: <52D01911.8030804@ericsson.com> Date: Fri, 10 Jan 2014 18:00:17 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" References: <20131209121243.31704.62698.idtracker@ietfa.amsl.com> <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> In-Reply-To: <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+Jvja6g5IUgg9avMhZTlz9msXh/fSWL xYnd2xgdmD2m/N7I6rFkyU+mAKYoLpuU1JzMstQifbsErozdMy4yFTzlqJi2vI+1gfEVWxcj J4eEgInExxe3oGwxiQv31gPZXBxCAkcYJSas2skM4WxglHj6/jhYlZDAHkaJV5eEIRJrGSW6 LzcyQySWM0p8vmsLYvMKaEvs3dDCBGKzCKhKLN16BqyGTcBe4uaE6+wgtqhAssS/JzdZIOoF JU7OfAJmiwgYSzQfOQpWwywQJPFo8wWwXmGBFIlrVxawQuwqkmjsuw1Uw8HBKWAr0TzVFKLc VuLCnOssELa8xPa3c5ghPlOTuHpuE9SZqhJX/71inMAoOgvJ5llI2mchaV/AyLyKkaM4tTgp N93IYBMjMAIObvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amA0q9lQeM3mVe3sw6q3rlUp1Hh0/NxR2fWs955cYmGlklP+zF8nSx4a63vevOW0tVGsWWPG sbB4teU+FTWrz9dG3Vh6iNfiJPuph6s71kwWL7+7bMrvM4X+83YJxKTXLbsi33FwbsGmzt3H VnAsUzikel9kV8LB7pUx/e+O7dpf9k73pO7d9ux8JZbijERDLeai4kQAmD/ttE4CAAA= Cc: mmusic , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2014 16:00:29 -0000 Hi, I read the latest draft and have a few questions. In Section 3 the draft says: > ICE [RFC5245] section 4.1.2 states that the formula in section > 4.1.2.1 SHOULD be used. Failing to do so may lead to ICE taking > longer to converge as the checklist no longer will be coordinated. > Therefore responsiveness of ICE candidate checks are improved when > both sides support Happy-Eyeballs, both sides have the same number of > candidate pairs, and both sides use the same Happy Eyeballs promotion > algorithm. Do you mean the checklist is no longer coordinated (i.e., matching on both sides) if all those requirements aren't fulfilled? That sounds a bit strange but that's the impression I got from the text. Also, if there is no coordination/signaling between the endpoints, what are the odds they'd end up using the same promotion algorithm? > If each ICE agent uses a different algorithm to promote IPv4 > candidates, ICE connectivity checks will be as responsive as the > least aggressive algorithm. What is "least aggressive algorithm"? Cheers, Ari From internet-drafts@ietf.org Fri Jan 10 08:40:25 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503FD1AE125; Fri, 10 Jan 2014 08:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9_K9bb-BRNZ; Fri, 10 Jan 2014 08:40:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E291AE137; Fri, 10 Jan 2014 08:40:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140110164022.28730.74692.idtracker@ietfa.amsl.com> Date: Fri, 10 Jan 2014 08:40:22 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:40:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Using Interactive Connectivity Establishment (ICE= ) with Session Description Protocol (SDP) offer/answer and Session Initiati= on Protocol (SIP) Authors : Marc Petit-Huguenin Ari Keranen Filename : draft-ietf-mmusic-ice-sip-sdp-01.txt Pages : 41 Date : 2014-01-10 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abegen@cisco.com Fri Jan 10 09:34:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5001AE108 for ; Fri, 10 Jan 2014 09:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhkljOpq6mAk for ; Fri, 10 Jan 2014 09:34:43 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F3ECE1AE0DE for ; Fri, 10 Jan 2014 09:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=523; q=dns/txt; s=iport; t=1389375273; x=1390584873; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dCAtQ0Pu1PPjh7DeTTAJ4PDDOAKu9B2jSPJueqLRgE0=; b=WhVq/tSSBnb/W6gG1EF1Hg+f/npEZ0hWoWmxc9bMJyrn1oC97yZLDGIH F+SbpdgLq1aJMXJg4f6VVAQQuPTSPBUG/HwClP7//l8gAiS+Q4KehPHnp zDEqakJvDVvdKb7vuIe1Wqyn9Kdgx/c0AeyIdKinwXdGHMhFlq7aQtoOs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOot0FKtJXG+/2dsb2JhbABZgmohgQ65SIEIFnSCJQEBAQMBeQULAgEIDjghESUCBA4Fh3ADCQgBvXQNhSEXjHWBYDMHgySBEwEDiQuNIIFsjFqFO4Mtgio X-IronPort-AV: E=Sophos;i="4.95,639,1384300800"; d="scan'208";a="296534777" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jan 2014 17:34:33 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0AHYW5c020440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jan 2014 17:34:32 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Fri, 10 Jan 2014 11:34:32 -0600 From: "Ali C. Begen (abegen)" To: Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08 Thread-Index: AQHO/YcWZ2DzntYTsE+pusHe8am5zZp+TQkAgABw7wA= Date: Fri, 10 Jan 2014 17:34:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.156.48.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6E1C7F8E18DD4545A065A619304A2C76@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tom Kristensen \(tomkrist\)" , "bfcpbis-chairs@tools.ietf.org" , "draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org" , "" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2014 17:34:44 -0000 On Jan 10, 2014, at 2:50 AM, Tom Kristensen <2mkristensen@gmail.com> wrote: > 3) There are a few "SHOULD"s. I think they are OK but it is not clear whe= n it is OK to ignore that SHOULD. If there are no such use cases, maybe the= y can be replaced with a "MUST"? >=20 > This is inherited from the original RFC 4583, that's the main reason for = me to suggest not changing this in this draft. Hopefully, that's fine? Well I guess IESG will have issues with this, so take this as a warning :) >=20 > -- Tom From internet-drafts@ietf.org Fri Jan 10 09:37:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0678D1AE138; Fri, 10 Jan 2014 09:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4HfPOMEsUya; Fri, 10 Jan 2014 09:37:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA641AE11D; Fri, 10 Jan 2014 09:37:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140110173751.11928.89627.idtracker@ietfa.amsl.com> Date: Fri, 10 Jan 2014 09:37:51 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 17:37:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Using Interactive Connectivity Establishment (ICE= ) with Session Description Protocol (SDP) offer/answer and Session Initiati= on Protocol (SIP) Authors : Marc Petit-Huguenin Ari Keranen Filename : draft-ietf-mmusic-ice-sip-sdp-02.txt Pages : 41 Date : 2014-01-10 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From palmarti@cisco.com Mon Jan 13 03:46:34 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44EF1AE020 for ; Mon, 13 Jan 2014 03:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.739 X-Spam-Level: X-Spam-Status: No, score=-9.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW_3_q4q-cLW for ; Mon, 13 Jan 2014 03:46:33 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 295E11AE115 for ; Mon, 13 Jan 2014 03:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3429; q=dns/txt; s=iport; t=1389613582; x=1390823182; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1/fR9SMJvB9UMTJgGSdcaPEGkSklujYYNIPHtSdtJaU=; b=MIAXbMgED5ygvNExwh1Go3LgGNmvyUfrlmf7UIq7xOikvU/qfu0s6KVV 36/hf1Z2Be6066Vj+4EMY94MKcnY75PhIO2rvEQl4N340ykfopiNHQzbE m1L/QdMuv7WlBYXJGyVWSgBYC1fxzIrDghLG6NXpHIiwK1e9wNvS4q5ir w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFABPR01KtJXG//2dsb2JhbABagwuBDrlrgQ4WdIIlAQEBAwF3AgULAgEIRjIlAgQOBYd8CMRtF442AQEcMweDJIETAQOYF5IVgW+BPoFxOQ X-IronPort-AV: E=Sophos;i="4.95,652,1384300800"; d="scan'208";a="12433918" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-8.cisco.com with ESMTP; 13 Jan 2014 11:46:22 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0DBkMN9019196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 11:46:22 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 05:46:21 -0600 From: "Pal Martinsen (palmarti)" To: =?Windows-1252?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt Thread-Index: AQHPEFUUlb4N8W3Wl06M5kiJnPk5wQ== Date: Mon, 13 Jan 2014 11:46:21 +0000 Message-ID: <647464EE-B8E0-47FA-A375-8C758046D854@cisco.com> References: <20131209121243.31704.62698.idtracker@ietfa.amsl.com> <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> <52D01911.8030804@ericsson.com> In-Reply-To: <52D01911.8030804@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.194.75] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6124457354B5FD43B3F64D63CDD6CF7B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2014 11:46:34 -0000 On 10 Jan 2014, at 17:00 pm, Ari Ker=E4nen wrote= : > Hi, >=20 > I read the latest draft and have a few questions. In Section 3 the draft = says: >=20 >> ICE [RFC5245] section 4.1.2 states that the formula in section >> 4.1.2.1 SHOULD be used. Failing to do so may lead to ICE taking >> longer to converge as the checklist no longer will be coordinated. >> Therefore responsiveness of ICE candidate checks are improved when >> both sides support Happy-Eyeballs, both sides have the same number of >> candidate pairs, and both sides use the same Happy Eyeballs promotion >> algorithm. >=20 > Do you mean the checklist is no longer coordinated (i.e., matching on bot= h sides) if all those requirements aren't fulfilled? That sounds a bit stra= nge but that's the impression I got from the text. What we tried to say was that if the two agents have different Happy Eyebal= l Algorithms ICE might take longer to complete. Both Alice and Bob used the following formula to sort the checklist: After = N numbers of IPv6 addresses, add M numbers of IPv4 addresses.=20 Alice(N=3D4, M=3D1) Bob(N=3D2,M=3D1) 1 IPv6 IPv6 2 IPv6 IPv6 3 IPv6 IPv4(*) 4 IPv6 IPv6 5 IPv4(*) IPv6 6 IPv6 IPv4(*) 7 IPv6 IPv6 8 IPv6 IPv6 9 IPv6 IPv4(*) 10 IPv4(*) IPv6 11 IPv6 IPv6 12 IPv6 IPv4(*) 13 IPv6 IPv6 14 IPv6 IPv6 15 IPv4(*) 16 IPv4(*) The initial thought was that having for example different M and N values w= ould cause ICE to take longer to complete. But due to triggered checks diff= erent M and N values might actually speed up the ICE negotiation.=20 I will update the text using this simple example algorithm, and rewrite Sec= tion 3. >=20 > Also, if there is no coordination/signaling between the endpoints, what a= re the odds they'd end up using the same promotion algorithm? >=20 Exactly, and that might be an advantage..=20 >> If each ICE agent uses a different algorithm to promote IPv4 >> candidates, ICE connectivity checks will be as responsive as the >> least aggressive algorithm. >=20 > What is "least aggressive algorithm=94? Good question. Regarding what the meaning was I think it was wron. Rereading the entire draft myself. I realise it is in a pretty bad state. I= will do a full rewrite focusing on: 1. Explaining the need for the draft. (Get IPv6 path a head start so we cho= ose that, but try to minimize the delay if the path is broken) 2. Get rid of generic IP address language. We are dealing with IPv6 and IPv= 4. That is not going to change for a while. (Haing language as if IPv8 was = just around the corner just makes it harder to read) 3. Add example algorithm as described in this mail Thanks for the review, will submit a 05 version before next IETF.=20 .-. P=E5l-Erik >=20 >=20 > Cheers, > Ari From praspati@cisco.com Mon Jan 13 05:39:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E2D1AE15F for ; Mon, 13 Jan 2014 05:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.739 X-Spam-Level: X-Spam-Status: No, score=-9.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-XOEmz6rimX for ; Mon, 13 Jan 2014 05:39:38 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5F91AE074 for ; Mon, 13 Jan 2014 05:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1832; q=dns/txt; s=iport; t=1389620367; x=1390829967; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LaE1sEzRac1yJQc741HeYun/0F/k0smzygnptVr+yGI=; b=ZopyGYrHUQPmTWPYxQhVhCcv5F9lR8gdKBKDUUQwze7kfeHoWP3iiiEU vlqn2ZuShYcp7i5MxNdh1FS5j+RSIPEr+UuL3XR7jd0tFji3PeSK9O1Vf /NA3vrNufPwV8mFiYlUVBueAVGmlK/9PcKgUvkarNd5nIOl2qo9DRwyHb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAADs01KtJV2Y/2dsb2JhbABagws4VrkeT4EQFnSCJgEBBAEBAWsJAhACAQhGJwslAgQBDQWIBA3EdRMEjlQzB4Q3AQOJC48MkhWBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208";a="12454864" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 13 Jan 2014 13:39:26 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0DDdP1v025981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 13:39:26 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.150]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 07:39:26 -0600 From: "Prashanth Patil (praspati)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "Pal Martinsen (palmarti)" Thread-Topic: [MMUSIC] Fwd: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt Thread-Index: AQHO9Nf3jpKLOm73R0eAgHrV7oAIYA== Date: Mon, 13 Jan 2014 13:39:24 +0000 Message-ID: References: <20131209121243.31704.62698.idtracker@ietfa.amsl.com> <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> <52D01911.8030804@ericsson.com> In-Reply-To: <52D01911.8030804@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [173.39.64.122] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2014 13:39:40 -0000 Hi Ari, On 1/10/14 9:30 PM, "Ari Ker=E4nen" wrote: >Hi, > >I read the latest draft and have a few questions. In Section 3 the draft >says: > >> ICE [RFC5245] section 4.1.2 states that the formula in section >> 4.1.2.1 SHOULD be used. Failing to do so may lead to ICE taking >> longer to converge as the checklist no longer will be coordinated. >> Therefore responsiveness of ICE candidate checks are improved when >> both sides support Happy-Eyeballs, both sides have the same number of >> candidate pairs, and both sides use the same Happy Eyeballs promotion >> algorithm. > >Do you mean the checklist is no longer coordinated (i.e., matching on >both sides) if all those requirements aren't fulfilled? That sounds a >bit strange but that's the impression I got from the text. > >Also, if there is no coordination/signaling between the endpoints, what >are the odds they'd end up using the same promotion algorithm? > >> If each ICE agent uses a different algorithm to promote IPv4 >> candidates, ICE connectivity checks will be as responsive as the >> least aggressive algorithm. > >What is "least aggressive algorithm"? Since there is no signaling between the end points, each end point could promote IPv4 to different positions in the checklist. Based on candidate pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0), the end point tha= t has promoted IPv4 in the least aggressive fashion i.e. IPv4 lower in its list when compared to the other end point, will influence the candidate priority pairing due to (2^32*MIN(G,D)) in the formula. Thanks, Prashanth > > >Cheers, >Ari >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From eckelcu@cisco.com Mon Jan 13 18:05:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D44D1AE1A7 for ; Mon, 13 Jan 2014 18:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAo04IL7BvB2 for ; Mon, 13 Jan 2014 18:05:33 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 819F81AE1A1 for ; Mon, 13 Jan 2014 18:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4245; q=dns/txt; s=iport; t=1389665123; x=1390874723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5uulkvGxqwCimIrYRAQRCByei6VVyVm81VMp8LVZKx8=; b=hc64xY8FFMs0WtPEFfHTeY8yrfnU4gmN6qs8l06R9cVc6alNq/OsHW/t O1MH5mPu+0jUhkdUxn3daX8icz+tX2la9sPy6BRLZPpWgj3/D+y7XXFCd dnyvYBPSQtar094U1viFXAd4OuJMj/T9utxbV4DgsnDT/45HzO+MyjtKs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAMea1FKtJXG//2dsb2JhbABQCAKDCzhWuTJPgRYWdIImAQEEAQEBNzQLEAIBCC4IECEGCyUCBAENBYdwAxENwA0NhR0XjHSBN1wHEguEGgSUM4F4gWyBMIsqhTuDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,656,1384300800"; d="scan'208";a="294109076" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 14 Jan 2014 02:05:22 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0E25MF0028886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 02:05:22 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 20:05:21 -0600 From: "Charles Eckel (eckelcu)" To: "Ali C. Begen (abegen)" , Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08 Thread-Index: AQHO/YcWZ2DzntYTsE+pusHe8am5zZp+TQkAgABw7wCABL+ZAA== Date: Tue, 14 Jan 2014 02:05:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.85.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <507D45A6343C8D4D809A03CC330C2A42@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "bfcpbis-chairs@tools.ietf.org" , "draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org" , "Tom Kristensen \(tomkrist\)" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2014 02:05:35 -0000 I am afraid Ali is right. Let's take the SHOULDs 1 by 1 and see how to deal with them. 1) From section 3: "The fmt (format) list is ignored for BFCP. The fmt list of BFCP 'm' The fmt (format) list is ignored for BFCP. The fmt list of BFCP 'm' lines SHOULD contain a single "*" character." This is inherited from RFC 4583. I see no reason to not use '*'. Unless someone can identify one, I suggest changing to "MUST". 2) From section 4: "Endpoints that use the offer/answer model to establish BFCP connections MUST support the 'floorctrl' attribute. A floor control server acting as an offerer or as an answerer SHOULD include this attribute in its session descriptions. If the 'floorctrl' attribute is not used in an offer/answer exchange, by default the offerer and the answerer will act as a floor control client and as a floor control server, respectively." I think this is okay as is. 3) From section 5: "Endpoints that use the offer/answer model to establish BFCP connections MUST support the 'confid' and the 'userid' attributes. A floor control server acting as an offerer or as an answerer SHOULD include these attributes in its session descriptions." This is inherited form RFC 4583. I have seen clients not including these in an offer, but I cannot think of a case in which a server would not include them these. I suggest changing to "MUST". 4) From section 6: "Endpoints that use the offer/answer model to establish BFCP connections MUST support the 'floorid' and the 'label' attributes. A floor control server acting as an offerer or as an answerer SHOULD include these attributes in its session descriptions." This is inherited form RFC 4583. I cannot think of a case in which a server would not include these. I suggest changing to "MUST". 5) There are several SHOULDs in section 7, which defines the new bfcpver attribute. As this attribute did not exist in RFC 4583, the SHOULDs are warranted for backward compatibility. However, they can be made mandatory for implementations of BFCP/UDP as well as those compliant with this update to RFC 4583. The only should for which this is not the case is the following: "Tokens representing versions SHOULD be integers matching the "Version" field that would be presented in the BFCP COMMON-HEADER [8 ]." I think this can be changed to "MUST" for all cases. 6) From section 8.1: "When the existing TCP connection is reset following the rules in [8 ], the client SHOULD generate an offer towards the floor control server in order to reestablish the connection. If a TCP connection cannot deliver a BFCP message and times out, the entity that attempted to send the message (i.e., the one that detected the TCP timeout) SHOULD generate an offer in order to reestablish the TCP connection." I am not sure about these. I think they could be changed to "MUST". Hopefully others can chime in. 7) Section 9 reads as follows: "Endpoints that use the offer/ answer model to establish BFCP connections MUST support the 'fingerprint' attribute and SHOULD include it in their session descriptions." I think this can be changed to "MUST"; however, I would appreciate additional opinions on this one as well. Cheers, Charles On 1/10/14 9:34 AM, "Ali C. Begen (abegen)" wrote: > >On Jan 10, 2014, at 2:50 AM, Tom Kristensen <2mkristensen@gmail.com> >wrote: > >> 3) There are a few "SHOULD"s. I think they are OK but it is not clear >>when it is OK to ignore that SHOULD. If there are no such use cases, >>maybe they can be replaced with a "MUST"? >>=20 >> This is inherited from the original RFC 4583, that's the main reason >>for me to suggest not changing this in this draft. Hopefully, that's >>fine? > >Well I guess IESG will have issues with this, so take this as a warning :) > >>=20 >> -- Tom > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Tue Jan 14 04:47:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A73B1AE0C8 for ; Tue, 14 Jan 2014 04:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L_2pMY4rHIt for ; Tue, 14 Jan 2014 04:47:02 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BCDEF1AE0BD for ; Tue, 14 Jan 2014 04:47:01 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-d1-52d531b9ddd9 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 82.41.15980.9B135D25; Tue, 14 Jan 2014 13:46:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0347.000; Tue, 14 Jan 2014 13:46:49 +0100 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" , "mmusic@ietf.org" Thread-Topic: Review (by Albrecht) of draft-ietf-mmusic-udptl-dtls-02 Thread-Index: Ac78BetKtAzG5MiCRciuBhIxNigaawVG7NHA Date: Tue, 14 Jan 2014 12:46:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5F9C35@ESESSMB209.ericsson.se> References: <786615F3A85DF44AA2A76164A71FE1AC1230F3@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC1230F3@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5F9C35ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje5Ow6tBBh/+Klj8af3FaDF1+WMW ByaP1md7WT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxdvMt9oK16xgrPj5OaGDcPJOxi5GTQ0LA ROLX9K1sELaYxIV764FsLg4hgUOMEs9W3mOGcJYwSnzc8wgow8HBJmAh0f1PG6RBRCBf4tiW Y+wgtrCAi8THL91sEHFXieN/ZoGViwgYSVx6kAISZhFQldi66AkTSJhXwFfi4exAkLCQQJTE kmsdrCA2p0C0xOYfK8CmMAKd8/3UGiYQm1lAXOLWk/lMEGcKSCzZc54ZwhaVePn4HyvISAkB RYnl/XIQ5fkSc49vYwGxeQUEJU7OfMIygVFkFpJJs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY +8yBx0zI4gsY2VcxsucmZuakl5tvYgTGzcEtvw12MG66L3aIUZqDRUmc98Nb5yAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjG1dv2I2hz2xT8r2P2T/VqnFbdK8d1PmdGfqf1+4bHGfW2MJ k3lWzWMhSQWbtX8jyk3Stxp8tPGRWzh76oTzHrUNNa/0H9+cX/D5fD5Daof/Ff8v+lOVxFb8 2SdYefrIr4nvO2rDv79axa7MKhgtx8uQp73wY+6mx1b5HVwfxJfeurt1U/PcZUosxRmJhlrM RcWJAOnHYkVpAgAA Subject: Re: [MMUSIC] Review (by Albrecht) of draft-ietf-mmusic-udptl-dtls-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2014 12:47:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C5F9C35ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Albrecht, I am sorry that it took a while to address your comments, but here we go :) Comment inline. I try to shorten your suggested text, by keeping the essent= ial parts, and prevent adding long notes. ----------------------------- to 3.1. Secure Channel Establishment Paragraph: In addition to the usual contents of an SDP media description ("m=3D" line) specified for UDPTL over the UDP, each SDP media description for UDPTL over DTLS over the UDP will also contain several SDP attributes, as specified in [RFC4145= ] and [RFC4572]. proposed to be detailed by: In addition to the usual contents of an SDP media description ("m=3D" line) specified for UDPTL over the UDP, each SDP media description for UDPTL over DTLS over the UDP will also contain several SDP attributes, which were introduced in the context of TCP and TLS (but reu= sed here for DTLS-over-UDP), as specified in [RFC4145] (TCP) and [RFC4572] (TL= S). I suggest the following: In addition to the usual contents of an SDP media description ("m=3D" line) specified for UDPTL over UDP, each SDP media description for UDPTL over DTLS over UDP will also contain several SDP attributes (which were introduced in the context of TCP [RFC4145] and TLS [4572], and re-used in this document). ----------------------------- List item: o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer SHOULD assign the SDP setup attribute with a setup:actpass value, and MAY assign the SDP setup attribute with a setup:active value or setup:passive value. The offerer MUST NOT assign the SDP setup attribute with a setup:holdconn value. If the offerer ... proposed to add further background information: o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer SHOULD assign the SDP setup attribute with a setup:actpass value, and MAY assign the SDP setup attribute with a setup:active value or setup:passive value (NOTE: these rules allow to decouple the= establishment direction of the DTLS session from the establishment directi= on of the SIP session (which may be demanded due to security considerations= , NAT traversal aspects, etc.)). The offerer MUST NOT assign the SDP setup attribute with a setup:holdconn value. If the offerer .... I suggest to simply say following: "In order to negotiate the TLS roles, the endpoint MUST use= the SDP setup attribute [RFC4145]." I don't think we need the other text. It's really not the main scope of the= document. Other DTLS protocols also use the setup attribute to determine the TLS roles, and we are simply doing the same thin= g. ----------------------------- to 3.2. Secure Channel Usage Paragraph: DTLS is used as specified in [RFC6347]. Once the DTLS handshake is completed, the UDPTL packets SHALL be transported in DTLS record layer "application_data" packets. proposed to be detailed by: DTLS is used as specified in [RFC6347]. Once the DTLS handshake is successfully completed, the UDPTL packets SHALL be transported in DTLS r= ecord layer "application_data" packets. NOTE: such a proceeding ensures that the application (i.e., T.38) does not = start to transmit facsimile data already during an ongoing underlying DTLS = session establishment. This aspect might be important for end-to-end scenar= ios with gateway equipment and a possible "UDPTL/DTLS/UDP-to-UDPTL/UDP" int= erworking function). I suggest the following: "DTLS is used as specified in [RFC6347]. Once the DTLS handshake is successfully completed (in order to prevent facsimile data from bei= ng transmitted insecurely), the UDPTL packets SHALL be transported in = DTLS record layer "application_data" packets." ----------------------------- Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C5F9C35ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Albrecht,

 

I am sorry that it too= k a while to address your comments, but here we go :)

 

Comment inline. I try = to shorten your suggested text, by keeping the essential parts, and prevent= adding long notes.

 

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

=  

to 3.1.  Secure Channel Establishment

=       Paragraph:

   In addition to the usual contents of=
 an SDP media description ("m=3D"
   line) specified for UDPTL over the U=
DP, each SDP media description
   for UDPTL over DTLS over the UDP wil=
l also contain several SDP
   attributes, as specified in [RFC4145] and [RFC4572].=

=  

proposed to be detailed by:<= /p>

=  

   In addition to the usual contents of=
 an SDP media description ("m=3D"
   line) specified for UDPTL over the U=
DP, each SDP media description
   for UDPTL over DTLS over the UDP wil=
l also contain several SDP
   attributes, which were introduced in the context of TCP and TLS (but reused here for =
DTLS-over-UDP), as specified in [RFC4145] (TCP) and [RFC4572] (TLS).

 

I sugge= st the following:

&n= bsp;

In= addition to the usual contents of an SDP media description ("m=3D&quo= t; 

      line) specified fo=
r UDPTL over UDP, each SDP media description
      for UDPTL over DTL=
S over UDP will also contain several SDP
      attributes (which were introduced in the context of TCP [RFC414=
5] 
    &=
nbsp; and TLS [4572], and re-used in this document).=

 

&n= bsp;

 

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

&n= bsp;

&n= bsp;

= List item:

   o  The endpoint MUST use the SD=
P setup attribute [RFC4145].  The
      offerer SHOULD ass=
ign the SDP setup attribute with a setup:actpass
      value, and MAY ass=
ign the SDP setup attribute with a setup:active
      value or setup:pas=
sive value.  The offerer MUST NOT assign the SDP

      setup attribute wi=
th a setup:holdconn value.  If the offerer …

=
 


=
proposed to add further background information:


   o  The endpoint MUST use the SD=
P setup attribute [RFC4145].  The


      offerer SHOULD ass=
ign the SDP setup attribute with a setup:actpass


      value, and MAY ass=
ign the SDP setup attribute with a setup:active


      value or setup:pas=
sive value (NOTE: these rules allow to decouple t=
he establishment direction of the DTLS session from the establishment direc=
tion of the SIP session (which may be demanded due to security consideratio=
ns, NAT traversal aspects, etc.)).  
The offerer MUST NOT as=
sign the SDP


      setup attribute wi=
th a setup:holdconn value.  If the offerer ….<=
/pre>

 


I sugge=
st to simply say following:


&n=
bsp;


 &=
nbsp;           &nbs=
p;  “In orde=
r to negotiate the TLS roles,
the endpoint MUST use the SDP setup attribute [=
RFC4145].=
”


 


I don’t think we=
 need the other text. It's really not the main scope of the document. Other=
 DTLS protocols also use the setup



attribute to determine=
 the TLS roles, and we are simply doing the same thing.

<=
o:p> 


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


&n=
bsp;


&n=
bsp;


&n=
bsp;


to 
3.2.  Secure Channel Usage


 


=
      Paragraph:


   DTLS is used as specified in [RFC6347].  Once the DTLS handsha=
ke is


   completed, the UDPTL packets SHALL b=
e transported in DTLS record


   layer "application_data" p=
ackets.


=
 


proposed to be detailed by:<=
/p>

   DTLS is used as specified in [RFC6347].  Once the DTLS handsha=
ke is


   successful=
ly completed, the UDPTL packets SHALL be transported in DTLS record<=
o:p>


   layer "application_data" p=
ackets.
NOTE: such a proceeding ensures that t=
he application (i.e., T.38) does not start to transmit facsimile data alrea=
dy during an ongoing underlying DTLS session establishment. This aspect mig=
ht be important for end-to-end scenarios with gateway equipment and a possi=
ble “UDPTL/DTLS/UDP-to-UDPTL/UDP” interworking function).


&n=
bsp;


I sugge=
st the following:


&n=
bsp;


        “DTLS is used as specified in [RFC6347]=
.  Once the DTLS handshake is


     =
   successfully completed (in order to prevent facsimile data fro=
m being 


    &=
nbsp;   transmitted insecurely), the UDPTL packets SHALL be trans=
ported in DTLS 


    &=
nbsp;   record layer "application_data" packets.”=



&n=
bsp;


&n=
bsp;


 


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


&n=
bsp;


Regards=
,


&n=
bsp;


Christe=
r


&n=
bsp;
--_000_7594FB04B1934943A5C02806D1A2204B1C5F9C35ESESSMB209erics_-- From abegen@cisco.com Tue Jan 14 11:49:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7C41AE1F6 for ; Tue, 14 Jan 2014 11:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ49Ns_avk4m for ; Tue, 14 Jan 2014 11:49:41 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6E28A1AE1DC for ; Tue, 14 Jan 2014 11:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=499; q=dns/txt; s=iport; t=1389728970; x=1390938570; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=NDaLeAui4Y/20W+n0PNg62nkHFShoY4ln9nS2O8jVEc=; b=RlljX/PhdbQuAJ/AGfyO67HTdaQd9xIz+8M78A9zkoirym6J1Xcf4vrC 9nuDfXKLw9giJgao38qWoPQjkYZZ42/y5PdXOriJgwPS5f9XAha6taMvZ SFbbr4ud9wvwGOjLnPufqdPdPWERmowm1aLJjt+GaCdo/Ub4kXI1eJ7cI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAMqT1VKtJXG//2dsb2JhbABagmohOFaodpMHFnSCLDpRAT5CJwSIFwEMmROqZReSMoETBJgegTCQZYMtgio X-IronPort-AV: E=Sophos;i="4.95,659,1384300800"; d="scan'208";a="12814016" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-1.cisco.com with ESMTP; 14 Jan 2014 19:49:29 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0EJnUc2023324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 14 Jan 2014 19:49:30 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 13:49:29 -0600 From: "Ali C. Begen (abegen)" To: "" Thread-Topic: Issue tracker for 4566bis Thread-Index: AQHPEWG8F/foggAQEEyGL+H7582LcA== Date: Tue, 14 Jan 2014 19:49:28 +0000 Message-ID: <55D7A835-54DD-4803-94C3-062D1108E0D6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.95] Content-Type: text/plain; charset="us-ascii" Content-ID: <2CDB922857D22B49B20F47E43BEBAF2A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Issue tracker for 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2014 19:49:44 -0000 Hi everyone Revising 4566 is underway as you know and there have been some issues with = 4566 and some folks want them to be fixed in 4566bis. However, due to convo= luted discussions, some of these issues go unfixed. To make the process eas= ier, it was suggested to establish an issue tracker. I have not done this before, but found the link below: http://tools.ietf.org/wg/mmusic/trac/report/1 Is this a good idea to use this or do you have better suggestions? Thanks, -acbegen From pkyzivat@alum.mit.edu Wed Jan 15 10:24:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A992C1AE389 for ; Wed, 15 Jan 2014 10:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92iqMU-vfXIj for ; Wed, 15 Jan 2014 10:24:35 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D31AE17A for ; Wed, 15 Jan 2014 10:24:35 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta02.westchester.pa.mail.comcast.net with comcast id EFgj1n0040Fqzac51JQPnp; Wed, 15 Jan 2014 18:24:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id EJQN1n00w3ZTu2S3UJQPKZ; Wed, 15 Jan 2014 18:24:23 +0000 Message-ID: <52D6D256.3020301@alum.mit.edu> Date: Wed, 15 Jan 2014 13:24:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <55D7A835-54DD-4803-94C3-062D1108E0D6@cisco.com> In-Reply-To: <55D7A835-54DD-4803-94C3-062D1108E0D6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389810263; bh=KXHMcywyAexVAQHyCl7vWF4gpXBdb+EP6JktWxtoUzk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=O+UiYLQ9k4QuNux7zAmaZ43A5HVqltA+aVKxiL1+f+c7T5tOpYD0cCXuQ+iT6UDj0 zAxQKPAXMP5m+Ye7SFyfP6vlcvOqqgwnLoo/YZxn6irMxIC6JXOwCSGC9LoHSMRzpT Oe+5i5AJmzJQSbW/7h5SamWNgT5A7EWMkNipQrdikYNh8x71Dhm2YrZdmvpRzoK4G5 9T4CQqaxOaPmBCnjzOW6FrZqD+oWwke2TDIRdg66srEMWNIk9wXy4NLx7e2IIbbtWk 3XtXJbP8kFqFhVOHSYrSJEg65sF12gCBnLBcwpcgp4ycN0jVbjh7B7caTledYKDz4p 4gYJ5Q13IU8CQ== Subject: Re: [MMUSIC] Issue tracker for 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 18:24:36 -0000 On 1/14/14 2:49 PM, Ali C. Begen (abegen) wrote: > Hi everyone > > Revising 4566 is underway as you know and there have been some issues with 4566 and some folks want them to be fixed in 4566bis. However, due to convoluted discussions, some of these issues go unfixed. To make the process easier, it was suggested to establish an issue tracker. > > I have not done this before, but found the link below: > http://tools.ietf.org/wg/mmusic/trac/report/1 > > Is this a good idea to use this or do you have better suggestions? This is just a link to a report of active tickets. Are you just asking if doing something analogous for 4566bis would be a good thing? I think the issue tracker is fine if you, as editor, use it to track the issues with your document. But I strongly suggest that you be the only one to open, update, and close tickets for 4566bis. Don't leave it for anybody who thinks they have an issue to open their own ticket, and don't use updates to the tickets as a way to debate an issue. I saw that done once or twice and it created a mess - confusing established mechanisms for discussing issues via email. So IMO we should continue to *discuss* proposed changes on the mmusic list. Based on those discussions you can make tickets as you see fit to track the status of identified issues and their incorporation into the draft. Thanks, Paul From internet-drafts@ietf.org Wed Jan 15 14:34:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485C71AE3E1; Wed, 15 Jan 2014 14:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9S_8g0jraja; Wed, 15 Jan 2014 14:34:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEA91AE22B; Wed, 15 Jan 2014 14:34:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140115223418.31458.94390.idtracker@ietfa.amsl.com> Date: Wed, 15 Jan 2014 14:34:18 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 22:34:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Interactive Connectivity Establishment (ICE): A P= rotocol for Network Address Translator (NAT) Traversal for Offer/Answer Pro= tocols Authors : Ari Keranen Jonathan Rosenberg Filename : draft-ietf-mmusic-rfc5245bis-01.txt Pages : 87 Date : 2014-01-15 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). This document obsoletes RFC 5245. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc5245bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc5245bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abegen@cisco.com Thu Jan 16 09:37:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE431AE171 for ; Thu, 16 Jan 2014 09:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaSWD3rMY2zU for ; Thu, 16 Jan 2014 09:37:42 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 33C7B1AE116 for ; Thu, 16 Jan 2014 09:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2016; q=dns/txt; s=iport; t=1389893850; x=1391103450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YFZapA/Zb/TcELVqAgQc8jPQBPnn1JtfBuOmFAIduV0=; b=l5bzMErvznyTm7oLDQbQX58BJbKIV8izDknaSo5mWMxGVDkTwzA6gAMB p/9Z0BsS2C8usmSkQahGvRtvhblFyS2ozJo4r48kdIEiC7V+g0FgfdV5c C05belw3iSEBCkSxkAzUUVLIOvU7ytDHHEYjlWJJTauRNPlbteNYMOjR+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFABQY2FKtJXG+/2dsb2JhbABZDoJcIThWujxPgQ4WdIIlAQEBAwEBAQE3NAsFCwIBCA4KHhAnCyUCBA4FG4dhCAEMxGEXjh0RAQsSMweDJIEUBJghgTGQZoJuP4FxOQ X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208";a="13371827" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 16 Jan 2014 17:37:29 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0GHbTBU019662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Jan 2014 17:37:29 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 16 Jan 2014 11:37:29 -0600 From: "Ali C. Begen (abegen)" To: Paul Kyzivat Thread-Topic: [MMUSIC] Issue tracker for 4566bis Thread-Index: AQHPEWG8F/foggAQEEyGL+H7582LcJqGf9cAgAGFPwA= Date: Thu, 16 Jan 2014 17:37:29 +0000 Message-ID: References: <55D7A835-54DD-4803-94C3-062D1108E0D6@cisco.com> <52D6D256.3020301@alum.mit.edu> In-Reply-To: <52D6D256.3020301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.225] Content-Type: text/plain; charset="us-ascii" Content-ID: <042D7ECA2E9A0141812F357768D01B19@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [MMUSIC] Issue tracker for 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 17:37:44 -0000 On Jan 15, 2014, at 10:24 AM, Paul Kyzivat wrote: > On 1/14/14 2:49 PM, Ali C. Begen (abegen) wrote: >> Hi everyone >>=20 >> Revising 4566 is underway as you know and there have been some issues wi= th 4566 and some folks want them to be fixed in 4566bis. However, due to co= nvoluted discussions, some of these issues go unfixed. To make the process = easier, it was suggested to establish an issue tracker. >>=20 >> I have not done this before, but found the link below: >> http://tools.ietf.org/wg/mmusic/trac/report/1 >>=20 >> Is this a good idea to use this or do you have better suggestions? >=20 > This is just a link to a report of active tickets. > Are you just asking if doing something analogous for 4566bis would be a g= ood thing? >=20 > I think the issue tracker is fine if you, as editor, use it to track the = issues with your document. >=20 > But I strongly suggest that you be the only one to open, update, and clos= e tickets for 4566bis. Don't leave it for anybody who thinks they have an i= ssue to open their own ticket, and don't use updates to the tickets as a wa= y to debate an issue. I saw that done once or twice and it created a mess -= confusing established mechanisms for discussing issues via email. >=20 > So IMO we should continue to *discuss* proposed changes on the mmusic lis= t. Based on those discussions you can make tickets as you see fit to track = the status of identified issues and their incorporation into the draft. Fine with me. I will try to create and track the issues in that list (so ev= erybody can know where we are) and people should post their comments about = the 4566bis in the list. But, please be clear on what the problem is and pr= ovide a solution if you can so that we can move faster. thanks. -acbegen >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Thu Jan 16 14:28:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7B81A1F78 for ; Thu, 16 Jan 2014 14:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrMehh-P70Xm for ; Thu, 16 Jan 2014 14:28:34 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 84FD51A1F62 for ; Thu, 16 Jan 2014 14:28:34 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta14.westchester.pa.mail.comcast.net with comcast id El061n0031ei1Bg5EmUMwQ; Thu, 16 Jan 2014 22:28:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id EmUM1n00g3ZTu2S3kmUMVN; Thu, 16 Jan 2014 22:28:21 +0000 Message-ID: <52D85D05.5050907@alum.mit.edu> Date: Thu, 16 Jan 2014 17:28:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <55D7A835-54DD-4803-94C3-062D1108E0D6@cisco.com> <52D6D256.3020301@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389911301; bh=3uQsdN8xjJdwTk7JFiGe4A09E72jKvBDOuZtTjfdkTc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PkT8XYCf95Zkpc8A9lKwFa4K2gZF7GKw7Xh/U5k/KN2aaJQQXN6i0GRorxg8tcKAn c6zN5N9y2ljF9oObspAhsBg/Ok9SyfMQbaitUlGRce0axH4rjPevC9Y7Khm797SI2Z weewVPtYszkZX7PJmLIiIkqPpyxkwd3bxO4inBT4plXU5xhlCqyaCLcUe4tBRnQ9sU ty2kgcVEschpjPfSTqeJ95dsM2HQqRovpEBRZAXIJkW23agk6lZhNRUgwrv+EWOUL7 PUkL0ZhjZjN7RKPS51O6SKrnxbtfHdUCwAYt29X/WZxEUrcLpDoK2F0UknY6tNVfZG 95PtDio/5SShQ== Cc: "" Subject: Re: [MMUSIC] Issue tracker for 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 22:28:36 -0000 Ali, I'll be interested to see the set of issues you post initially. I've raised things from time to time in the past, and you may already have them on your private list. Thanks, Paul On 1/16/14 12:37 PM, Ali C. Begen (abegen) wrote: > > On Jan 15, 2014, at 10:24 AM, Paul Kyzivat wrote: > >> On 1/14/14 2:49 PM, Ali C. Begen (abegen) wrote: >>> Hi everyone >>> >>> Revising 4566 is underway as you know and there have been some issues with 4566 and some folks want them to be fixed in 4566bis. However, due to convoluted discussions, some of these issues go unfixed. To make the process easier, it was suggested to establish an issue tracker. >>> >>> I have not done this before, but found the link below: >>> http://tools.ietf.org/wg/mmusic/trac/report/1 >>> >>> Is this a good idea to use this or do you have better suggestions? >> >> This is just a link to a report of active tickets. >> Are you just asking if doing something analogous for 4566bis would be a good thing? >> >> I think the issue tracker is fine if you, as editor, use it to track the issues with your document. >> >> But I strongly suggest that you be the only one to open, update, and close tickets for 4566bis. Don't leave it for anybody who thinks they have an issue to open their own ticket, and don't use updates to the tickets as a way to debate an issue. I saw that done once or twice and it created a mess - confusing established mechanisms for discussing issues via email. >> >> So IMO we should continue to *discuss* proposed changes on the mmusic list. Based on those discussions you can make tickets as you see fit to track the status of identified issues and their incorporation into the draft. > > Fine with me. I will try to create and track the issues in that list (so everybody can know where we are) and people should post their comments about the 4566bis in the list. But, please be clear on what the problem is and provide a solution if you can so that we can move faster. > > thanks. > -acbegen > > > >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > From internet-drafts@ietf.org Fri Jan 17 02:29:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF7A1ADFD6; Fri, 17 Jan 2014 02:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw0u1SlHi9Fa; Fri, 17 Jan 2014 02:29:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F211ADFC6; Fri, 17 Jan 2014 02:29:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140117102919.14246.79224.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2014 02:29:19 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 10:29:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : UDP Transport Layer (UDPTL) over Datagram Transpo= rt Layer Security (DTLS) Authors : Christer Holmberg Ivo Sedlacek Gonzalo Salgueiro Filename : draft-ietf-mmusic-udptl-dtls-03.txt Pages : 21 Date : 2014-01-17 Abstract: This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-udptl-dtls-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Fri Jan 17 02:33:48 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954D81ADFC6 for ; Fri, 17 Jan 2014 02:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3WhAH87vaZD for ; Fri, 17 Jan 2014 02:33:46 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6651C1ADFCD for ; Fri, 17 Jan 2014 02:33:46 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-86-52d906fc78f3 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5F.37.23787.CF609D25; Fri, 17 Jan 2014 11:33:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0347.000; Fri, 17 Jan 2014 11:33:33 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-udptl-dtls-03 Thread-Index: Ac8Tbzja38Qsi/SIQI+/J2WL605y8A== Date: Fri, 17 Jan 2014 10:33:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D0FDD10@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D0FDD10ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje4ftptBBi3bzC3+7U2ymLr8MYsD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlbHpZy9jwXXRit/fe5gaGBcJdzFyckgImEis 27aWBcIWk7hwbz1bFyMXh5DAIUaJuc8XMEM4Sxglzt3dwdTFyMHBJmAh0f1PG6RBREBd4uve HmYQm1nAUeLsre1MILawgI3E920LGCFqgOLtc5ggbD2JC++PgdWzCKhKHOk8zQZi8wr4Six5 vB8szgh0xPdTa5ggZopL3HoynwniOAGJJXvOM0PYohIvH/9jBTlHQkBRYnm/HER5vsS312eh RgpKnJz5hGUCo/AsJJNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2Jkz03M zEkvN9zECIyPg1t+6+5gPHVO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4 pRoYy4KTtLxyj4Rs9ttxOrJ9YbnGp9Obpqq9ftP6ZMOS7MqeY7pu02+LJyW5K3zIccpTvSXD fM7MdMvSXQUl8rO+czx00Pb9dGPnb88rfkvV5i/zLHp12zhWnGl35js1mQvp5ayntL4Jlh7e zbShaFvxpqOHNbOnTzww56Zeo6q5huHDDZ+4WYOklViKMxINtZiLihMBoPX2J10CAAA= Cc: "mmusic-chairs@tools.ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 10:33:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D0FDD10ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi fax lovers, Based on the excellent and detailed document reviews performed by James R, = David H, Albrecht S and Oscar O, we've submitted a new version (-03) of dra= ft-ietf-mmusic-udptl-dtls. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D0FDD10ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi fax lovers,

 

Based on the excellent and detailed document reviews= performed by James R, David H, Albrecht S and Oscar O, we’ve submitt= ed a new version (-03) of draft-ietf-mmusic-udptl-dtls.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D0FDD10ESESSMB209erics_-- From internet-drafts@ietf.org Fri Jan 17 02:58:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260881ADFCD; Fri, 17 Jan 2014 02:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbPo7up1MEO0; Fri, 17 Jan 2014 02:58:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 931041ADFEF; Fri, 17 Jan 2014 02:58:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140117105827.23104.91681.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2014 02:58:27 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-39.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 10:58:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Real Time Streaming Protocol 2.0 (RTSP) Authors : Henning Schulzrinne Anup Rao Rob Lanphier Magnus Westerlund Martin Stiemerling Filename : draft-ietf-mmusic-rfc2326bis-39.txt Pages : 309 Date : 2014-01-17 Abstract: This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-layer protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-39 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc2326bis-39 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Fri Jan 17 03:04:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F611ADFE2 for ; Fri, 17 Jan 2014 03:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wabC-t0Mz5ur for ; Fri, 17 Jan 2014 03:04:20 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1651ADFC6 for ; Fri, 17 Jan 2014 03:04:20 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-5e-52d90e140518 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AA.BC.15980.31E09D25; Fri, 17 Jan 2014 12:03:48 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.347.0; Fri, 17 Jan 2014 12:03:42 +0100 Message-ID: <52D90DFC.3000102@ericsson.com> Date: Fri, 17 Jan 2014 12:03:24 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: References: <20140117105827.23104.91681.idtracker@ietfa.amsl.com> In-Reply-To: <20140117105827.23104.91681.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RleE72aQwblHJhaTnk5jspi6/DGL A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJUx8+xVtoLnkhUtDf/YGxjvCHcxcnJICJhI dL44wwJhi0lcuLeerYuRi0NI4BCjxOauxVDOckaJN++PM4NU8QpoS8y6tpGpi5GDg0VAVeLO o0CQMJuAhcTNH41sILaoQLDErWkP2CHKBSVOznwCtkBEQFTi0cVFrCA2M9CYV7evgo0UFnCV +Hb2PiOILSTgKHHrzg6wek4BJ4m/z6exgqySEBCX6GkMgmjVk5hytYURwpaXaN46mxmiVVui oamDdQKj0Cwkm2chaZmFpGUBI/MqRvbcxMyc9HLzTYzAQD245bfBDsZN98UOMUpzsCiJ8354 6xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHLVNcm8TbFk4ph0bZNy5bvOcc98a3/4288 12QEBONuz3l8zOJpA4uMSeo01blKh0pedTNqFj+aoRwoln/jZGf+FrumYvbrH2u2yky31Qg8 xxbs0/RjyemF/bwJb4rcN6V/kWA8btvPppi9yGmz8f65TsZmbzLWXdx0Jc8ht6nhg1nDgdvl m5RYijMSDbWYi4oTAWFgLHYiAgAA Cc: Martin Stiemerling Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-39.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 11:04:23 -0000 WG, Martin and I have now worked through the discusses and comments received in IESG review. Thus this is our suggestion on how to resolve them. I encourage you to review the changes while the ADs reviews the discuss positions. If you find issues we need to hear comments ASAP. The main changes are: - rewritten structure for a large number of IANA entries - Additional text regarding security and sensitivity of control vs media. - ABNF chagnes regarding UTF-8 - Rewritten NPT text and ABNF. - Updated examples for Date to follow the time format actually specified. Cheers Magnus On 2014-01-17 11:58, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Real Time Streaming Protocol 2.0 (RTSP) > Authors : Henning Schulzrinne > Anup Rao > Rob Lanphier > Magnus Westerlund > Martin Stiemerling > Filename : draft-ietf-mmusic-rfc2326bis-39.txt > Pages : 309 > Date : 2014-01-17 > > Abstract: > This memorandum defines RTSP version 2.0 which obsoletes RTSP version > 1.0 defined in RFC 2326. > > The Real Time Streaming Protocol, or RTSP, is an application-layer > protocol for setup and control of the delivery of data with real-time > properties. RTSP provides an extensible framework to enable > controlled, on-demand delivery of real-time data, such as audio and > video. Sources of data can include both live data feeds and stored > clips. This protocol is intended to control multiple data delivery > sessions, provide a means for choosing delivery channels such as UDP, > multicast UDP and TCP, and provide a means for choosing delivery > mechanisms based upon RTP (RFC 3550). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-39 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc2326bis-39 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 dhanes@cisco.com Fri Jan 17 06:33:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F711AE0FB for ; Fri, 17 Jan 2014 06:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8_F_XKEJ0vp for ; Fri, 17 Jan 2014 06:33:00 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 94D441AE0F3 for ; Fri, 17 Jan 2014 06:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4923; q=dns/txt; s=iport; t=1389969168; x=1391178768; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=FtV+Q6nOqqexbsIGk1e+KJyWD1HoGcyvWi+z2+ytkCs=; b=i1ou6bY8tU2/XqwhMU9SqOY0YXeASmYe9omjZAvVI4LXe63mqtYqI8P8 yWJhrzJFGy/LtSBw7W1H8kSn5KYyQulJXO+Ctpil/RO4flKcAu+dtLzTU ZdYmHEGOnbBIeILAHXFv603bqUtaSYvmJ1FxLQq8Y6LGFtYSAetxHhLWS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAJFf2FKtJV2d/2dsb2JhbABZgkdEOFa7EYEPFnSCJQECBC1MEgEIEQMBAig5FAkIAQEEAQ0FiATFQReObhEHhDgBA5ghkheDLYIq X-IronPort-AV: E=Sophos;i="4.95,670,1384300800"; d="scan'208,217";a="13622102" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 17 Jan 2014 14:32:48 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0HEWmPI004493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jan 2014 14:32:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.144]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 17 Jan 2014 08:32:47 -0600 From: "David Hanes (dhanes)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 Thread-Index: Ac8Tbzja38Qsi/SIQI+/J2WL605y8AAKikGA Date: Fri, 17 Jan 2014 14:32:47 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D0FDD10@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.39.199] Content-Type: multipart/alternative; boundary="_000_CEFEA89ED391dhanesciscocom_" MIME-Version: 1.0 Cc: "mmusic-chairs@tools.ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 14:33:02 -0000 --_000_CEFEA89ED391dhanesciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Christer, This new draft looks good and addresses the concerns that I raised. Thanks, David From: Christer Holmberg > Date: Friday, January 17, 2014 5:33 AM To: "mmusic@ietf.org" > Cc: "mmusic-chairs@tools.ietf.org" > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 Hi fax lovers, Based on the excellent and detailed document reviews performed by James R, = David H, Albrecht S and Oscar O, we=92ve submitted a new version (-03) of d= raft-ietf-mmusic-udptl-dtls. Regards, Christer --_000_CEFEA89ED391dhanesciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Christer,

This new draft looks good and addresses the concerns that I raised.&nb= sp;

Thanks,
David



From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, January 17, 2014 5:33= AM
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org&g= t;
Subject: [MMUSIC] Draft new version= : draft-ietf-mmusic-udptl-dtls-03

Hi fax lovers,

 

Based on the excellent and detailed document reviews= performed by James R, David H, Albrecht S and Oscar O, we=92ve submitted a= new version (-03) of draft-ietf-mmusic-udptl-dtls.

 

Regards,

 

Christer

--_000_CEFEA89ED391dhanesciscocom_-- From gsalguei@cisco.com Fri Jan 17 11:43:32 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87B11AE101 for ; Fri, 17 Jan 2014 11:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9K-qQ7qAdzl for ; Fri, 17 Jan 2014 11:43:31 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 14B011AE0F3 for ; Fri, 17 Jan 2014 11:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2192; q=dns/txt; s=iport; t=1389987798; x=1391197398; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ON50zMN2dHiIlUmcBQVhWOyxhwYo4+bL7QbDaOLNtiI=; b=UBBffhXT9jBdi4+8cMxJ3BQw4ZZ/P2Ww6dRTV41kN1dKg9exvDkw6nTC eLkMCEA9ac9dvvwoBMG0tBRg+XVjLOwX7qaZX//297ncqekzWSdWPAx5f hS5a0ICRtxABbk8oeREoSG0YneOqgj5yxhEQvSEISTIFjjlXEVS+FzVil Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAB+H2VKtJXHB/2dsb2JhbABWA4MLOFa7JYEOFnSCJQEBAQMBKRE/BQsCAQIGEQQBAR8JBzIUCQgCBA4Fh30IDcQAF44dEQEdIxAHAg+DE4EUBJghgTGQZoMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,675,1384300800"; d="scan'208";a="13697235" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 17 Jan 2014 19:43:18 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0HJhIiB028837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jan 2014 19:43:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 17 Jan 2014 13:43:18 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: John Shaheen Thread-Topic: Working Group Last Call Review of UDPTL over DTLS Draft Thread-Index: AQHO9dFKgmgY0F59g0eZLx0nEmOneZqJifLggABnuwA= Importance: high X-Priority: 1 Date: Fri, 17 Jan 2014 19:43:17 +0000 Message-ID: References: <54633A5E61DC84429CB9FE3D9143C7210121344FFC@MBX.dialogic.com> In-Reply-To: <54633A5E61DC84429CB9FE3D9143C7210121344FFC@MBX.dialogic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.154.240] Content-Type: text/plain; charset="us-ascii" Content-ID: <1979D0A9E3D5894CB4CD0B7504367D28@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "foip@sipforum.org" , mmusic , Sebastien BOIRE-LAVIGNE , Christer Holmberg Subject: Re: [MMUSIC] Working Group Last Call Review of UDPTL over DTLS Draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 19:43:33 -0000 [Copying the MMUSIC list for awareness...] John -=20 I appreciate you taking the time to review the draft. Cheers, Gonzalo On Jan 17, 2014, at 2:39 PM, John Shaheen wrote= : > Hi Gonzalo, > I have reviewed the UDPTL over DTLS draft with my team and we do not see = any issues.=20 > =20 > Regards, > John Shaheen > =20 > John G. Shaheen III > Engineering Manager, Brooktrout > Dialogic, Inc. >=20 > Tel: 781.433.9514 > Fax: 781.433.9255 > Email: john.shaheen@dialogic.com > =20 > > =20 > =20 > =20 > This e-mail is intended only for the named recipient(s) and may contain i= nformation that is privileged, confidential and/or exempt from disclosure u= nder applicable law. No waiver of privilege, confidence or otherwise is int= ended by virtue of communication via the internet. Any unauthorized use,dis= semination or copying is strictly prohibited. If you have received this e-m= ail in error, or are not named as a recipient, please immediately notify th= e sender and destroy all copies of this e-mail. > =20 > From: foip-bounces@sipforum.org [mailto:foip-bounces@sipforum.org] On Beh= alf Of Gonzalo Salgueiro (gsalguei) > Sent: Tuesday, December 10, 2013 12:57 PM > To: foip@sipforum.org; Sebastien BOIRE-LAVIGNE > Cc: Ivo Sedlacek; Christer Holmberg > Subject: [Foip] Working Group Last Call Review of UDPTL over DTLS Draft > =20 > FoIP TG -=20 > =20 > The authors believe that the UDPTL over DTLS draft is ready to be moved f= orward toward publication. For that to happen, we would need folks to perfo= rm a detailed review of the draft, and indicate on the list (mmusic@ietf.or= g) about any possible issues. Feedback indicating that you have read the d= raft and that everything looks good is even helpful. The draft can be foun= d here: > =20 > http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls >=20 > The authors would appreciate it if folks from this group would be willing= to perform such a review. >=20 > Thanks! >=20 > Gonzalo From christer.holmberg@ericsson.com Fri Jan 17 21:35:01 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1251ADBF7 for ; Fri, 17 Jan 2014 21:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-Iv9I7tlADQ for ; Fri, 17 Jan 2014 21:34:59 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C32DA1ADD02 for ; Fri, 17 Jan 2014 21:34:57 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-52-52da1274314e Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 59.71.15980.4721AD25; Sat, 18 Jan 2014 06:34:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Sat, 18 Jan 2014 06:34:43 +0100 From: Christer Holmberg To: "Gonzalo Salgueiro (gsalguei)" , John Shaheen Thread-Topic: Working Group Last Call Review of UDPTL over DTLS Draft Thread-Index: AQHO9dFKgmgY0F59g0eZLx0nEmOneZqJifLggABnuwCAAECrDg== Date: Sat, 18 Jan 2014 05:34:43 +0000 Message-ID: References: <54633A5E61DC84429CB9FE3D9143C7210121344FFC@MBX.dialogic.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvjW6J0K0gg7/zhS0ePZvPbjF3ip/F /p8vmS2mLn/MYjFz7xsmB1aPKb83snoc2drB5LFkyU8mj10zTzN5dLb2sQSwRnHZpKTmZJal FunbJXBl3H23hK3grWDF298/2BsYF/F1MXJwSAiYSEx+ot/FyAlkiklcuLeerYuRi0NI4BCj RHv3fEYIZwmjxJuz21hAGtgELCS6/2mDNIgIJEtcuPCYFaSGWWAzo8SJS29YQWqEBVwkZt8V BDFFBFwl+roEIcqdJC4eP8ICYrMIqEocWzCHEcTmFXCT+PN/ISvEqrWMEk923mIDSXAK2Erc +zyPFcRmBDru+6k1TCA2s4C4xK0n85kgjhaQWLLnPDOELSrx8vE/VogaHYkFuz+xQdjaEssW vmaGWCYocXLmE5YJjKKzkIyahaRlFpKWWUhaFjCyrGJkz03MzEkvN9/ECIyhg1t+G+xg3HRf 7BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY0+9tPqTZ89Hi8pTdsfem lEZ+Sp1+jPdU/eMX0gXJ+XJPXjtbrT6RdjrnxsSXiwWl9pWu1FSOd/Dq3jmbpWOBvVLeX9Et vpNE+F4fSChYFpfy9MIGjdZ3HA/b7jeGVxw8Ijnn8oeUNu5HlxW87STVOZd2T8t3ev7hTfN9 3W7Lx4VcN+7/2rR/lRJLcUaioRZzUXEiAADi7e5vAgAA Cc: "foip@sipforum.org" , Sebastien BOIRE-LAVIGNE , mmusic Subject: Re: [MMUSIC] Working Group Last Call Review of UDPTL over DTLS Draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jan 2014 05:35:02 -0000 Thanks, John! :) Regards, Christer Sent from my Sony Ericsson Xperia arc S "Gonzalo Salgueiro (gsalguei)" wrote: [Copying the MMUSIC list for awareness...] John - I appreciate you taking the time to review the draft. Cheers, Gonzalo On Jan 17, 2014, at 2:39 PM, John Shaheen wrote= : > Hi Gonzalo, > I have reviewed the UDPTL over DTLS draft with my team and we do not see = any issues. > > Regards, > John Shaheen > > John G. Shaheen III > Engineering Manager, Brooktrout > Dialogic, Inc. > > Tel: 781.433.9514 > Fax: 781.433.9255 > Email: john.shaheen@dialogic.com > > > > > > This e-mail is intended only for the named recipient(s) and may contain i= nformation that is privileged, confidential and/or exempt from disclosure u= nder applicable law. No waiver of privilege, confidence or otherwise is int= ended by virtue of communication via the internet. Any unauthorized use,dis= semination or copying is strictly prohibited. If you have received this e-m= ail in error, or are not named as a recipient, please immediately notify th= e sender and destroy all copies of this e-mail. > > From: foip-bounces@sipforum.org [mailto:foip-bounces@sipforum.org] On Beh= alf Of Gonzalo Salgueiro (gsalguei) > Sent: Tuesday, December 10, 2013 12:57 PM > To: foip@sipforum.org; Sebastien BOIRE-LAVIGNE > Cc: Ivo Sedlacek; Christer Holmberg > Subject: [Foip] Working Group Last Call Review of UDPTL over DTLS Draft > > FoIP TG - > > The authors believe that the UDPTL over DTLS draft is ready to be moved f= orward toward publication. For that to happen, we would need folks to perfo= rm a detailed review of the draft, and indicate on the list (mmusic@ietf.or= g) about any possible issues. Feedback indicating that you have read the d= raft and that everything looks good is even helpful. The draft can be foun= d here: > > http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls > > The authors would appreciate it if folks from this group would be willing= to perform such a review. > > Thanks! > > Gonzalo From christer.holmberg@ericsson.com Sun Jan 19 23:05:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37A61A005D for ; Sun, 19 Jan 2014 23:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpxrzgCJXGAo for ; Sun, 19 Jan 2014 23:05:15 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BCB191A005B for ; Sun, 19 Jan 2014 23:05:14 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-6a-52dccaaabfef Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 42.23.23787.AAACCD25; Mon, 20 Jan 2014 08:05:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Mon, 20 Jan 2014 08:05:13 +0100 From: Christer Holmberg To: Shida Schubert , "David Hanes (dhanes)" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 Thread-Index: Ac8Tbzja38Qsi/SIQI+/J2WL605y8AAKikGAAILRUQAAAlCoIA== Date: Mon, 20 Jan 2014 07:05:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D108D8E@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D108D8EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje6qU3eCDDb8lrW4tOITi8W/vUkW U5c/ZrFouX+UzYHF49i/g8weU35vZPVYsuQnk8eXy5/ZAliiuGxSUnMyy1KL9O0SuDKeb7Ar uBBb8fd5P1MD44uQLkZODgkBE4mFF/4yQ9hiEhfurWfrYuTiEBI4xCjxaMoZKGcJo8Sr2S9Y uxg5ONgELCS6/2mDNIgIBEkcfjGRHcRmFsiQuPf2CzNIibCAp8SSj4kQJV4Sx4+/ZoWwnSQe tmwAs1kEVCWO95wBa+UV8JW4smg3I4gtJJAg0XpyNVgNp4CdRPvGI0wgNiPQbd9PrWGCWCUu 8eHgdaibBSSW7DkPZYtKvHz8jxXCVpJYsf0SI0R9vsStnn1sELsEJU7OfMIygVF0FpJRs5CU zUJSBhHXk7gxdQobhK0tsWzha6h6XYkZ/w6xIIsvYGRfxciem5iZk15uuIkRGHUHt/zW3cF4 6pzIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCad1kdPbFGcJqNpfC5 rxv/fZ/Ky3z50fyqhFWdK/UaSrqq4xvnR/32ePAu/sQr18K1FxYeMLuz61PM50s+Uls00pil LRNjGSK29xyewLJkQ5hGjGdYB6/pok8bGS00ZJnUeX+q3U31mjtFReZla3kFu6rv+u9Nbcue rpXxfXBbWd2ztej4Mk0lluKMREMt5qLiRAD+nLq8iAIAAA== Cc: "mmusic-chairs@tools.ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2014 07:05:18 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D108D8EESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Shida! :) Regards, Christer L=E4hett=E4j=E4: Shida Schubert [mailto:shida@agnada.com] L=E4hetetty: 20. tammikuuta 2014 8:59 Vastaanottaja: David Hanes (dhanes) Kopio: Christer Holmberg; mmusic@ietf.org; mmusic-chairs@tools.ietf.org Aihe: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 I read the previous draft and didn't see any issues beside raised by others. I glanced over the new draft and the changes look good. Regards Shida On Jan 17, 2014, at 6:32 AM, David Hanes (dhanes) > wrote: Hi Christer, This new draft looks good and addresses the concerns that I raised. Thanks, David From: Christer Holmberg > Date: Friday, January 17, 2014 5:33 AM To: "mmusic@ietf.org" > Cc: "mmusic-chairs@tools.ietf.org" > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 Hi fax lovers, Based on the excellent and detailed document reviews performed by James R, = David H, Albrecht S and Oscar O, we've submitted a new version (-03) of dra= ft-ietf-mmusic-udptl-dtls. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1D108D8EESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Shida! J

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

L=E4hett=E4j=E4: Shida Schubert [mailto:shida@agnada.com]
L=E4hetetty: 20. tammikuuta 2014 8:59
Vastaanottaja: David Hanes (dhanes)
Kopio: Christer Holmberg; mmusic@ietf.org; mmusic-chairs@tools.ietf.= org
Aihe: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-0= 3

 

 

 I read the previous draft and didn't see any i= ssues beside 

raised by others. 

 

 I glanced over the new draft and the changes l= ook good. 

 

 Regards

  Shida

 

On Jan 17, 2014, at 6:32 AM, David Hanes (dhanes) &l= t;dhanes@cisco.com> wrote:<= /o:p>



Hi Christer,

 

This new draft looks good and addresses= the concerns that I raised. 

 

Thanks,

David

 

 

 

From: Christer Holmberg <chr= ister.holmberg@ericsson.com>
Date: Friday, Janu= ary 17, 2014 5:33 AM
To: "mmusic@ietf.org" <mmusic@ietf.org>
Cc: "mmusi= c-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org= >
Subject: [MMUSIC] = Draft new version: draft-ietf-mmusic-udptl-dtls-03

 

Hi fax lovers,

 

Based on the excellent a= nd detailed document reviews performed by James R, David H, Albrecht S and = Oscar O, we’ve submitted a new version (-03) of draft-ietf-mmusic-udp= tl-dtls.

 =

Regards,

 =

Christer

_______________________________________= ________
mmusic mailing list
mmusic@ietf= .org
https://www.ietf.org/mailman/listinfo/mmusic

 

--_000_7594FB04B1934943A5C02806D1A2204B1D108D8EESESSMB209erics_-- From shida@ntt-at.com Sun Jan 19 23:16:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB751A005B for ; Sun, 19 Jan 2014 23:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHyoUt-6Ja1R for ; Sun, 19 Jan 2014 23:16:08 -0800 (PST) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by ietfa.amsl.com (Postfix) with ESMTP id 664AC1A0058 for ; Sun, 19 Jan 2014 23:16:08 -0800 (PST) Received: from [50.184.77.69] (port=63994 helo=[192.168.1.23]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1W595c-00030T-F4 for mmusic@ietf.org; Mon, 20 Jan 2014 01:16:08 -0600 From: Shida Schubert Content-Type: multipart/alternative; boundary="Apple-Mail=_830E5732-9BF4-4A72-957F-DC8862A385CD" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Sun, 19 Jan 2014 23:16:05 -0800 References: To: "mmusic@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1827) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 50.184.77.69 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.23]) [50.184.77.69]:63994 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2014 07:16:11 -0000 --Apple-Mail=_830E5732-9BF4-4A72-957F-DC8862A385CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I read the previous draft and didn't see any issues beside=20 raised by others.=20 I glanced over the new draft and the changes look good.=20 Regards Shida On Jan 17, 2014, at 6:32 AM, David Hanes (dhanes) = wrote: > Hi Christer, >=20 > This new draft looks good and addresses the concerns that I raised.=20 >=20 > Thanks, > David >=20 >=20 >=20 > From: Christer Holmberg > Date: Friday, January 17, 2014 5:33 AM > To: "mmusic@ietf.org" > Cc: "mmusic-chairs@tools.ietf.org" > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 >=20 > Hi fax lovers, > =20 > Based on the excellent and detailed document reviews performed by = James R, David H, Albrecht S and Oscar O, we=92ve submitted a new = version (-03) of draft-ietf-mmusic-udptl-dtls. > =20 > Regards, > =20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_830E5732-9BF4-4A72-957F-DC8862A385CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

 I read the previous draft = and didn't see any issues beside 
raised by = others. 

 I glanced over the new = draft and the changes look = good. 

 Regards
  = Shida

On Jan 17, 2014, at 6:32 AM, David = Hanes (dhanes) <dhanes@cisco.com> = wrote:

Hi = Christer,

This new draft looks good and = addresses the concerns that I = raised. 

Thanks,
David
<= br>


From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Friday, January 17, = 2014 5:33 AM
To: "mmusic@ietf.org" <mmusic@ietf.org>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>
Subject: [MMUSIC] Draft new = version: draft-ietf-mmusic-udptl-dtls-03

Hi fax = lovers,
 
Based on = the excellent and detailed document reviews performed by James R, David = H, Albrecht S and Oscar O, we=92ve submitted a new version (-03) of = draft-ietf-mmusic-udptl-dtls.
 
Regards,
 
Christer
___________= ____________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

= --Apple-Mail=_830E5732-9BF4-4A72-957F-DC8862A385CD-- From shida@agnada.com Sun Jan 19 22:58:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01681A005B for ; Sun, 19 Jan 2014 22:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSamAP0ZCkwP for ; Sun, 19 Jan 2014 22:58:37 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.15.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3881A0058 for ; Sun, 19 Jan 2014 22:58:37 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 5EB5554009216; Mon, 20 Jan 2014 00:58:37 -0600 (CST) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 4BEFC540091D7 for ; Mon, 20 Jan 2014 00:58:37 -0600 (CST) Received: from [50.184.77.69] (port=63303 helo=[192.168.1.23]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1W58oe-00087M-QL; Mon, 20 Jan 2014 00:58:36 -0600 Content-Type: multipart/alternative; boundary="Apple-Mail=_7F3CEC14-3F29-4A69-A6BD-E8BEB58BB4B2" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shida Schubert In-Reply-To: Date: Sun, 19 Jan 2014 22:58:34 -0800 Message-Id: References: To: "David Hanes (dhanes)" X-Mailer: Apple Mail (2.1827) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - agnada.com X-BWhitelist: no X-Source-IP: 50.184.77.69 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.23]) [50.184.77.69]:63303 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== X-Mailman-Approved-At: Mon, 20 Jan 2014 00:45:26 -0800 Cc: "mmusic-chairs@tools.ietf.org" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2014 06:58:38 -0000 --Apple-Mail=_7F3CEC14-3F29-4A69-A6BD-E8BEB58BB4B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I read the previous draft and didn't see any issues beside=20 raised by others.=20 I glanced over the new draft and the changes look good.=20 Regards Shida On Jan 17, 2014, at 6:32 AM, David Hanes (dhanes) = wrote: > Hi Christer, >=20 > This new draft looks good and addresses the concerns that I raised.=20 >=20 > Thanks, > David >=20 >=20 >=20 > From: Christer Holmberg > Date: Friday, January 17, 2014 5:33 AM > To: "mmusic@ietf.org" > Cc: "mmusic-chairs@tools.ietf.org" > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-03 >=20 > Hi fax lovers, > =20 > Based on the excellent and detailed document reviews performed by = James R, David H, Albrecht S and Oscar O, we=92ve submitted a new = version (-03) of draft-ietf-mmusic-udptl-dtls. > =20 > Regards, > =20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_7F3CEC14-3F29-4A69-A6BD-E8BEB58BB4B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

 I read the previous draft = and didn't see any issues beside 
raised by = others. 

 I glanced over the new = draft and the changes look = good. 

 Regards
  = Shida

On Jan 17, 2014, at 6:32 AM, David Hanes = (dhanes) <dhanes@cisco.com> = wrote:

Hi = Christer,

This new draft looks good and = addresses the concerns that I = raised. 

Thanks,
David
<= br>


From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Friday, January 17, = 2014 5:33 AM
To: "mmusic@ietf.org" <mmusic@ietf.org>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>
Subject: [MMUSIC] Draft new = version: draft-ietf-mmusic-udptl-dtls-03

Hi fax = lovers,
 
Based on = the excellent and detailed document reviews performed by James R, David = H, Albrecht S and Oscar O, we=92ve submitted a new version (-03) of = draft-ietf-mmusic-udptl-dtls.
 
Regards,
 
Christer
___________= ____________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

= --Apple-Mail=_7F3CEC14-3F29-4A69-A6BD-E8BEB58BB4B2-- From wwwrun@rfc-editor.org Tue Jan 21 22:06:01 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A9F1A0270; Tue, 21 Jan 2014 22:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWaLqjzDSfnD; Tue, 21 Jan 2014 22:05:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id D1FEF1A02BB; Tue, 21 Jan 2014 22:05:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6BDB37FC2C7; Tue, 21 Jan 2014 22:05:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140122060558.6BDB37FC2C7@rfc-editor.org> Date: Tue, 21 Jan 2014 22:05:58 -0800 (PST) Cc: drafts-update-ref@iana.org, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 7104 on Duplication Grouping Semantics in the Session Description Protocol X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jan 2014 06:06:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7104 Title: Duplication Grouping Semantics in the Session Description Protocol Author: A. Begen, Y. Cai, H. Ou Status: Standards Track Stream: IETF Date: January 2014 Mailbox: abegen@cisco.com, yiqunc@microsoft.com, hou@cisco.com Pages: 10 Characters: 17719 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-duplication-grouping-04.txt URL: http://www.rfc-editor.org/rfc/rfc7104.txt Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From magnus.westerlund@ericsson.com Wed Jan 22 01:36:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C861A03FA for ; Wed, 22 Jan 2014 01:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1O1ywQ3tNFo for ; Wed, 22 Jan 2014 01:36:16 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 98A711A0416 for ; Wed, 22 Jan 2014 01:36:15 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-01-52df91075b9c Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 64.22.23809.7019FD25; Wed, 22 Jan 2014 10:36:07 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.347.0; Wed, 22 Jan 2014 10:36:07 +0100 Message-ID: <52DF90E9.2070902@ericsson.com> Date: Wed, 22 Jan 2014 10:35:37 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mmusic (E-mail)" , Marc Petit-Huguenin , =?ISO-8859-1?Q?Ari_Ker=E4nen?= X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+JvjS7fxPtBBgtOy1pMXf6YxeLCmrtM Dkwel694eyxZ8pMpgCmKyyYlNSezLLVI3y6BK2PnnCVsBQ+FK9Yd2MzcwNjC28XIySEhYCLx /Ws7K4QtJnHh3nq2LkYuDiGBQ4wSN07sZIdwljNKfNiwEKyKV0Bb4n73ZEYQm0VAVeLTj89M IDabgIXEzR+NbCC2qECwxK1pD9gh6gUlTs58wgIySESgh1FiwfV7YAlhATeJ38+nMHcxcgCt FpfoaQwCCTML6ElMudrCCGHLSzRvnc0MYgsB7W1o6mCdwMg/C8nYWUhaZiFpWcDIvIqRPTcx Mye93GgTIzDEDm75rbqD8c45kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLg lGpgLFOW1t77aLvu7klSX4Qmqnq9kPI29v6Zv2R3RsWO20Fh/lNE1f+2b1JVXa907s//FSlb rfhlbJ/+s70/K3G1iJmZCpeaRVopt9a9A4usVK2rfmyc+HPy8sn8Ad3xnhdmnJTMnJy4ai3j sZjFdbO3bPv4cIvBqu6lhlczzxesfFiaNcE3d+1nLyWW4oxEQy3mouJEABBWzxH/AQAA Subject: [MMUSIC] Comments on ABNF in draft-petithuguenin-mmusic-ice-sip-sdp-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jan 2014 09:36:17 -0000 Hi, As part of the RTSP for NAT work I actually noticed an issue with the ABNF that is defined for ICE in SDP. >From Section 8.1: candidate-attribute = "candidate" ":" foundation SP component-id SP transport SP priority SP connection-address SP ;from RFC 4566 port ;port from RFC 4566 SP cand-type [SP rel-addr] [SP rel-port] *(SP extension-att-name SP extension-att-value) foundation = 1*32ice-char component-id = 1*5DIGIT transport = "UDP" / transport-extension transport-extension = token ; from RFC 3261 priority = 1*10DIGIT cand-type = "typ" SP candidate-types Petit-Huguenin & KeranenExpires August 29, 2013 [Page 9] Internet-Draft ICE SIP/SDP Usage February 2013 candidate-types = "host" / "srflx" / "prflx" / "relay" / token rel-addr = "raddr" SP connection-address rel-port = "rport" SP port extension-att-name = byte-string ;from RFC 4566 extension-att-value = byte-string ice-char = ALPHA / DIGIT / "+" / "/" The issue is what is allowed in extension-att-name and extension-att-value. They are listed here as byte-string. That is an extremely wide allowance in what values to be included. First of all it includes SP the character used for delimiting the -att-name against the -att-value and the next set of name and value. I can't see that one can allow that, and if one have values that includes space, then they must be escaped. Further I wonder if it wise to include the non-visible values from the below 128 range of the byte. It might be okay, but some thought needs to be put into this. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 iesg-secretary@ietf.org Wed Jan 22 04:25:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA04B1A00C2; Wed, 22 Jan 2014 04:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1wJDkMWCfXu; Wed, 22 Jan 2014 04:25:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8071A03F2; Wed, 22 Jan 2014 04:25:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140122122509.9594.4765.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 04:25:09 -0800 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'Delayed Duplication Attribute in the Session Description Protocol' to Proposed Standard (draft-ietf-mmusic-delayed-duplication-03.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 12:25:19 -0000 The IESG has approved the following document: - 'Delayed Duplication Attribute in the Session Description Protocol' (draft-ietf-mmusic-delayed-duplication-03.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ Technical Summary A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to simply duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as Time-shifted Redundancy, Temporal Redundancy or simply Delayed Duplication. This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. Working Group Summary There is WG consensus behind this draft. All issues raised during and before WGLC have been addressed. Document Quality The document has received reviews from working group participants both at MMUSIC and AVTEXT and the document shepherd. There is currently at least one vendor implementing this mechanism and various other vendors have expressed interest for this technique. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Ari Keranen is the Document Shepherd, and the Responsible Area Director is Gonzalo Camarillo. RFC Editor's Note Please add the following site as a reference to Lucky 13 mentioned in Section 5. http://www.isg.rhul.ac.uk/tls/Lucky13.html From magnus.westerlund@ericsson.com Wed Jan 22 06:01:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C011A03F7 for ; Wed, 22 Jan 2014 06:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTFK1tMKeHIZ for ; Wed, 22 Jan 2014 06:01:30 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0581A03ED for ; Wed, 22 Jan 2014 06:01:29 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-0f-52dfcf38a82f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 6B.68.04853.83FCFD25; Wed, 22 Jan 2014 15:01:28 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.347.0; Wed, 22 Jan 2014 15:01:27 +0100 Message-ID: <52DFCF18.8080104@ericsson.com> Date: Wed, 22 Jan 2014 15:00:56 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mmusic (E-mail)" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3Rtfi/P0gg/Zzwhbtb44wWUxd/pjF gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MrYc+kga8FJ8YqHnXsZGxi3CnUxcnJICJhI HGqbxAJhi0lcuLeerYuRi0NI4ASjxO2TD1ggnOWMEg1HVrOBVPEKaEvcO/GUuYuRg4NFQFXi 16QAkDCbgIXEzR+NYCWiAsESt6Y9YIcoF5Q4OfMJ2AIRAXWJ1s19rCCtzAL6EtPeaYKEhQWc JA5fvccCEpYQEJfoaQwCCTML6ElMudrCCGHLSzRvnc0MYgsBHdDQ1ME6gVFgFpIFs5C0zELS soCReRWjZHFqcXFuupGBXm56bolealFmcnFxfp5eceomRmBoHtzy22gH48k99ocYpTlYlMR5 r7PWBAkJpCeWpGanphakFsUXleakFh9iZOLglGpg3LUrpvSU77tQj625xmHPbuvfWlduaBQZ /Mi04sq2Rzl6iS6P44zEvp4p3f2dd/FHbY1zN0KmM178wrOIsUT/jPV/fn6eJ6d9nJftPJRw b4HX7KSHj9e+nnnEscVGPrBL47c4x+Jzic/T7gctCFiSHr3T6uPr6vzYkr05s07eUj5omN6U fGmFlhJLcUaioRZzUXEiABQ3w/kbAgAA Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org Subject: [MMUSIC] draft-ietf-mmusic-rtsp-nat: ICE restart fails, then what? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jan 2014 14:01:31 -0000 WG, I received a comment in the doc shepherd preparation from Flemming. I need some feedback on this. This is in regards to ICE restart. One initiate an ICE restart when having an existing promoted and used candidate pair. So RFC 5245 is clear that you continue to use the candidate pair while restarting, but it is not clear that you will continue to use it if an ICE restart fails. My intuition would be to keep on using the candidate pair if it still works. But, if one looks at 8.1.2 and applies that to a restart the result is different. I mean the following text: o If the state of the check list is Failed, ICE has not been able to complete for this media stream. The correct behavior depends on the state of the check lists for other media streams: * If all check lists are Failed, ICE processing overall is considered to be in the Failed state, and the agent SHOULD consider the session a failure, SHOULD NOT restart ICE, and the controlling agent SHOULD terminate the entire session. Thus, one should terminate the session. I think there is possibility that there should be a bit more room for attempting rectifying actions. Thus my current proposal for Section 6.12 of draft-ietf-mmmusic-rtsp-nat is the following: If the RTSP session is in playing state at the time of sending the SETUP request requiring ICE restart, then the ICE connectivity checks SHALL use Regular nomination. Any ongoing media delivery continues on the previously nominated candidate pairs until the new pairs have been nominated for the individual candidate. Once the nomination of the new candidate pair has completed, all unused candidates may be released. If the ICE processing fails and no new candidate pairs are promoted for use, then one MAY continue to use the previously nominated candidate pairs while they still function. If they have appear to fail to transport media packets anymore then the client can select between two actions. First, if it has any actions available that might make ICE work, like trying another STUN/TURN server or change the transport parameters it modifies the session, and if ICE is still to be used restart ICE. If the client is unable to modify the ICE parameters, it MUST NOT restart the ICE processing, and SHOULD terminate the RTSP session. Have I missed anything about this interaction with ICE? Any issues with what I propose? Thanks Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 gsalguei@cisco.com Wed Jan 22 11:19:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B251A016E for ; Wed, 22 Jan 2014 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_zbUMkj86MX for ; Wed, 22 Jan 2014 11:19:42 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 808101A0141 for ; Wed, 22 Jan 2014 11:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3123; q=dns/txt; s=iport; t=1390418382; x=1391627982; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EyIx/ottY3QbtZfUN63ticbwrEzIPuAUgePF1e4RF8c=; b=GBr91tEqe9gW4Y3V6QJiMbnajvpD7rTv+C3OtrPCeSCumu9rkqZ8c//x NoAiYX8xwbFUqqpzoGqvWyNdO9SN9i2QcmpHJSnTFxOO2Nohc4miWbl4n ffoCL/i9Ca+dhm6VXXNed/uBLnlmBC/sli48ewrL7gruvDrabU9R79Up+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAK0Y4FKtJXHB/2dsb2JhbABbgww4Sgy7XYEXFnSCJQEBAQMBKRE/BQsCAQIGNhAyJQIEDgWHfQgNwzkXjkkzB4MkgRQElDyDZoEykGaDLYIq X-IronPort-AV: E=Sophos;i="4.95,701,1384300800"; d="scan'208";a="14755861" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-2.cisco.com with ESMTP; 22 Jan 2014 19:19:41 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0MJJfuJ004776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 19:19:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 13:19:41 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "Adam Gensler (agensler)" Thread-Topic: Review of draft-ietf-mmusic-udptl-dtls-03 Thread-Index: AQHPF6Z7X1rBlQF7JUm0AYYGqOYxvZqRgxMA Importance: high X-Priority: 1 Date: Wed, 22 Jan 2014 19:19:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic , "christer.holmberg@ericsson.com" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jan 2014 19:19:44 -0000 Thanks very much for your detailed review, Adam. I'm copying the MMUSIC@ l= ist for awareness. Cheers, Gonzalo On Jan 22, 2014, at 2:16 PM, Adam Gensler (agensler) w= rote: > Gonzalo, Christer, >=20 > After speaking with Gonzalo I've reviewed draft-ietf-mmusic-udptl-dtls-03= . > Overall this draft is excellent and appears to cover all the corner cases > I could think of. I do have a few comments, see below: >=20 > 1. In section 3.1, secure channel establishment, there is the following > text: >=20 > "If the endpoint supports, and is willing to use, a cipher suite with an > associated certificate, it MUST include an SDP fingerprint attribute > [RFC4572 ] in the SDP." >=20 > "If a cipher suite with an associated certificate is selected during the > DTLS handshake, the certificate received during the DTLS handshake MUST > match the fingerprint received in the SDP fingerprint attribute." >=20 > To me this seems to indicate the particular cipher suites are associated > with a particular certificate. While it's true that the certificate plays > a role in overall TLS negotiation, it does not provide a list of ciphers > to use. I think what this is saying is that if the client wishes to use a > certificate for DTLS it should provide a certificate fingerprint. Is that > right? Given the overall complexity of PKI in general I think being extra > clear here would help avoid any confusion. >=20 >=20 > 2. Section 4.1 describes handling anonymous faxes with freshly generated > self-signed certificates. It goes on to say: >=20 > "...and the content of the subjectAltName attribute inside the certificat= e > MUST NOT contain information that either allows correlation or > identification of the user making anonymous calls." >=20 > While the subjectAltName could potentially have identifiable data in it, > it is not always present as a field within the certificate. Some > certificates may have a subjectAltName, some may not. However, all > certificates should have a commonName. I think that is the item that > should be specifically called out as a place to avoid identifiable > information. Or, perhaps, simply stipulating that no fields within the > certificate should contain identifiable information. >=20 >=20 > 3. Section 4.3 describes rekeying a connection that is established. The > DTLS RFC describes how to handle this, but gives two options to an > endpoint where out-of-order packets are received that have been encrypted > with different keys; discard the packet, or, retain two sets of keying > material for some recommended interval. DTLS is not specific as to what t= o > do here. Section 4.3 says the receiver SHOULD maintain the keying > material. Given the nature of T.38, I think it may be prudent to say the > receiver MUST maintain the keying material. Dropping and/or discarding > T.38 packets would never be my preference. >=20 > If there's any questions or concerns about the above please let me know. >=20 > Best regards, > Adam Gensler >=20 >=20 From fandreas@cisco.com Wed Jan 22 16:28:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDD21A01D6 for ; Wed, 22 Jan 2014 16:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.736 X-Spam-Level: X-Spam-Status: No, score=-14.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwyHS_X6s0Us for ; Wed, 22 Jan 2014 16:28:32 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 969411A01A5 for ; Wed, 22 Jan 2014 16:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3710; q=dns/txt; s=iport; t=1390436912; x=1391646512; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7iQ54abvQYaTbnKEW2vuFqObSbbnblB7FCyJj3VB9BI=; b=g7fx/qbDHBrIxIVwAFYP8CI86TusAf1iOeQkR096Jxme/LNJzEIMwY0X 4wO8Slx0UPzIj816nunM9WsPKkoHfshr/fre9b/3Gmft2dsMPrS+Emk0y +X9DHq55FJFrJ7GysTjBtcGyXeYu/7zl+Z1lEjq2yQY7b86iSA4HQBzS6 E=; X-IronPort-AV: E=Sophos;i="4.95,703,1384300800"; d="scan'208";a="101122801" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 23 Jan 2014 00:28:32 +0000 Received: from dhcp-10-155-84-85.cisco.com (dhcp-10-155-84-85.cisco.com [10.155.84.85]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0N0SUJT015075; Thu, 23 Jan 2014 00:28:31 GMT Message-ID: <52E0622E.5070806@cisco.com> Date: Wed, 22 Jan 2014 19:28:30 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: SM , "Muthu Arul Mozhi Perumal (mperumal)" , "DRAGE, Keith (Keith)" , =?ISO-8859-1?Q?Ari_Ker=E4nen?= References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> <949EF20990823C4C85C18D59AA11AD8B0F23CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> <6.2.5.6.2.20131204204318.0b8c2430@resistor.net> In-Reply-To: <6.2.5.6.2.20131204204318.0b8c2430@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jan 2014 00:28:35 -0000 Greetings The chairs have reviewed this thread carefully and also discussed it with our AD. To conclude, we believe we have concensus to proceed with the document as follows: - The document does not formally update RFC 4856 (or any other RFC) and hence the front page and abstract will be updated accordingly. - The document will remain Standards Track. - Since the "annexa" and "annexb" parameters are defined in RFC 4856, it makes sense to keep the reference to RFC 4856 in the introductory text, along the lines of Muthu's suggested "New Introduction" text in the previous message in this thread. If anybody disagrees with this conclusion, please let the chairs know. Thanks Ari & Flemming (MMUSIC co-chairs) On 12/4/13, 11:54 PM, SM wrote: > Hi Muthu, > At 20:13 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: >> I see your point. >> >> Our opinion was that an RFC that specifies the mapping of media type >> parameters with SDP and registers the media types with IANA should >> also describe its usage, especially with the offer/answer model (e.g, >> RFC435). In that sense we thought draft-ietf-mmusic-sdp-g723-g729 is >> an update to RFC4856. >> >> Your opinion is that they should be delinked -- one RFC can register >> the media types and another RFC can describe the usage for the >> registered media types independently. I am fine with that. The >> abstract and introduction in draft-ietf-mmusic-sdp-g723-g729 can >> easily be changed to reflect it. > > Yes, but you can have both in one RFC. The registration can be > requested in the IANA Considerations section. > >> --------------------------------------------------------------------- >> Current Abstract: >> 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 Session Description >> protocol(SDP) offer and answer. This document provides the offer/ >> answer considerations for these parameters and updates RFC4856. >> >> New Abstract: >> There are no specifications that describe the offerer and answerer >> behavior when the value of the annexa parameter of G729 or the annexb >> parameter of G729, G729D and G729E does not match in the Session >> Description protocol(SDP) offer and answer. This document provides >> the >> offer/answer considerations for these parameters. > > I suggest removing "there are no specifications ..." and explain what > the document specifies. > >> Current Introduction: >> [RFC4856] describes the annexa parameter for G723 as follows: >> >> annexa: indicates that Annex A, voice activity detection, is used >> or preferred. Permissible values are "yes" and "no" (without the >> quotes); "yes" is implied if this parameter is omitted. >> >> Also, [RFC4856] describes the annexb parameter for G729, G729D and >> G729E as follows: >> >> annexb: indicates that Annex B, voice activity detection, is used >> or preferred. Permissible values are "yes" and "no" (without the >> quotes); "yes" is implied if this parameter is omitted. > > The above starts with RFC 4856. I suggest starting with the RFC 4566 > followed by the RFC 3264 text (I did not verify the reference). You > can then specify the fmtp parameters for Annex A, etc. Once you have > done that, verify whether there are some registry requirements and add > text for that in a IANA Considerations section. > > Regards, > -sm > . > From internet-drafts@ietf.org Thu Jan 23 01:58:32 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FDF1A0390; Thu, 23 Jan 2014 01:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjuk3vnmbQBF; Thu, 23 Jan 2014 01:58:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D0C1A0349; Thu, 23 Jan 2014 01:58:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123095830.12476.4096.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 01:58:30 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 09:58:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : The Evaluation of Different Network Address Trans= lator (NAT) Traversal Techniques for Media Controlled by Real-time Streamin= g Protocol (RTSP) Authors : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-11.txt Pages : 39 Date : 2014-01-23 Abstract: This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-evaluation-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jan 23 02:03:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079161A03DD; Thu, 23 Jan 2014 02:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqMVZth88brm; Thu, 23 Jan 2014 02:03:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B806A1A03C5; Thu, 23 Jan 2014 02:03:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123100328.14993.53403.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 02:03:28 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-18.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 10:03:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : A Network Address Translator (NAT) Traversal Mech= anism for Media Controlled by Real-Time Streaming Protocol (RTSP) Authors : Jeff Goldberg Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-18.txt Pages : 32 Date : 2014-01-23 Abstract: This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams set up and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary RTSP extensions and procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jan 23 02:29:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF08F1A03D5; Thu, 23 Jan 2014 02:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lWzIxIP7e2S; Thu, 23 Jan 2014 02:29:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D001A03CA; Thu, 23 Jan 2014 02:29:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123102918.22643.65104.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 02:29:18 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 10:29:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : The Evaluation of Different Network Address Trans= lator (NAT) Traversal Techniques for Media Controlled by Real-time Streamin= g Protocol (RTSP) Authors : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-12.txt Pages : 39 Date : 2014-01-23 Abstract: This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-evaluation-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Thu Jan 23 02:36:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A33C1A03D5 for ; Thu, 23 Jan 2014 02:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuHj022KyO0f for ; Thu, 23 Jan 2014 02:36:42 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id B84A71A03A9 for ; Thu, 23 Jan 2014 02:36:41 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-89-52e0f0b8ceff Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id F9.88.04853.8B0F0E25; Thu, 23 Jan 2014 11:36:40 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.347.0; Thu, 23 Jan 2014 11:36:40 +0100 Message-ID: <52E0F0B7.5090805@ericsson.com> Date: Thu, 23 Jan 2014 11:36:39 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: References: <20140123102918.22643.65104.idtracker@ietfa.amsl.com> In-Reply-To: <20140123102918.22643.65104.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZGfG3RnfHhwdBBjd6ZS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO3XT7EUfJSouP35E1sD403hLkZODgkBE4m/F9YyQ9hiEhfu rWfrYuTiEBI4wSjR9vI/K4SznFHi4dRuVpAqXgFtif8fHjKC2CwCqhIHFq9hA7HZBCwkbv5o BLNFBYIlbk17wA5RLyhxcuYTFhBbREBU4tHFRWBzhAX8JG70PwCq5wBa4Cjxq70UJMwp4CRx bVsbI0hYQkBcoqcxCCTMLKAnMeVqCyOELS/RvHU22M1CQNc0NHWwTmAUnIVk2SwkLbOQtCxg ZF7FKFmcWlycm25koJebnluil1qUmVxcnJ+nV5y6iREYoAe3/DbawXhyj/0hRmkOFiVx3uus NUFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGAPCDl1dsPArQ/aRg72uSr+vH0//GF5ed/1a zOFLP26xvvql+c5gcv9xL3GW12fcXSQ+vCkU5HvPpHVyzt7UY/s6o+Wj7eVzjvjMPRG+6d87 oeuWK71q5xqJ685y23jk8i/XSeo5izYbzJFf/nD620DBfRxHKh+/2V+wkbdLsOhcs67Nnn+W 81yVWIozEg21mIuKEwFiEz49HgIAAA== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jan 2014 10:36:43 -0000 WG, This revision is the result of feedback from Flemming during his doc shepherd write-up process and review. What has been changed is: - Made the copied text into a quote to avoid having to put pre RFC 5378 disclaimer on the document. This was what caused the rapid 11-12 version as I had realized that I had edited the text from RFC 4787. - Lots of small editorial fixes. - More references in appropriate places, including to the latching document. - Reformulated text regarding security considerations for latching. Cheers Magnus On 2014-01-23 11:29, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) > Authors : Magnus Westerlund > Thomas Zeng > Filename : draft-ietf-mmusic-rtsp-nat-evaluation-12.txt > Pages : 39 > Date : 2014-01-23 > > Abstract: > This document describes several Network Address Translator (NAT) > traversal techniques that were considered to be used for establishing > the RTP media flows controlled by the Real-time Streaming Protocol > (RTSP). Each technique includes a description of how it would be > used, the security implications of using it and any other deployment > considerations it has. There are also discussions on how NAT > traversal techniques relate to firewalls and how each technique can > be applied in different use cases. These findings were used when > selecting the NAT traversal for RTSP 2.0, which is specified in a > separate document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 magnus.westerlund@ericsson.com Thu Jan 23 02:41:26 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3459A1A03A9 for ; Thu, 23 Jan 2014 02:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRecwlb---do for ; Thu, 23 Jan 2014 02:41:24 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B4DA21A0231 for ; Thu, 23 Jan 2014 02:41:23 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-84-52e0f1d24885 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1E.EA.23809.2D1F0E25; Thu, 23 Jan 2014 11:41:22 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.347.0; Thu, 23 Jan 2014 11:41:21 +0100 Message-ID: <52E0F1D1.2050607@ericsson.com> Date: Thu, 23 Jan 2014 11:41:21 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: References: <20140123100328.14993.53403.idtracker@ietfa.amsl.com> In-Reply-To: <20140123100328.14993.53403.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvje6ljw+CDNZsl7OYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4MqZNO8hcsFSsYu22fqYGxi2CXYycHBICJhL919azQNhiEhfu rWfrYuTiEBI4xChx7NFfVghnOaPE12/bGUGqeAW0JZbtXMYOYrMIqEps+d/KDGKzCVhI3PzR yAZiiwoES9ya9oAdol5Q4uTMJ2AbRAREJR5dXMQKYgsLOEtM/NnDBGILCThKfH5wBmgOBwen gJPEtmusIKaEgLhET2MQSAWzgJ7ElKstjBC2vETz1tnMEJ3aEg1NHawTGAVnIVk2C0nLLCQt CxiZVzGy5yZm5qSXG21iBAbfwS2/VXcw3jkncohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2Ms693e97YapCSnHbwr17Soyn/DuYrneVIDI6bapl71H/RHxabb0euax/6 Pv/R0ozNz/yzV21u6uY45XFio5rFxTML4oR4RRNamZi3+O/pmvaoo32hkNYbf7HPT8RzFQ4/ 614e0/9C8smauUdVwnSmf/tt+7Jux3vz59sYNv881rPgj2Gl6BRhNSWW4oxEQy3mouJEANoW n6kMAgAA Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-18.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jan 2014 10:41:26 -0000 WG, This revision is the result of feedback from Flemming during his doc shepherd write-up process and review. The changes made are: - Lots of editorial corrections - Section 4.2: Added escaping for ICE extensions resulting in new parameters and values. - Changed some lower case should, must etc to their upper case versions where appropriate. - Section 6.10 has been expanded to clarify when 480 response may result in freeing of candidates. - Section 6.12 has text on what to do when a ICE restart fails. Cheers Magnus On 2014-01-23 11:03, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP) > Authors : Jeff Goldberg > Magnus Westerlund > Thomas Zeng > Filename : draft-ietf-mmusic-rtsp-nat-18.txt > Pages : 32 > Date : 2014-01-23 > > Abstract: > This document defines a solution for Network Address Translation > (NAT) traversal for datagram based media streams set up and > controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). > It uses Interactive Connectivity Establishment (ICE) adapted to use > RTSP as a signalling channel, defining the necessary RTSP extensions > and procedures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-18 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-18 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 harald@alvestrand.no Thu Jan 23 03:22:25 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB1B1A03E6 for ; Thu, 23 Jan 2014 03:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKL6ZPxjyynB for ; Thu, 23 Jan 2014 03:22:23 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 751641A039D for ; Thu, 23 Jan 2014 03:22:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 687A739E1C0 for ; Thu, 23 Jan 2014 12:22:30 +0100 (CET) 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 GjRT7z9Aa-W8 for ; Thu, 23 Jan 2014 12:22:29 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AA71339E127 for ; Thu, 23 Jan 2014 12:22:29 +0100 (CET) Message-ID: <52E0FB6D.50906@alvestrand.no> Date: Thu, 23 Jan 2014 12:22:21 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MSID draft -03 is out X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jan 2014 11:22:25 -0000 This draft was published on January 6. Copy of the changelog: C.9. Changes from mmusic-msid-02 to -03 Corrected even more cases where the word "ssrc" was not changed to "M-line". Added the functionality of using an asterisk (*) in the msid-semantic line, in order to remove the need for listing all msids in the msid- semantic line whne only one msid-semantic is in use. Removed some now-unnecessary text. Comments are welcome! Harald From adam@nostrum.com Thu Jan 23 12:18:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9C61A00C5 for ; Thu, 23 Jan 2014 12:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzpwGottvDDZ for ; Thu, 23 Jan 2014 12:18:06 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 86B7B1A0049 for ; Thu, 23 Jan 2014 12:18:06 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0NKI4X4069577 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 23 Jan 2014 14:18:05 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52E178F6.70009@nostrum.com> Date: Thu, 23 Jan 2014 14:17:58 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="------------010400040301040307060201" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jan 2014 20:18:07 -0000 This is a multi-part message in MIME format. --------------010400040301040307060201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I've had an interesting issue brought to my attention regarding RFC4473 "telephone-event" handling. Section 2.1 requires that "Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel". On its face, this would imply that offering voice codecs with varying clock rates would result in the need to offer several PTs with telephone-event, varying only in frequency. So, for example, if we were setting up a media session that looked like this m=audio 12346 RTP/AVP 0 97 98 99 a=rtpmap:0 PCMU/8000 a=rtpmap:97 opus/4800 0/2 a=rtpmap:98 AMR-WB/16000 a=rtpmap:99 speex/32000 But want to add telephone-event to it, we would need to do this: m=audio 12346 RTP/AVP 0 97 98 99 100 101 102 103 a=rtpmap:0 PCMU/8000 a=rtpmap:97 opus/48000/2 a=rtpmap:98 AMR-WB/16000 a=rtpmap:99 speex/32000 a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15 a=rtpmap:101 telephone-event/48000 a=fmtp:101 0-15 a=rtpmap:102 telephone-event/16000 a=fmtp:102 0-15 a=rtpmap:103 telephone-event/32000 a=fmtp:103 0-15 Rather than this: m=audio 12346 RTP/AVP 0 97 98 99 100 a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMA/8000 a=rtpmap:97 opus/48000/2 a=rtpmap:98 AMR-WB/16000 a=rtpmap:99 speex/32000 a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15 And then it would be incumbent on the remote end to ensure that they use the *correct* DTMF PT to match the codec that they're using for speech. This all seems like patent nonsense, and it burns an additional PT for each clock rate. Is that really what was intended by this language in RFC 4733? /a --------------010400040301040307060201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I've had an interesting issue brought to my attention regarding RFC4473 "telephone-event" handling.

Section 2.1 requires that "Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel".

On its face, this would imply that offering voice codecs with varying clock rates would result in the need to offer several PTs with telephone-event, varying only in frequency.

So, for example, if we were setting up a media session that looked like this

    m=audio 12346 RTP/AVP 0 97 98 99
   a=rtpmap:0 PCMU/8000
   a=rtpmap:97 opus/4800 0/2
   a=rtpmap:98 AMR-WB/16000
   a=rtpmap:99 speex/32000

But want to add telephone-event to it, we would need to do this:

   m=audio 12346 RTP/AVP 0 97 98 99 100 101 102 103
   a=rtpmap:0 PCMU/8000
   a=rtpmap:97 opus/48000/2
   a=rtpmap:98 AMR-WB/16000
   a=rtpmap:99 speex/32000
   a=rtpmap:100 telephone-event/8000
   a=fmtp:100 0-15
   a=rtpmap:101 telephone-event/48000
   a=fmtp:101 0-15
   a=rtpmap:102 telephone-event/16000
   a=fmtp:102 0-15
   a=rtpmap:103 telephone-event/32000
   a=fmtp:103 0-15


Rather than this:

   m=audio 12346 RTP/AVP 0 97 98 99 100
   a=rtpmap:0 PCMU/8000
   a=rtpmap:0 PCMA/8000
   a=rtpmap:97 opus/48000/2
   a=rtpmap:98 AMR-WB/16000
   a=rtpmap:99 speex/32000
   a=rtpmap:100 telephone-event/8000
   a=fmtp:100 0-15


And then it would be incumbent on the remote end to ensure that they use the *correct* DTMF PT to match the codec that they're using for speech.

This all seems like patent nonsense, and it burns an additional PT for each clock rate. Is that really what was intended by this language in RFC 4733?

/a
 --------------010400040301040307060201-- From christer.holmberg@ericsson.com Thu Jan 23 17:43:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0C61A0485 for ; Thu, 23 Jan 2014 17:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL6kx-OnLnF5 for ; Thu, 23 Jan 2014 17:43:42 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8A01A01A5 for ; Thu, 23 Jan 2014 17:43:41 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-89-52e1c54baa50 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 94.AA.10875.B45C1E25; Fri, 24 Jan 2014 02:43:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 02:43:39 +0100 From: Christer Holmberg To: "Gonzalo Salgueiro (gsalguei)" , "Adam Gensler (agensler)" Thread-Topic: Review of draft-ietf-mmusic-udptl-dtls-03 Thread-Index: AQHPF6Z7X1rBlQF7JUm0AYYGqOYxvZqRgxMAgAGYwMA= Date: Fri, 24 Jan 2014 01:43:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D11B0EA@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+Jvja730YdBBu2vLCyWfr/DZjF3ip/F 1OWPWRyYPab83sjqsWTJT6YApigum5TUnMyy1CJ9uwSujMub/7IXfJKp2H27ib2B8Zx4FyMn h4SAicTTHY+YIGwxiQv31rN1MXJxCAkcYpRofPCNGcJZwijx4dBOli5GDg42AQuJ7n/aIA0i ApkSn6ctZwexmQVkJGacbQQbJCxgJtF3s4sZosZconnqXUaQVhEBK4mLH81AwiwCqhLXrk4D a+UV8JWY8G0FmC0kkCjRs+ogC4jNKWArcf7zMbA4I9Bt30+tYYJYJS7x4eB1ZoibBSSW7DkP ZYtKvHz8jxXCVpJYe3g7C0S9nsSNqVPYIGxtiWULXzND7BWUODnzCcsERrFZSMbOQtIyC0nL LCQtCxhZVjGy5yZm5qSXG25iBEbKwS2/dXcwnjoncohRmoNFSZz3w1vnICGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2MgTJz1PuWCovKyeZwx0jLqsQJ7H76tuzMky3hu67O+mxpVm5w1V+H t6rAMdn3NUO6ZvytYyZzWrw+eT499f1w9jzBglNr2llPXp2hKKIvoSH+f35Tz/sNLbtj7i7r TAw40byO537OtKpNF4y/BZUnxW4+PnNyVq1mJ3/yoq2a7b9yo/fVbdNXYinOSDTUYi4qTgQA QP8YU2ICAAA= Cc: mmusic Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jan 2014 01:43:44 -0000 Hi Adam, Thank You very much for the review! I am currently on a business trip, but = I'll address your comments asap. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com]=20 L=E4hetetty: 22. tammikuuta 2014 21:20 Vastaanottaja: Adam Gensler (agensler) Kopio: Gonzalo Salgueiro (gsalguei); Christer Holmberg; mmusic Aihe: Re: Review of draft-ietf-mmusic-udptl-dtls-03 T=E4rkeys: Suuri Thanks very much for your detailed review, Adam. I'm copying the MMUSIC@ l= ist for awareness. Cheers, Gonzalo On Jan 22, 2014, at 2:16 PM, Adam Gensler (agensler) w= rote: > Gonzalo, Christer, >=20 > After speaking with Gonzalo I've reviewed draft-ietf-mmusic-udptl-dtls-03= . > Overall this draft is excellent and appears to cover all the corner=20 > cases I could think of. I do have a few comments, see below: >=20 > 1. In section 3.1, secure channel establishment, there is the=20 > following > text: >=20 > "If the endpoint supports, and is willing to use, a cipher suite with=20 > an associated certificate, it MUST include an SDP fingerprint=20 > attribute > [RFC4572 ] in the SDP." >=20 > "If a cipher suite with an associated certificate is selected during=20 > the DTLS handshake, the certificate received during the DTLS handshake=20 > MUST match the fingerprint received in the SDP fingerprint attribute." >=20 > To me this seems to indicate the particular cipher suites are=20 > associated with a particular certificate. While it's true that the=20 > certificate plays a role in overall TLS negotiation, it does not=20 > provide a list of ciphers to use. I think what this is saying is that=20 > if the client wishes to use a certificate for DTLS it should provide a=20 > certificate fingerprint. Is that right? Given the overall complexity=20 > of PKI in general I think being extra clear here would help avoid any con= fusion. >=20 >=20 > 2. Section 4.1 describes handling anonymous faxes with freshly=20 > generated self-signed certificates. It goes on to say: >=20 > "...and the content of the subjectAltName attribute inside the=20 > certificate MUST NOT contain information that either allows=20 > correlation or identification of the user making anonymous calls." >=20 > While the subjectAltName could potentially have identifiable data in=20 > it, it is not always present as a field within the certificate. Some=20 > certificates may have a subjectAltName, some may not. However, all=20 > certificates should have a commonName. I think that is the item that=20 > should be specifically called out as a place to avoid identifiable=20 > information. Or, perhaps, simply stipulating that no fields within the=20 > certificate should contain identifiable information. >=20 >=20 > 3. Section 4.3 describes rekeying a connection that is established.=20 > The DTLS RFC describes how to handle this, but gives two options to an=20 > endpoint where out-of-order packets are received that have been=20 > encrypted with different keys; discard the packet, or, retain two sets=20 > of keying material for some recommended interval. DTLS is not specific=20 > as to what to do here. Section 4.3 says the receiver SHOULD maintain=20 > the keying material. Given the nature of T.38, I think it may be=20 > prudent to say the receiver MUST maintain the keying material.=20 > Dropping and/or discarding > T.38 packets would never be my preference. >=20 > If there's any questions or concerns about the above please let me know. >=20 > Best regards, > Adam Gensler >=20 >=20 From thomas.stach@unify.com Thu Jan 23 23:19:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008161A010E for ; Thu, 23 Jan 2014 23:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seMfFZzRX431 for ; Thu, 23 Jan 2014 23:19:43 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 42D791A013A for ; Thu, 23 Jan 2014 23:19:43 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id A2C231EB8588; Fri, 24 Jan 2014 08:19:41 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.183]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 08:19:41 +0100 From: "Stach, Thomas" To: Adam Roach Thread-Topic: [MMUSIC] Telephone-event and multiple clock rates Thread-Index: AQHPGHg+Hoa1O/rTbkS9JzrtRXTrK5qTdMaA Date: Fri, 24 Jan 2014 07:19:40 +0000 Message-ID: References: <52E178F6.70009@nostrum.com> In-Reply-To: <52E178F6.70009@nostrum.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE1217A2E16DMCHP04MSXglobal_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jan 2014 07:19:46 -0000 --_000_F81CEE99482EFE438DAE2A652361EE1217A2E16DMCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRhbSwNCg0KdGhlcmUgaXMgYW4gZXJyYXRhIHRoYXQgY292ZXJzIHRoZSBpc3N1ZS4NCmh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTQ3MzMgKGNsb3NlIHRv IGJvdHRvbSkNCkl0IHBvaW50cyB0byBzb21lIGRpc2N1c3Npb24gYXQNCmh0dHA6Ly90b29scy5p ZXRmLm9yZy93Zy9hdnRleHQvbWludXRlcz9pdGVtPW1pbnV0ZXMtODUtYXZ0ZXh0Lmh0bWwgKGNs b3NlIHRvIGJvdHRvbSkNCg0KRnJvbSB0aGF0IEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBuZWdvdGlh dGVkIGF1ZGlvIGNvZGVjIGRldGVybWluZXMgdGhlIGNsb2NrIHJhdGUgZm9yIERUTUYuDQpJdCBz dGlsbCByZW1haW5zIGludGVyZXN0aW5nIHdoYXQgaGlzIG1lYW5zIGlmIHR3byBjb2RlY3Mgd2l0 aCBkaWZmZXJlbnQgY2xvY2sgcmF0ZXMgd2VyZSBuZWdvdGlhdGVkIGFuZCBjb2RlYy1zd2l0Y2hp bmctb24tdGhlLWZseSBoYXBwZW5zLg0KDQpLaW5kIFJlZ2FyZHMvbWl0IGZyZXVuZGxpY2hlbiBH csO8w59lbg0KVGhvbWFzIFN0YWNoDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRhbSBSb2FjaA0KU2VudDogRG9ubmVyc3RhZywg MjMuIEphbnVhciAyMDE0IDIxOjE4DQpUbzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBbTU1V U0lDXSBUZWxlcGhvbmUtZXZlbnQgYW5kIG11bHRpcGxlIGNsb2NrIHJhdGVzDQoNCkkndmUgaGFk IGFuIGludGVyZXN0aW5nIGlzc3VlIGJyb3VnaHQgdG8gbXkgYXR0ZW50aW9uIHJlZ2FyZGluZyBS RkM0NDczICJ0ZWxlcGhvbmUtZXZlbnQiIGhhbmRsaW5nLg0KDQpTZWN0aW9uIDIuMSByZXF1aXJl cyB0aGF0ICJOYW1lZCB0ZWxlcGhvbmUgZXZlbnRzIGFyZSBjYXJyaWVkIGFzIHBhcnQgb2YgdGhl IGF1ZGlvIHN0cmVhbSBhbmQgTVVTVCB1c2UgdGhlIHNhbWUgc2VxdWVuY2UgbnVtYmVyIGFuZCB0 aW1lc3RhbXAgYmFzZSBhcyB0aGUgcmVndWxhciBhdWRpbyBjaGFubmVsIi4NCg0KT24gaXRzIGZh Y2UsIHRoaXMgd291bGQgaW1wbHkgdGhhdCBvZmZlcmluZyB2b2ljZSBjb2RlY3Mgd2l0aCB2YXJ5 aW5nIGNsb2NrIHJhdGVzIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCB0byBvZmZlciBzZXZlcmFs IFBUcyB3aXRoIHRlbGVwaG9uZS1ldmVudCwgdmFyeWluZyBvbmx5IGluIGZyZXF1ZW5jeS4NCg0K U28sIGZvciBleGFtcGxlLCBpZiB3ZSB3ZXJlIHNldHRpbmcgdXAgYSBtZWRpYSBzZXNzaW9uIHRo YXQgbG9va2VkIGxpa2UgdGhpcw0KDQogICBtPWF1ZGlvIDEyMzQ2IFJUUC9BVlAgMCA5NyA5OCA5 OQ0KICAgYT1ydHBtYXA6MCBQQ01VLzgwMDANCiAgIGE9cnRwbWFwOjk3IG9wdXMvNDgwMCAwLzIN CiAgIGE9cnRwbWFwOjk4IEFNUi1XQi8xNjAwMA0KICAgYT1ydHBtYXA6OTkgc3BlZXgvMzIwMDAN Cg0KQnV0IHdhbnQgdG8gYWRkIHRlbGVwaG9uZS1ldmVudCB0byBpdCwgd2Ugd291bGQgbmVlZCB0 byBkbyB0aGlzOg0KDQogICBtPWF1ZGlvIDEyMzQ2IFJUUC9BVlAgMCA5NyA5OCA5OSAxMDAgMTAx IDEwMiAxMDMNCiAgIGE9cnRwbWFwOjAgUENNVS84MDAwDQogICBhPXJ0cG1hcDo5NyBvcHVzLzQ4 MDAwLzINCiAgIGE9cnRwbWFwOjk4IEFNUi1XQi8xNjAwMA0KICAgYT1ydHBtYXA6OTkgc3BlZXgv MzIwMDANCiAgIGE9cnRwbWFwOjEwMCB0ZWxlcGhvbmUtZXZlbnQvODAwMA0KICAgYT1mbXRwOjEw MCAwLTE1DQogICBhPXJ0cG1hcDoxMDEgdGVsZXBob25lLWV2ZW50LzQ4MDAwDQogICBhPWZtdHA6 MTAxIDAtMTUNCiAgIGE9cnRwbWFwOjEwMiB0ZWxlcGhvbmUtZXZlbnQvMTYwMDANCiAgIGE9Zm10 cDoxMDIgMC0xNQ0KICAgYT1ydHBtYXA6MTAzIHRlbGVwaG9uZS1ldmVudC8zMjAwMA0KICAgYT1m bXRwOjEwMyAwLTE1DQoNCg0KUmF0aGVyIHRoYW4gdGhpczoNCg0KICAgbT1hdWRpbyAxMjM0NiBS VFAvQVZQIDAgOTcgOTggOTkgMTAwDQogICBhPXJ0cG1hcDowIFBDTVUvODAwMA0KICAgYT1ydHBt YXA6MCBQQ01BLzgwMDANCiAgIGE9cnRwbWFwOjk3IG9wdXMvNDgwMDAvMg0KICAgYT1ydHBtYXA6 OTggQU1SLVdCLzE2MDAwDQogICBhPXJ0cG1hcDo5OSBzcGVleC8zMjAwMA0KICAgYT1ydHBtYXA6 MTAwIHRlbGVwaG9uZS1ldmVudC84MDAwDQogICBhPWZtdHA6MTAwIDAtMTUNCg0KDQpBbmQgdGhl biBpdCB3b3VsZCBiZSBpbmN1bWJlbnQgb24gdGhlIHJlbW90ZSBlbmQgdG8gZW5zdXJlIHRoYXQg dGhleSB1c2UgdGhlICpjb3JyZWN0KiBEVE1GIFBUIHRvIG1hdGNoIHRoZSBjb2RlYyB0aGF0IHRo ZXkncmUgdXNpbmcgZm9yIHNwZWVjaC4NCg0KVGhpcyBhbGwgc2VlbXMgbGlrZSBwYXRlbnQgbm9u c2Vuc2UsIGFuZCBpdCBidXJucyBhbiBhZGRpdGlvbmFsIFBUIGZvciBlYWNoIGNsb2NrIHJhdGUu IElzIHRoYXQgcmVhbGx5IHdoYXQgd2FzIGludGVuZGVkIGJ5IHRoaXMgbGFuZ3VhZ2UgaW4gUkZD IDQ3MzM/DQoNCi9hDQo= --_000_F81CEE99482EFE438DAE2A652361EE1217A2E16DMCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BZGFtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlcmUgaXMgYW4gZXJyYXRhIHRo YXQgY292ZXJzIHRoZSBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJl Zj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9NDczMyI+ aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9NDczMzwvYT4g KGNsb3NlIHRvIGJvdHRvbSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgcG9pbnRz IHRvIHNvbWUgZGlzY3Vzc2lvbiBhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvYXZ0ZXh0L21pbnV0ZXM/aXRlbT1taW51dGVz LTg1LWF2dGV4dC5odG1sIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvYXZ0ZXh0L21pbnV0ZXM/ aXRlbT1taW51dGVzLTg1LWF2dGV4dC5odG1sPC9hPiAoY2xvc2UNCiB0byBib3R0b20pIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+RnJvbSB0aGF0IEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBuZWdvdGlhdGVkIGF1ZGlvIGNv ZGVjIGRldGVybWluZXMgdGhlIGNsb2NrIHJhdGUgZm9yIERUTUYuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SXQgc3RpbGwgcmVtYWlucyBpbnRlcmVzdGluZyB3aGF0IGhpcyBtZWFu cyBpZiB0d28gY29kZWNzIHdpdGggZGlmZmVyZW50IGNsb2NrIHJhdGVzIHdlcmUgbmVnb3RpYXRl ZCBhbmQgY29kZWMtc3dpdGNoaW5nLW9uLXRoZS1mbHkgaGFwcGVucy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5LaW5kIFJlZ2FyZHMvbWl0IGZyZXVuZGxpY2hlbiBHcsO8w59lbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaG9tYXMgU3RhY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4g bW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkFkYW0gUm9hY2g8YnI+DQo8Yj5TZW50OjwvYj4gRG9ubmVyc3RhZywgMjMuIEphbnVhciAy MDE0IDIxOjE4PGJyPg0KPGI+VG86PC9iPiBtbXVzaWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gW01NVVNJQ10gVGVsZXBob25lLWV2ZW50IGFuZCBtdWx0aXBsZSBjbG9jayByYXRlczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SSd2ZSBoYWQgYW4gaW50ZXJlc3RpbmcgaXNzdWUgYnJv dWdodCB0byBteSBhdHRlbnRpb24gcmVnYXJkaW5nIFJGQzQ0NzMgJnF1b3Q7dGVsZXBob25lLWV2 ZW50JnF1b3Q7IGhhbmRsaW5nLjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8YnI+DQo8dHQ+ U2VjdGlvbiAyLjEgcmVxdWlyZXMgdGhhdCAmcXVvdDtOYW1lZCB0ZWxlcGhvbmUgZXZlbnRzIGFy ZSBjYXJyaWVkIGFzIHBhcnQgb2YgdGhlIGF1ZGlvIHN0cmVhbSBhbmQgTVVTVCB1c2UgdGhlIHNh bWUgc2VxdWVuY2UgbnVtYmVyIGFuZCB0aW1lc3RhbXAgYmFzZSBhcyB0aGUgcmVndWxhciBhdWRp byBjaGFubmVsJnF1b3Q7LjwvdHQ+PGJyPg0KPGJyPg0KPHR0Pk9uIGl0cyBmYWNlLCB0aGlzIHdv dWxkIGltcGx5IHRoYXQgb2ZmZXJpbmcgdm9pY2UgY29kZWNzIHdpdGggdmFyeWluZyBjbG9jayBy YXRlcyB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgdG8gb2ZmZXIgc2V2ZXJhbCBQVHMgd2l0aCB0 ZWxlcGhvbmUtZXZlbnQsIHZhcnlpbmcgb25seSBpbiBmcmVxdWVuY3kuPC90dD48YnI+DQo8YnI+ DQo8dHQ+U28sIGZvciBleGFtcGxlLCBpZiB3ZSB3ZXJlIHNldHRpbmcgdXAgYSBtZWRpYSBzZXNz aW9uIHRoYXQgbG9va2VkIGxpa2UgdGhpczwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNw OyBtPWF1ZGlvIDEyMzQ2IFJUUC9BVlAgMCA5NyA5OCA5OTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBhPXJ0cG1hcDowIFBDTVUvODAwMDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBhPXJ0 cG1hcDo5NyBvcHVzLzQ4MDA8L3R0Pjwvc3Bhbj4gPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4wLzI8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBh PXJ0cG1hcDo5OCBBTVItV0IvMTYwMDA8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYT1ydHBt YXA6OTkgc3BlZXgvMzIwMDA8L3R0Pjxicj4NCjxicj4NCjx0dD5CdXQgd2FudCB0byBhZGQgdGVs ZXBob25lLWV2ZW50IHRvIGl0LCB3ZSB3b3VsZCBuZWVkIHRvIGRvIHRoaXM6PC90dD48YnI+DQo8 L3NwYW4+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJz cDsgbT1hdWRpbyAxMjM0NiBSVFAvQVZQIDAgOTcgOTggOTkgMTAwIDEwMSAxMDIgMTAzPC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYT1ydHBtYXA6MCBQQ01VLzgw MDA8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYT1ydHBtYXA6OTcgb3B1cy80ODAwMC8yPC90 dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGE9cnRwbWFwOjk4IEFNUi1XQi8xNjAwMDwvdHQ+PGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyBhPXJ0cG1hcDo5OSBzcGVleC8zMjAwMDwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBhPXJ0cG1hcDoxMDAgdGVsZXBob25lLWV2ZW50LzgwMDA8L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsgYT1mbXRwOjEwMCAwLTE1PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IGE9cnRwbWFwOjEwMSB0ZWxlcGhvbmUtZXZlbnQvNDgwMDA8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgYT1mbXRwOjEwMSAwLTE1PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGE9cnRw bWFwOjEwMiB0ZWxlcGhvbmUtZXZlbnQvMTYwMDA8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsg YT1mbXRwOjEwMiAwLTE1PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGE9cnRwbWFwOjEwMyB0 ZWxlcGhvbmUtZXZlbnQvMzIwMDA8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYT1mbXRwOjEw MyAwLTE1PC90dD48YnI+DQo8YnI+DQo8YnI+DQo8dHQ+UmF0aGVyIHRoYW4gdGhpczo8L3R0Pjwv c3Bhbj48YnI+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNw OyZuYnNwOyBtPWF1ZGlvIDEyMzQ2IFJUUC9BVlAgMCA5NyA5OCA5OSAxMDA8L3NwYW4+PC90dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBhPXJ0cG1hcDowIFBDTVUvODAwMDwvdHQ+ PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBhPXJ0cG1hcDowIFBDTUEvODAwMDwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBhPXJ0cG1hcDo5NyBvcHVzLzQ4MDAwLzI8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgYT1ydHBtYXA6OTggQU1SLVdCLzE2MDAwPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IGE9cnRwbWFwOjk5IHNwZWV4LzMyMDAwPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGE9 cnRwbWFwOjEwMCB0ZWxlcGhvbmUtZXZlbnQvODAwMDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyBhPWZtdHA6MTAwIDAtMTU8L3R0Pjxicj4NCjxicj4NCjxicj4NCjx0dD5BbmQgdGhlbiBpdCB3 b3VsZCBiZSBpbmN1bWJlbnQgb24gdGhlIHJlbW90ZSBlbmQgdG8gZW5zdXJlIHRoYXQgdGhleSB1 c2UgdGhlICpjb3JyZWN0KiBEVE1GIFBUIHRvIG1hdGNoIHRoZSBjb2RlYyB0aGF0IHRoZXkncmUg dXNpbmcgZm9yIHNwZWVjaC48L3R0Pjxicj4NCjxicj4NCjx0dD5UaGlzIGFsbCBzZWVtcyBsaWtl IHBhdGVudCBub25zZW5zZSwgYW5kIGl0IGJ1cm5zIGFuIGFkZGl0aW9uYWwgUFQgZm9yIGVhY2gg Y2xvY2sgcmF0ZS4gSXMgdGhhdCByZWFsbHkgd2hhdCB3YXMgaW50ZW5kZWQgYnkgdGhpcyBsYW5n dWFnZSBpbiBSRkMgNDczMz88L3R0Pjxicj4NCjxicj4NCjx0dD4vYTwvdHQ+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F81CEE99482EFE438DAE2A652361EE1217A2E16DMCHP04MSXglobal_-- From magnus.westerlund@ericsson.com Fri Jan 24 02:29:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C6A1A01BA for ; Fri, 24 Jan 2014 02:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HphVvhWubKB for ; Fri, 24 Jan 2014 02:29:42 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id ED7C41A0226 for ; Fri, 24 Jan 2014 02:29:38 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-60-52e24091be88 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C8.E9.04249.19042E25; Fri, 24 Jan 2014 11:29:37 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.347.0; Fri, 24 Jan 2014 11:29:36 +0100 Message-ID: <52E24090.1030608@ericsson.com> Date: Fri, 24 Jan 2014 11:29:36 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Stach, Thomas" , Adam Roach References: <52E178F6.70009@nostrum.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvje5Eh0dBBodWilvs+buI3WLq8scs Fid3bmN2YPZYsuQnk8esnU9YPLb3PGYJYI7isklJzcksSy3St0vgytg66RJrwSqeijkzzrE1 ME7g6mLk5JAQMJF4e+IuO4QtJnHh3nq2LkYuDiGBI4wSV2cfYwJJCAksZ5T4csAAxOYV0JZY 0n2PBcRmEVCV+Ld5Jlgzm4CFxM0fjWwgtqhAsMStaQ/YIeoFJU7OfAJWLyLgLbHt33bWLkYO DmYBdYmri4NAwsICdhJH/01ih1iVLXHtUzcziM0p4C/RP+0/C0i5hIC4RE8jWDmzgJ7ElKst jBC2vETz1tnMEK3aEg1NHawTGIVmIVk8C0nLLCQtCxiZVzFyFKcWJ+WmGxlsYgQG78Etvy12 MF7+a3OIUZqDRUmc9+Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjMbmVyKYiq7ovD35 R0DM5u8/8feJUrHzWBX4Hc0qz+66KXuq/dP6+S0OUZf9q4zs+lexfF/yRmzbPOZ9R+5eOPpk QUG6nbvdh9v+j7r9D4mHmkq+s504X2rvR8bJFsVvrppUJzMeuWDKoHfztEBCtqXr1sWf6v8e P/fr2nbnSWqXttfzmr0oFlZiKc5INNRiLipOBABkrWVnLAIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jan 2014 10:29:44 -0000 Hi, My understanding for the reasoning behind this definition in the RFC is due to that the events is supposed to be connected to the same time-line as the audio. Thus it ended up using the same SSRC. To avoid timestamp rate switching which we know has issues (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/) it was mandated to provide one PT for each rate negotiated for the audio payload types. On 2014-01-24 08:19, Stach, Thomas wrote: > > It still remains interesting what his means if two codecs with different > clock rates were negotiated and codec-switching-on-the-fly happens. > So there is a difference in negotiating possible to use, another to actively switch between them within a RTP session for a particular media source. If you actually switch then you have to take the considerations in draft-ietf-avtext-multiple-clock-rates into account. If you are not switching, then these are only ensuring that you can use the events for what ever audio payload format you select to use out of the set offered and accepted. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 ari.keranen@ericsson.com Fri Jan 24 06:03:23 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C4C1A0477 for ; Fri, 24 Jan 2014 06:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnxt5jAayQE9 for ; Fri, 24 Jan 2014 06:03:22 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D1A7A1A0377 for ; Fri, 24 Jan 2014 06:03:21 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-7d-52e26f234bfc Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 21.65.04249.32F62E25; Fri, 24 Jan 2014 14:48:20 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.205]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 14:48:19 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Magnus Westerlund Thread-Topic: Comments on ABNF in draft-petithuguenin-mmusic-ice-sip-sdp-01 Thread-Index: AQHPF1VgyDIAHSSGLku7JH0ZsrROJpqT1nEA Date: Fri, 24 Jan 2014 13:48:18 +0000 Message-ID: References: <52DF90E9.2070902@ericsson.com> In-Reply-To: <52DF90E9.2070902@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <87C20A0EBD5A1B4CBC0DD5FF2B987D54@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvja5K/qMgg+aV7BZTlz9msbiw5i6T A5PH5SveHkuW/GQKYIrisklJzcksSy3St0vgytjSvY6tYLZkRf+NVYwNjIcEuxg5OSQETCQa 5q1igbDFJC7cW8/WxcjFISRwhFGibelCJghnCaNEd9d0VpAqNgF7iclrPjKC2CICZhIPJ+xn A7GZBQIlujtPM4PYwgJeEnu2L2GCqPGW+NPSzgxhG0msn9cJNodFQFXi78kzYDYv0MyjqzeB zRQS0JbY++wV2ExOAR2Jg+ePgV3HCHTd91NrmCB2iUvcejKfCeJqAYkle84zQ9iiEi8f/2OF sJUkVmy/xAhRrydxY+oUoJkcQLa1xJn58RBhbYllC18zQ5wgKHFy5hOWCYzis5BsmIWkexZC 9ywk3bOQdC9gZF3FyFGcWpyUm25ksIkRGFEHt/y22MF4+a/NIUZpDhYlcd6Pb52DhATSE0tS s1NTC1KL4otKc1KLDzEycXBKNTDWHS/dUj3H/OBtd7NNmwvEt6eVXIxZcqFSwtm1Yq+ljkyX 0aXvy/KKeMxvnnrMIfuSKeATz3tGa8t3E1Rm+3xbxl6vb1THZs49535bY9d7rwDn1qms53fN 2KP6Q8DFc4nCBf3tP8p2XavY+uHIishu+df7/edvP787TFVm+u2GOxzp4cq1Kl+VWIozEg21 mIuKEwGr8avvdgIAAA== Cc: Marc Petit-Huguenin , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Comments on ABNF in draft-petithuguenin-mmusic-ice-sip-sdp-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jan 2014 14:03:23 -0000 Hi Magnus, Good point. That ABNF indeed seems to be overly liberal on the extension at= tribute names and values. Perhaps e.g., token would be more appropriate at = least for the extension-att-name (like att-field in RFC4566).=20 For extension-att-value, are there any reasonable use cases where e.g., VCH= AR would not be sufficient? Are RFC4566 att-values with non-printable chara= cters used somewhere? Cheers, Ari On 22 Jan 2014, at 11:35, Magnus Westerlund wrote: > Hi, >=20 > As part of the RTSP for NAT work I actually noticed an issue with the > ABNF that is defined for ICE in SDP. >=20 > From Section 8.1: >=20 > candidate-attribute =3D "candidate" ":" foundation SP component-id SP > transport SP > priority SP > connection-address SP ;from RFC 4566 > port ;port from RFC 4566 > SP cand-type > [SP rel-addr] > [SP rel-port] > *(SP extension-att-name SP > extension-att-value) >=20 > foundation =3D 1*32ice-char > component-id =3D 1*5DIGIT > transport =3D "UDP" / transport-extension > transport-extension =3D token ; from RFC 3261 > priority =3D 1*10DIGIT > cand-type =3D "typ" SP candidate-types >=20 >=20 >=20 > Petit-Huguenin & KeranenExpires August 29, 2013 [Page 9] >=20 > Internet-Draft ICE SIP/SDP Usage February 2013 >=20 >=20 > candidate-types =3D "host" / "srflx" / "prflx" / "relay" / token > rel-addr =3D "raddr" SP connection-address > rel-port =3D "rport" SP port > extension-att-name =3D byte-string ;from RFC 4566 > extension-att-value =3D byte-string > ice-char =3D ALPHA / DIGIT / "+" / "/" >=20 > The issue is what is allowed in extension-att-name and > extension-att-value. They are listed here as byte-string. That is an > extremely wide allowance in what values to be included. >=20 > First of all it includes SP the character used for delimiting the > -att-name against the -att-value and the next set of name and value. I > can't see that one can allow that, and if one have values that includes > space, then they must be escaped. >=20 > Further I wonder if it wise to include the non-visible values from the > below 128 range of the byte. It might be okay, but some thought needs to > be put into this. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From ari.keranen@ericsson.com Fri Jan 24 06:19:48 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1AD1A0490 for ; Fri, 24 Jan 2014 06:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXWqTH0_-kCn for ; Fri, 24 Jan 2014 06:19:46 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9111A043F for ; Fri, 24 Jan 2014 06:19:46 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-42-52e271c9c38f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1C.8F.23809.9C172E25; Fri, 24 Jan 2014 14:59:37 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.205]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 14:59:36 +0100 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: "Pal Martinsen (palmarti)" Thread-Topic: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt Thread-Index: AQHPEFUWHwgZkvhvT0WDP3osgKTRnJqT55oA Date: Fri, 24 Jan 2014 13:59:36 +0000 Message-ID: References: <20131209121243.31704.62698.idtracker@ietfa.amsl.com> <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> <52D01911.8030804@ericsson.com> <647464EE-B8E0-47FA-A375-8C758046D854@cisco.com> In-Reply-To: <647464EE-B8E0-47FA-A375-8C758046D854@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje7JwkdBBrvblS2mLn/MYvH++koW ixO7tzE6MHtM+b2R1WPJkp9MAUxRXDYpqTmZZalF+nYJXBkH101iKuhnqZg1bz5zA+MS5i5G Tg4JAROJF5O3sEDYYhIX7q1n62Lk4hASOMQo8e3OZHYIZwmjxKLrH9hAqtgEHCVOPVzLCmKL CBhLNB85yg5iMwsESTzafAFsqrBAosSqtodsEDVJEudfnGOHsI0kTl18B1bDIqAqcfT6AUYQ m1fAXmLzghVQy04ySvw/9xNsAaeArcSMOcfBzmMEOu/7qTVMEMvEJW49mc8EcbaAxJI956He EZV4+fgfK4StJNG45AkrRL2BxPtz85khbGuJY/t6WCBsbYllC18zQxwhKHFy5hOWCYzis5Cs mIWkfRaS9llI2mchaV/AyLqKkT03MTMnvdxoEyMwwg5u+a26g/HOOZFDjNIcLErivB/eOgcJ CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGzec+W9jWgmp67ic2EV17nn7k3/M//azp9CDTH/ 83j88uKnva6/HXZnU8u9BbuaNzys/h2/5It577M5LX575l6psbrwfrUo1/Frl+yf7S+uFnuk Yn7lt+WnPavcZdyMXhwRmsGjvmzfpyPOh3muSTO8aZy58DPnjJBFn2R+vHjr1bK2pHHDJ6s7 SizFGYmGWsxFxYkAS3BD+X4CAAA= Cc: mmusic , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jan 2014 14:19:48 -0000 Hi, The way forward you proposed sounds good. Looking forward to the updated dr= aft. However, I didn=92t really understand how is the lack of coordination = and different promo algorithms an advantage? Cheers, Ari On 13 Jan 2014, at 13:46, Pal Martinsen (palmarti) wro= te: >>=20 >>=20 >> Also, if there is no coordination/signaling between the endpoints, what = are the odds they'd end up using the same promotion algorithm? >>=20 > Exactly, and that might be an advantage..=20 From adam@nostrum.com Fri Jan 24 07:59:51 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FDB1A001E for ; Fri, 24 Jan 2014 07:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d03gGJqKnE39 for ; Fri, 24 Jan 2014 07:59:49 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC97E1A0010 for ; Fri, 24 Jan 2014 07:59:49 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0OFxjHO074121 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 24 Jan 2014 09:59:45 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52E28DEB.1040100@nostrum.com> Date: Fri, 24 Jan 2014 09:59:39 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Magnus Westerlund , "Stach, Thomas" References: <52E178F6.70009@nostrum.com> <52E24090.1030608@ericsson.com> In-Reply-To: <52E24090.1030608@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jan 2014 15:59:51 -0000 On 1/24/14 04:29, Magnus Westerlund wrote: > My understanding for the reasoning behind this definition in the RFC is > due to that the events is supposed to be connected to the same time-line > as the audio. Thus it ended up using the same SSRC. To avoid timestamp > rate switching which we know has issues > (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/) > it was mandated to provide one PT for each rate negotiated for the audio > payload types. To make sure I understand what you're saying correctly: you are asserting that having four different clock rates for voice codecs requires us to use four different PTs for telephone-event if we're going to have them on the same SSRC. Is that correct? /a From magnus.westerlund@ericsson.com Mon Jan 27 00:47:34 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464A01A0148 for ; Mon, 27 Jan 2014 00:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nqjoJJ6dUfz for ; Mon, 27 Jan 2014 00:47:33 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0AE1A0111 for ; Mon, 27 Jan 2014 00:47:32 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-8d-52e61d219057 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 40.28.04249.12D16E25; Mon, 27 Jan 2014 09:47:29 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.2.347.0; Mon, 27 Jan 2014 09:47:28 +0100 Message-ID: <52E61D16.1080708@ericsson.com> Date: Mon, 27 Jan 2014 09:47:18 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adam Roach , "Stach, Thomas" References: <52E178F6.70009@nostrum.com> <52E24090.1030608@ericsson.com> <52E28DEB.1040100@nostrum.com> In-Reply-To: <52E28DEB.1040100@nostrum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvja6i7LMgg9bfuhZ7/i5it5i6/DGL xcmd25gdmD2WLPnJ5DFr5xMWj+09j1kCmKO4bFJSczLLUov07RK4Mh7NucRU0Mpb8WHGdLYG xutcXYycHBICJhL/1p1jh7DFJC7cW8/WxcjFISRwhFFizs9LUM5yRolpx1eAVfEKaEs0tHey gdgsAqoSX7ofsIDYbAIWEjd/NILFRQWCJW5NewBVLyhxcuYTsBoRAW+Jb4c6GLsYOTiYBdQl ri4OAgkLC9hJHP03iR1i1ypGia6bx8HmcALtWrRgHTtIvYSAuERPI1g9s4CmROv23+wQtrxE 89bZzCC2EMhpTR2sExiFZiHZPAtJyywkLQsYmVcxchSnFiflphsZbGIEBvDBLb8tdjBe/mtz iFGag0VJnPfjW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwrWq4UHdCbXsc28aTq0oyi 13tmP8m4vz/zpWCzuKJwWGxCfqPqtCCrL9knImXcpq4Nsz0Q1Rf6wLdSZUdMaf3iOftSH1Q5 8/yd+H6VibGRA9POlWXfWpdN7n2bZH/s+gRh7d8VflNuvr64xGJlyk/3uvU7H+XvN6pK+bz6 fcs52fnpujpPP7YqsRRnJBpqMRcVJwIAHZanCy4CAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 08:47:34 -0000 On 2014-01-24 16:59, Adam Roach wrote: > On 1/24/14 04:29, Magnus Westerlund wrote: >> My understanding for the reasoning behind this definition in the RFC is >> due to that the events is supposed to be connected to the same time-line >> as the audio. Thus it ended up using the same SSRC. To avoid timestamp >> rate switching which we know has issues >> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/) >> >> it was mandated to provide one PT for each rate negotiated for the audio >> payload types. > > To make sure I understand what you're saying correctly: you are > asserting that having four different clock rates for voice codecs > requires us to use four different PTs for telephone-event if we're going > to have them on the same SSRC. Is that correct? Yes! All to avoid the issue that with rate switching within an SSRC. This is both potential loss of time synchronization as well as degrading RTP timestamp based RTCP measurements. And the above draft (soon RFC) does require new implementations to change their SSRC when doing rate-switching. That clearly have signaling implications in the context of WebRTC. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 randell-ietf@jesup.org Mon Jan 27 00:48:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B271A016A for ; Mon, 27 Jan 2014 00:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjelSAfBei-R for ; Mon, 27 Jan 2014 00:48:26 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 05E5F1A0111 for ; Mon, 27 Jan 2014 00:48:26 -0800 (PST) Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:4883 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1W7hrj-000Bq7-5N for mmusic@ietf.org; Mon, 27 Jan 2014 02:48:23 -0600 Message-ID: <52E61D40.1020301@jesup.org> Date: Mon, 27 Jan 2014 03:48:00 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <52E178F6.70009@nostrum.com> <52E24090.1030608@ericsson.com> <52E28DEB.1040100@nostrum.com> In-Reply-To: <52E28DEB.1040100@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: randell@jesup.org X-OutGoing-Spam-Status: No, score=-6.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 08:48:27 -0000 On 1/24/2014 10:59 AM, Adam Roach wrote: > On 1/24/14 04:29, Magnus Westerlund wrote: >> My understanding for the reasoning behind this definition in the RFC is >> due to that the events is supposed to be connected to the same time-line >> as the audio. Thus it ended up using the same SSRC. To avoid timestamp >> rate switching which we know has issues >> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/) >> >> it was mandated to provide one PT for each rate negotiated for the audio >> payload types. > > To make sure I understand what you're saying correctly: you are > asserting that having four different clock rates for voice codecs > requires us to use four different PTs for telephone-event if we're > going to have them on the same SSRC. Is that correct? If those four PT's (not codecs) are accepted (and thus can be switched between on-the-fly), yes. Multiple clock rates plays hell with RTP timestamps. You could use a separate SSRC (or m=audio line) for each clock rate instead. This would likely mean glitching at transitions however, so not a great solution, but works. You might be able to avoid glitches by making sure you send RTCP for the alternate SSRCs so synchronization info is available, though this may require the receiver to know somehow that the SSRC's need to be "lip-synced" (in this case audio to audio though). Overall - here be (baby) dragons in the glitch-avoidance variation... In theory you could allow one telephone-event PT and do a renegotiate after an effective codec/PT change. You might need to be careful about asynchronicity due to the renegotiation and not re-use the same PT for a different rate of telephone-event (ping-pong between two). There would exist a window when there was a switch where it would be problematic to send telephone-event (and you'd need to require that both sides switch when one does). Overall - here be (big) dragons. -- Randell Jesup -- rjesup a t mozilla d o t com From christer.holmberg@ericsson.com Mon Jan 27 03:36:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAD11A01E8 for ; Mon, 27 Jan 2014 03:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZr3q40WuLbS for ; Mon, 27 Jan 2014 03:36:19 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5791A0130 for ; Mon, 27 Jan 2014 03:36:18 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-53-52e644afd412 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 75.74.04853.FA446E25; Mon, 27 Jan 2014 12:36:16 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Mon, 27 Jan 2014 12:36:15 +0100 From: Christer Holmberg To: mmusic Thread-Topic: Questions on draft-ietf-mmusic-sctp-sdp-05 Thread-Index: Ac8bUQl73YOfrjw4RXqWisjZiYMaaA== Date: Mon, 27 Jan 2014 11:36:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D13BB05@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D13BB05ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvje4Gl2dBBktOcFtMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGQeWdbEU/DKtuP5kO2MD4029LkZODgkBE4lpM66xQNhiEhfu rWfrYuTiEBI4wSixactuZpCEkMBiRon/34GKODjYBCwkuv9pg4RFBGQk9m7aDFYiDDSnd0cz G0TcUmLKvg/MIOUiAnoSv0/HgIRZBFQlfly8wgRi8wr4Sqx5+gusnBFo7fdTa8DizALiEree zGeCOEdAYsme88wQtqjEy8f/WCFsJYkfGy6xQNTnS+xfu5MFYqagxMmZT1gmMArNQjJqFpKy WUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypGyeLU4uLcdCMDvdz03BK91KLM5OLi /Dy94tRNjMC4OLjlt9EOxpN77A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAuEdT3e3c/0k/jdSW+cafC/5Yt7nyVWiJipVym9BOttV3Hyre5Eg+Ue/3w+fj2tVmx/uO 1nzYU9nwc81VrWsc9bzbNkYWBlwr2b1tl6yn1WQXk9zLTfEu+W8WqRQvq+rdeMOyxEnx8cRD 30VW8sbvX7Bx1rLM6IZDn9vO/ObUPbeG0/S4zU9hOyWW4oxEQy3mouJEAIGp7MlZAgAA Subject: [MMUSIC] Questions on draft-ietf-mmusic-sctp-sdp-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 11:36:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D13BB05ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 5.1 of draft-ietf-mmusic-sctp-sdp-05 describes how an offered SCTP = association can be rejected, by in the Answer setting the port value in the= associated SDP sctpmap attribute to zero. Q1: When an SCTP association is rejected, shall the associated port= value in the m- line fmt list also be set to zero? The text only talks abo= ut the sctpmap attribute. The draft does not talk about subsequent offers. Q2: Do I need to include all sctpmap attributes in subsequent offer= s, even if some are associated with previously rejected STCP associations, = in order to maintain the order? Q3: Can I, in a subsequent offer, remove an SCTP association by set= ting the associated port value to zero? If so, do I set the port value to z= ero in the associated sctpmap attribute, and/or the m- line fmt list? The draft only talks about having a single media-subtype per SCTP associati= on. Q4: Is it possible to define multiple media-subtypes per SCTP assoc= iation? Example: m=3Dapplication 54111 DTLS/SCTP 5000 c=3DIN IP4 79.97.215.79 a=3Dsctpmap:5000 webrtc-datachannel 16 a=3Dsctpmap:5000 bfcp 2 a=3Dsctpmap:5000 t38 1 (Each media-subtype could use different SCTP streams within= the SCTP association) Thanks! Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D13BB05ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 5.1 of draft-ietf-mmusic-sctp-sdp-05 describ= es how an offered SCTP association can be rejected, by in the Answer settin= g the port value in the associated SDP sctpmap attribute to zero.

 

Q1:       =   When an SCTP association is rejected, shall the associated port valu= e in the m- line fmt list also be set to zero? The text only talks about th= e sctpmap attribute.

 

The draft does not talk about subsequent offers.

 

Q2:       =   Do I need to include all sctpmap attributes in subsequent offers, ev= en if some are associated with previously rejected STCP associations, in or= der to maintain the order?

 

Q3:       =   Can I, in a subsequent offer, remove an SCTP association by setting = the associated port value to zero? If so, do I set the port value to zero i= n the associated sctpmap attribute, and/or the m- line fmt list?=

 

The draft only talks about having a single media-sub= type per SCTP association.

 

Q4:       =   Is it possible to define multiple media-subtypes per SCTP associatio= n?

 

        &nbs= p;       Example:

 

        &nbs= p;       m=3Dapplication 54111 DTLS/SCTP 5= 000

        &nbs= p;     c=3DIN IP4 79.97.215.79

        &nbs= p;     a=3Dsctpmap:5000 webrtc-datachannel 16

        &nbs= p;     a=3Dsctpmap:5000 bfcp 2

        &nbs= p;     a=3Dsctpmap:5000 t38 1

 

        &nbs= p;       (Each media-subtype could use differ= ent SCTP streams within the SCTP association)

 

 

Thanks!

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D13BB05ESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Jan 28 05:02:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FF11A03CB for ; Tue, 28 Jan 2014 05:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.66 X-Spam-Level: * X-Spam-Status: No, score=1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_15=0.6, MANGLED_RATES=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE9FV-wXBF2C for ; Tue, 28 Jan 2014 05:02:55 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 97E341A01EB for ; Tue, 28 Jan 2014 05:02:54 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-3b-52e7aa7a8282 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 39.40.04853.A7AA7E25; Tue, 28 Jan 2014 14:02:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Tue, 28 Jan 2014 14:02:50 +0100 From: Christer Holmberg To: Randell Jesup , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Telephone-event and multiple clock rates Thread-Index: AQHPGHg9LlpXnTtXk0SY+cajv/cG7ZqTZ5YAgAA1EQCAAFw3gIAEPmQAgAHpdsA= Date: Tue, 28 Jan 2014 13:02:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se> References: <52E178F6.70009@nostrum.com> <52E24090.1030608@ericsson.com> <52E28DEB.1040100@nostrum.com> <52E61D40.1020301@jesup.org> In-Reply-To: <52E61D40.1020301@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+JvjW71qudBBmu/M1tMXf6YxeLstiwH Jo8lS34yeXxYvo4tgCmKyyYlNSezLLVI3y6BK6NvegNzwRqxinv9k1gaGPuEuhg5OSQETCS2 fdjDDGGLSVy4t56ti5GLQ0jgBKPE1XU7WSGcxYwSy18tY+pi5OBgE7CQ6P6nDdIgIhAo0fv6 HTuILSxgJ3F1xwVmiLi9xJILT5ggbD+JjzePsIC0sgioSjz4zgIS5hXwlZj39yATxPizjBJd HXfB6jkFNCUmr3sLVsQIdND3U2vA4swC4hK3nsxngjhUQGLJnvNQR4tKvHz8jxXCVpS4On05 VL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMUoWpxYX56Yb GejlpueW6KUWZSYXF+fn6RWnbmIERsvBLb+NdjCe3GN/iFGag0VJnPc6a02QkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsaWjwrGe3iOzbH1LT39tfqEy89jZd+/t3/9s5dD7O7htQtP3qp1 0vj3OqspesfeyVob1uziPvnylZjqk0ssnQt4+Dz61r3zajh1RlYqX1ay5+G7CXPef6+Jjv/v dW2lea7Tbj7NH/u/XXS3UFYXvsFpsliEzZRF6Z5XkTHrxtY86+Vbt8z4No9RiaU4I9FQi7mo OBEAksuu+GQCAAA= Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 13:02:58 -0000 Hi, I guess it would be good to add some text to BUNDLE, to indicate that you m= ust include the telephone-event PTs for every m- line which may use them. I= .e. you cannot indicate telephone-event for one m- line, and then use them = on every m- line within the bundle group. But, I guess there will be no need for people to support telephone-events o= n more than one m- line to begin with, so... Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup Sent: 27. tammikuuta 2014 10:48 To: mmusic@ietf.org Subject: Re: [MMUSIC] Telephone-event and multiple clock rates On 1/24/2014 10:59 AM, Adam Roach wrote: > On 1/24/14 04:29, Magnus Westerlund wrote: >> My understanding for the reasoning behind this definition in the RFC=20 >> is due to that the events is supposed to be connected to the same=20 >> time-line as the audio. Thus it ended up using the same SSRC. To=20 >> avoid timestamp rate switching which we know has issues >> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra >> tes/) >> >> it was mandated to provide one PT for each rate negotiated for the=20 >> audio payload types. > > To make sure I understand what you're saying correctly: you are=20 > asserting that having four different clock rates for voice codecs=20 > requires us to use four different PTs for telephone-event if we're=20 > going to have them on the same SSRC. Is that correct? If those four PT's (not codecs) are accepted (and thus can be switched betw= een on-the-fly), yes. Multiple clock rates plays hell with RTP timestamps. You could use a separate SSRC (or m=3Daudio line) for each clock rate inste= ad. This would likely mean glitching at transitions however, so not a grea= t solution, but works. You might be able to avoid glitches by making sure = you send RTCP for the alternate SSRCs so synchronization info is available,= though this may require the receiver to know somehow that the SSRC's need = to be "lip-synced" (in this case audio to audio though). Overall - here be= (baby) dragons in the glitch-avoidance variation... In theory you could allow one telephone-event PT and do a renegotiate after= an effective codec/PT change. You might need to be careful about asynchro= nicity due to the renegotiation and not re-use the same PT for a different = rate of telephone-event (ping-pong between two). There would exist a windo= w when there was a switch where it would be problematic to send telephone-e= vent (and you'd need to require that both sides switch when one does). Over= all - here be (big) dragons. -- Randell Jesup -- rjesup a t mozilla d o t com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From palmarti@cisco.com Tue Jan 28 05:49:24 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605811A03E0 for ; Tue, 28 Jan 2014 05:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.736 X-Spam-Level: X-Spam-Status: No, score=-14.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lgsh7FI6rIBW for ; Tue, 28 Jan 2014 05:49:23 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E77111A03D9 for ; Tue, 28 Jan 2014 05:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1747; q=dns/txt; s=iport; t=1390916960; x=1392126560; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c/7BUTOxEDwovAXpUXeJYbgDRwLgztERcRpmgWIXoZM=; b=ihCgveXDgElwPEyDe7H3yTKibKWp9G/YRr+nksO/OUwXHtTRWJtKgSbj 8bN+RZVfKX+Pgl4lmuTu4XCSKG5Zm3FwUf8nbctRuAfaIcjABO1SIcksp kXx6hWy8yTfHHctFFv0nmypnFtyqlJEFz4dGgX3im6oMoFOcNHBmjKQ4F s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAC2051KtJXG+/2dsb2JhbABagww4UAa8V4EVFnSCJQEBAQMBDlcSAgULAgEIGC4yJQIEDgUJh3QICAXJWxeOTDMHgySBFASYKIEykG2Bb4E+gio X-IronPort-AV: E=Sophos;i="4.95,736,1384300800"; d="scan'208";a="297193678" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jan 2014 13:49:20 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0SDnKjX010133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 13:49:20 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 07:49:19 -0600 From: "Pal Martinsen (palmarti)" To: =?Windows-1252?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt Thread-Index: AQHPEFUUlb4N8W3Wl06M5kiJnPk5wZqUXPIAgAZGcwA= Date: Tue, 28 Jan 2014 13:49:19 +0000 Message-ID: <7C0E6D63-D816-4415-B621-73A0309C6AB2@cisco.com> References: <20131209121243.31704.62698.idtracker@ietfa.amsl.com> <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> <52D01911.8030804@ericsson.com> <647464EE-B8E0-47FA-A375-8C758046D854@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.88.248] Content-Type: text/plain; charset="Windows-1252" Content-ID: <64171E2117D0224B9DFDE4D4FB16F49C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 13:49:24 -0000 On 24 Jan 2014, at 14:59 pm, Ari Ker=E4nen wrote= : > Hi, >=20 > The way forward you proposed sounds good. Looking forward to the updated = draft. However, I didn=92t really understand how is the lack of coordinatio= n and different promo algorithms an advantage? My thought at the time was due to triggered checks it could in some cases b= e good to have uncoordinated checklists for IPv6 due to less NATs and other= restrictive =93things=94. But that is clearly a bad idea. Sorry for the de= railing.=20 Just posted -05 version of the draft.=20 Name: draft-reddy-mmusic-ice-happy-eyeballs Revision: 05 Title: Happy Eyeballs Extension for ICE Document date: 2014-01-28 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-reddy-mmusic-ice-= happy-eyeballs-05.txt Status: https://datatracker.ietf.org/doc/draft-reddy-mmusic-ice-hap= py-eyeballs/ Htmlized: http://tools.ietf.org/html/draft-reddy-mmusic-ice-happy-eye= balls-05 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-mmusic-ice-h= appy-eyeballs-05 Not sure if we hit the right balance between keeping it short, but still re= adable without having all the ICE details fresh in memory.=20 Do we ask for WG adoption, or do we need another MMUSIC session discussing = this? .-. P=E5l-Erik >=20 >=20 > Cheers, > Ari >=20 > On 13 Jan 2014, at 13:46, Pal Martinsen (palmarti) w= rote: >=20 >>>=20 >>>=20 >>> Also, if there is no coordination/signaling between the endpoints, what= are the odds they'd end up using the same promotion algorithm? >>>=20 >> Exactly, and that might be an advantage..=20 >=20 From pkyzivat@alum.mit.edu Tue Jan 28 08:32:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541141A03D6 for ; Tue, 28 Jan 2014 08:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.665 X-Spam-Level: * X-Spam-Status: No, score=1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, MANGLED_RATES=2.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWJqcSYaJaPr for ; Tue, 28 Jan 2014 08:32:05 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6041A03D0 for ; Tue, 28 Jan 2014 08:32:05 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id KS6Z1n0040mv7h053UY2GT; Tue, 28 Jan 2014 16:32:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id KUY21n01h3ZTu2S3XUY2VA; Tue, 28 Jan 2014 16:32:02 +0000 Message-ID: <52E7DB82.2080907@alum.mit.edu> Date: Tue, 28 Jan 2014 11:32:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <52E178F6.70009@nostrum.com> <52E24090.1030608@ericsson.com> <52E28DEB.1040100@nostrum.com> <52E61D40.1020301@jesup.org> <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390926722; bh=tvoEBWo8vJmOi9ZFsGwpUDibsc27IpunoqsfO3gSU6I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZKMiWdqzKj01z+cbxtfpYGGHmNIQSlw+ehflBQD3Q3Exd7vYbqUjiBAV92TF1ehrU 8Hq2Nb/27Me5anqf2sg/Yoxm5hRqZYiKy2S1wFWxfdsjb+OMjXuvZEsWf1lLq64m2L UPAEDf7f/Gj66bAPtix/VUuRtGfumVOUlQcy947R371UnrrvDScs4eM2Dyb/QtjCmD ut91Y7lMG2ASgaTCXwvpveuId0nsmWh8gS7SOUE85Jua8HIsFeJ2VxF18sQeCoxL78 erIoAuRT4gmpSSFYi34YBhq3W1nr248BrqGzciVfbuHBs2ExucwKbGEvQuymoSH64f 5HRUnnoX4qU2A== Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:32:07 -0000 On 1/28/14 8:02 AM, Christer Holmberg wrote: > Hi, > > I guess it would be good to add some text to BUNDLE, to indicate that you must include the telephone-event PTs for every m- line which may use them. I.e. you cannot indicate telephone-event for one m- line, and then use them on every m- line within the bundle group. > > But, I guess there will be no need for people to support telephone-events on more than one m- line to begin with, so... Why would you say that? Thanks, Paul > Regards, > > Christer > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup > Sent: 27. tammikuuta 2014 10:48 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > > On 1/24/2014 10:59 AM, Adam Roach wrote: >> On 1/24/14 04:29, Magnus Westerlund wrote: >>> My understanding for the reasoning behind this definition in the RFC >>> is due to that the events is supposed to be connected to the same >>> time-line as the audio. Thus it ended up using the same SSRC. To >>> avoid timestamp rate switching which we know has issues >>> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra >>> tes/) >>> >>> it was mandated to provide one PT for each rate negotiated for the >>> audio payload types. >> >> To make sure I understand what you're saying correctly: you are >> asserting that having four different clock rates for voice codecs >> requires us to use four different PTs for telephone-event if we're >> going to have them on the same SSRC. Is that correct? > > If those four PT's (not codecs) are accepted (and thus can be switched between on-the-fly), yes. Multiple clock rates plays hell with RTP timestamps. > > You could use a separate SSRC (or m=audio line) for each clock rate instead. This would likely mean glitching at transitions however, so not a great solution, but works. You might be able to avoid glitches by making sure you send RTCP for the alternate SSRCs so synchronization info is available, though this may require the receiver to know somehow that the SSRC's need to be "lip-synced" (in this case audio to audio though). Overall - here be (baby) dragons in the glitch-avoidance variation... > > In theory you could allow one telephone-event PT and do a renegotiate after an effective codec/PT change. You might need to be careful about asynchronicity due to the renegotiation and not re-use the same PT for a different rate of telephone-event (ping-pong between two). There would exist a window when there was a switch where it would be problematic to send telephone-event (and you'd need to require that both sides switch when one does). Overall - here be (big) dragons. > > -- > Randell Jesup -- rjesup a t mozilla d o t com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Tue Jan 28 10:25:23 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9ED41A02E9 for ; Tue, 28 Jan 2014 10:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, MANGLED_RATES=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6orWDeHzYgkH for ; Tue, 28 Jan 2014 10:25:22 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B68151A02B2 for ; Tue, 28 Jan 2014 10:25:21 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-89-52e7f60e3708 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CA.69.23809.E06F7E25; Tue, 28 Jan 2014 19:25:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Tue, 28 Jan 2014 19:25:17 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Telephone-event and multiple clock rates Thread-Index: AQHPGHg9LlpXnTtXk0SY+cajv/cG7ZqTZ5YAgAA1EQCAAFw3gIAEPmQAgAHpdsCAACqFAIAAMGjo Date: Tue, 28 Jan 2014 18:25:17 +0000 Message-ID: <9dt0s2vbp3f9xidieks341ev.1390933514153@email.android.com> References: <52E178F6.70009@nostrum.com> <52E24090.1030608@ericsson.com> <52E28DEB.1040100@nostrum.com> <52E61D40.1020301@jesup.org> <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se>, <52E7DB82.2080907@alum.mit.edu> In-Reply-To: <52E7DB82.2080907@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+JvjS7ft+dBBh1/pC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj84OwgmkyFQcWrWRpYLwp1sXIySEhYCLR OusYE4QtJnHh3no2EFtI4BCjREerXRcjF5C9mFFic9tFoAQHB5uAhUT3P22QGhEBX4lnj2+D 1QsL2Ekc/TeJHSJuL7HkwhMmCDtKYvKsdWA1LAKqEleW3gWL8wq4SUxfd4QVYv5GJonGJ1dY QRKcAjoSN6/tAxvECHTQ91NrwBqYBcQlbj2ZD3WogMSSPeeZIWxRiZeP/7FC1OhILNj9iQ3C 1pZYtvA1M8QyQYmTM5+wTGAUmYVk1CwkLbOQtMxC0rKAkWUVI3tuYmZOernRJkZgwB/c8lt1 B+OdcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBjwtCfQc3OA9fv+ e8o64q+EFsxfuJP1TfZ5F1PGHU7s09evuCV0bP6upqNdp38+6k/K4OQ9OefzsgcaClkREQbx 9lPfXg9/4xR7VrHzkUnQ6olNPj89Xrer823fkzwraWOomn/fhPlqM39dXLHi5oUnfTszzL7z X/GQPvH4ach+F+eHk3akhF9VYinOSDTUYi4qTgQAR8FTBkYCAAA= Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 18:25:23 -0000 Hi Paul, I can't think of a use-case with multiple audio m- lines, where each would = need to support telephone-events. Perhaps such use-cases do exist, but I don't they are very common. Regards, Christer Sent from my Sony Ericsson Xperia arc S Paul Kyzivat wrote: On 1/28/14 8:02 AM, Christer Holmberg wrote: > Hi, > > I guess it would be good to add some text to BUNDLE, to indicate that you= must include the telephone-event PTs for every m- line which may use them.= I.e. you cannot indicate telephone-event for one m- line, and then use the= m on every m- line within the bundle group. > > But, I guess there will be no need for people to support telephone-events= on more than one m- line to begin with, so... Why would you say that? Thanks, Paul > Regards, > > Christer > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup > Sent: 27. tammikuuta 2014 10:48 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > > On 1/24/2014 10:59 AM, Adam Roach wrote: >> On 1/24/14 04:29, Magnus Westerlund wrote: >>> My understanding for the reasoning behind this definition in the RFC >>> is due to that the events is supposed to be connected to the same >>> time-line as the audio. Thus it ended up using the same SSRC. To >>> avoid timestamp rate switching which we know has issues >>> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra >>> tes/) >>> >>> it was mandated to provide one PT for each rate negotiated for the >>> audio payload types. >> >> To make sure I understand what you're saying correctly: you are >> asserting that having four different clock rates for voice codecs >> requires us to use four different PTs for telephone-event if we're >> going to have them on the same SSRC. Is that correct? > > If those four PT's (not codecs) are accepted (and thus can be switched be= tween on-the-fly), yes. Multiple clock rates plays hell with RTP timestamp= s. > > You could use a separate SSRC (or m=3Daudio line) for each clock rate ins= tead. This would likely mean glitching at transitions however, so not a gr= eat solution, but works. You might be able to avoid glitches by making sur= e you send RTCP for the alternate SSRCs so synchronization info is availabl= e, though this may require the receiver to know somehow that the SSRC's nee= d to be "lip-synced" (in this case audio to audio though). Overall - here = be (baby) dragons in the glitch-avoidance variation... > > In theory you could allow one telephone-event PT and do a renegotiate aft= er an effective codec/PT change. You might need to be careful about asynch= ronicity due to the renegotiation and not re-use the same PT for a differen= t rate of telephone-event (ping-pong between two). There would exist a win= dow when there was a switch where it would be problematic to send telephone= -event (and you'd need to require that both sides switch when one does). Ov= erall - here be (big) dragons. > > -- > Randell Jesup -- rjesup a t mozilla d o t com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Tue Jan 28 11:21:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279821A026C for ; Tue, 28 Jan 2014 11:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.535 X-Spam-Level: X-Spam-Status: No, score=-4.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, MANGLED_RATES=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZCSzsY3HIBo for ; Tue, 28 Jan 2014 11:20:56 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1602F1A0355 for ; Tue, 28 Jan 2014 11:20:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 141C839E12B for ; Tue, 28 Jan 2014 20:20:53 +0100 (CET) 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 YV8SsproOyQc for ; Tue, 28 Jan 2014 20:20:52 +0100 (CET) Received: from [IPv6:2620:0:1000:167d:c550:9ce2:4855:2d11] (unknown [IPv6:2620:0:1000:167d:c550:9ce2:4855:2d11]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6ED5039E127 for ; Tue, 28 Jan 2014 20:20:51 +0100 (CET) Message-ID: <52E7F08A.6070200@alvestrand.no> Date: Tue, 28 Jan 2014 19:01:46 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <52E178F6.70009@nostrum.com> <52E24090.1030608@ericsson.com> <52E28DEB.1040100@nostrum.com> <52E61D40.1020301@jesup.org> <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:21:04 -0000 On 01/28/2014 02:02 PM, Christer Holmberg wrote: > Hi, > > I guess it would be good to add some text to BUNDLE, to indicate that you must include the telephone-event PTs for every m- line which may use them. I.e. you cannot indicate telephone-event for one m- line, and then use them on every m- line within the bundle group. > > But, I guess there will be no need for people to support telephone-events on more than one m- line to begin with, so... Telephone-events are a hack for gateways into contexts where DTMF signalling makes sense - which is primarily the telephone network and telephone-related systems. In practice, I don't expect gateways into those contexts to support very many clock rates - they should support G.711's 8000 and Opus' 48K, and hopefully that's the end of it. I don't want to worry very much about two extra lines of SDP; let's just declare (probably in -rtcweb-audio-) that if multiple audio codec bitrates are offered, and one wishes to use DTMF no matter what codec is selected, one must offer DTMF at each clock rate offered - each offer consuming one PT. > > Regards, > > Christer > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup > Sent: 27. tammikuuta 2014 10:48 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > > On 1/24/2014 10:59 AM, Adam Roach wrote: >> On 1/24/14 04:29, Magnus Westerlund wrote: >>> My understanding for the reasoning behind this definition in the RFC >>> is due to that the events is supposed to be connected to the same >>> time-line as the audio. Thus it ended up using the same SSRC. To >>> avoid timestamp rate switching which we know has issues >>> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra >>> tes/) >>> >>> it was mandated to provide one PT for each rate negotiated for the >>> audio payload types. >> To make sure I understand what you're saying correctly: you are >> asserting that having four different clock rates for voice codecs >> requires us to use four different PTs for telephone-event if we're >> going to have them on the same SSRC. Is that correct? > If those four PT's (not codecs) are accepted (and thus can be switched between on-the-fly), yes. Multiple clock rates plays hell with RTP timestamps. > > You could use a separate SSRC (or m=audio line) for each clock rate instead. This would likely mean glitching at transitions however, so not a great solution, but works. You might be able to avoid glitches by making sure you send RTCP for the alternate SSRCs so synchronization info is available, though this may require the receiver to know somehow that the SSRC's need to be "lip-synced" (in this case audio to audio though). Overall - here be (baby) dragons in the glitch-avoidance variation... > > In theory you could allow one telephone-event PT and do a renegotiate after an effective codec/PT change. You might need to be careful about asynchronicity due to the renegotiation and not re-use the same PT for a different rate of telephone-event (ping-pong between two). There would exist a window when there was a switch where it would be problematic to send telephone-event (and you'd need to require that both sides switch when one does). Overall - here be (big) dragons. > > -- > Randell Jesup -- rjesup a t mozilla d o t com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Surveillance is pervasive. Go Dark. From keith.drage@alcatel-lucent.com Tue Jan 28 12:19:56 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890C91A02F1 for ; Tue, 28 Jan 2014 12:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs0bPVg1rMrU for ; Tue, 28 Jan 2014 12:19:53 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id B03681A0245 for ; Tue, 28 Jan 2014 12:19:53 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s0SKJlBi022656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jan 2014 14:19:48 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s0SKJivp003431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 21:19:46 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 28 Jan 2014 21:19:44 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Randell Jesup , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Telephone-event and multiple clock rates Thread-Index: AQHPGHg9LlpXnTtXk0SY+cajv/cG7ZqTZ5YAgAA1EQCAAFw3gIAEPmQAgAHpdsCAAHaq8A== Date: Tue, 28 Jan 2014 20:19:44 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1246AC@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <52E178F6.70009@nostrum.com> <52E24090.1030608@ericsson.com> <52E28DEB.1040100@nostrum.com> <52E61D40.1020301@jesup.org> <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:19:56 -0000 Well I could postulate a webrtc endpoint forming the collection endpoint fo= r a telephone voting system. Keith=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Christer Holmberg > Sent: 28 January 2014 13:03 > To: Randell Jesup; mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates >=20 > Hi, >=20 > I guess it would be good to add some text to BUNDLE, to=20 > indicate that you must include the telephone-event PTs for=20 > every m- line which may use them. I.e. you cannot indicate=20 > telephone-event for one m- line, and then use them on every=20 > m- line within the bundle group. >=20 > But, I guess there will be no need for people to support=20 > telephone-events on more than one m- line to begin with, so... >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Randell Jesup > Sent: 27. tammikuuta 2014 10:48 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates >=20 > On 1/24/2014 10:59 AM, Adam Roach wrote: > > On 1/24/14 04:29, Magnus Westerlund wrote: > >> My understanding for the reasoning behind this definition=20 > in the RFC=20 > >> is due to that the events is supposed to be connected to the same=20 > >> time-line as the audio. Thus it ended up using the same SSRC. To=20 > >> avoid timestamp rate switching which we know has issues=20 > >>=20 > (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra > >> tes/) > >> > >> it was mandated to provide one PT for each rate negotiated for the=20 > >> audio payload types. > > > > To make sure I understand what you're saying correctly: you are=20 > > asserting that having four different clock rates for voice codecs=20 > > requires us to use four different PTs for telephone-event if we're=20 > > going to have them on the same SSRC. Is that correct? >=20 > If those four PT's (not codecs) are accepted (and thus can be=20 > switched between on-the-fly), yes. Multiple clock rates=20 > plays hell with RTP timestamps. >=20 > You could use a separate SSRC (or m=3Daudio line) for each=20 > clock rate instead. This would likely mean glitching at=20 > transitions however, so not a great solution, but works. You=20 > might be able to avoid glitches by making sure you send RTCP=20 > for the alternate SSRCs so synchronization info is available,=20 > though this may require the receiver to know somehow that the=20 > SSRC's need to be "lip-synced" (in this case audio to audio=20 > though). Overall - here be (baby) dragons in the=20 > glitch-avoidance variation... >=20 > In theory you could allow one telephone-event PT and do a=20 > renegotiate after an effective codec/PT change. You might=20 > need to be careful about asynchronicity due to the=20 > renegotiation and not re-use the same PT for a different rate=20 > of telephone-event (ping-pong between two). There would=20 > exist a window when there was a switch where it would be=20 > problematic to send telephone-event (and you'd need to=20 > require that both sides switch when one does). Overall - here=20 > be (big) dragons. >=20 > -- > Randell Jesup -- rjesup a t mozilla d o t com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From christer.holmberg@ericsson.com Tue Jan 28 22:53:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727241A0373 for ; Tue, 28 Jan 2014 22:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KljANeko2WNL for ; Tue, 28 Jan 2014 22:53:53 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 56A591A036C for ; Tue, 28 Jan 2014 22:53:53 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-bb-52e8a57d15f4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 68.70.04249.D75A8E25; Wed, 29 Jan 2014 07:53:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Wed, 29 Jan 2014 07:53:49 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Randell Jesup , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Telephone-event and multiple clock rates Thread-Index: AQHPGHg9LlpXnTtXk0SY+cajv/cG7ZqTZ5YAgAA1EQCAAFw3gIAEPmQAgAHpdsCAAHaq8IAAtLjQ Date: Wed, 29 Jan 2014 06:53:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D148ACD@ESESSMB209.ericsson.se> References: <52E178F6.70009@nostrum.com> <52E24090.1030608@ericsson.com> <52E28DEB.1040100@nostrum.com> <52E61D40.1020301@jesup.org> <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B1246AC@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1246AC@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjW7d0hdBBvumslk8bTzLaDF1+WMW i7PbshyYPVqf7WX1WLLkJ5PHh+Xr2AKYo7hsUlJzMstSi/TtErgy9j1bzlzQL1uxY+UK5gbG s+JdjBwcEgImEnfXx3YxcgKZYhIX7q1n62Lk4hASOMIo8WvZd0YIZzGjxPR9/1hBGtgELCS6 /2mDxEUEuhglGntPsIN0CwvYSVzdcYEZxBYRsJdYcuEJE0i9iECUxNqjuSBhFgFViRc3n7OA 2LwCvhJtT+dCLXvEJLH1zgQ2kASnQLTElZ8PwOYwAl30/dQaJhCbWUBc4taT+UwQlwpILNlz nhnCFpV4+RjkNhBbUaL9aQMjRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jIL ScssJC0LGFlWMXIUpxYn5aYbGWxiBMbHwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2M19bfEzLf+av/O1vpOYsPv95dnbIldkJ38hMxzS1zA3X+P1l7 TKXNPXhqkkN8o75J2afEH1lPNsTnXk4Xf9GaXL7jxLQ7yaYs9+q5on9dt9+2oFdm578uzY9x zDu9Gi0Unm+czvdwjlJ7pl7H9Y2sK4/e0SlQbreq33dAX1MrfOmRky435a0KlFiKMxINtZiL ihMBjRFF0F0CAAA= Subject: Re: [MMUSIC] Telephone-event and multiple clock rates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 06:53:55 -0000 > Well I could postulate a webrtc endpoint forming the collection endpoint = for a telephone voting system. Sure, if you are going to represent every new incoming "vote call" by addin= g an audio m- line to a single ongoing session. Regards, Christer > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer=20 > Holmberg > Sent: 28 January 2014 13:03 > To: Randell Jesup; mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates >=20 > Hi, >=20 > I guess it would be good to add some text to BUNDLE, to indicate that=20 > you must include the telephone-event PTs for every m- line which may=20 > use them. I.e. you cannot indicate telephone-event for one m- line,=20 > and then use them on every > m- line within the bundle group. >=20 > But, I guess there will be no need for people to support=20 > telephone-events on more than one m- line to begin with, so... >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell=20 > Jesup > Sent: 27. tammikuuta 2014 10:48 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates >=20 > On 1/24/2014 10:59 AM, Adam Roach wrote: > > On 1/24/14 04:29, Magnus Westerlund wrote: > >> My understanding for the reasoning behind this definition > in the RFC > >> is due to that the events is supposed to be connected to the same=20 > >> time-line as the audio. Thus it ended up using the same SSRC. To=20 > >> avoid timestamp rate switching which we know has issues > >>=20 > (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra > >> tes/) > >> > >> it was mandated to provide one PT for each rate negotiated for the=20 > >> audio payload types. > > > > To make sure I understand what you're saying correctly: you are=20 > > asserting that having four different clock rates for voice codecs=20 > > requires us to use four different PTs for telephone-event if we're=20 > > going to have them on the same SSRC. Is that correct? >=20 > If those four PT's (not codecs) are accepted (and thus can be switched=20 > between on-the-fly), yes. Multiple clock rates plays hell with RTP=20 > timestamps. >=20 > You could use a separate SSRC (or m=3Daudio line) for each clock rate=20 > instead. This would likely mean glitching at transitions however, so=20 > not a great solution, but works. You might be able to avoid glitches=20 > by making sure you send RTCP for the alternate SSRCs so=20 > synchronization info is available, though this may require the=20 > receiver to know somehow that the SSRC's need to be "lip-synced" (in=20 > this case audio to audio though). Overall - here be (baby) dragons in=20 > the glitch-avoidance variation... >=20 > In theory you could allow one telephone-event PT and do a renegotiate=20 > after an effective codec/PT change. You might need to be careful=20 > about asynchronicity due to the renegotiation and not re-use the same=20 > PT for a different rate of telephone-event (ping-pong between two). =20 > There would exist a window when there was a switch where it would be=20 > problematic to send telephone-event (and you'd need to require that=20 > both sides switch when one does). Overall - here be (big) dragons. >=20 > -- > Randell Jesup -- rjesup a t mozilla d o t com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 From christer.holmberg@ericsson.com Wed Jan 29 01:58:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D3C1A04DA for ; Wed, 29 Jan 2014 01:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56yTXIx-XhB5 for ; Wed, 29 Jan 2014 01:58:14 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9A21A037D for ; Wed, 29 Jan 2014 01:58:14 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-1d-52e8d0b2f224 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E5.C8.10875.2B0D8E25; Wed, 29 Jan 2014 10:58:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Wed, 29 Jan 2014 10:58:10 +0100 From: Christer Holmberg To: "Gonzalo Salgueiro (gsalguei)" , "Adam Gensler (agensler)" Thread-Topic: Review of draft-ietf-mmusic-udptl-dtls-03 Thread-Index: AQHPF6Z7X1rBlQF7JUm0AYYGqOYxvZqRgxMAgAn+m0A= Date: Wed, 29 Jan 2014 09:58:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D148F76@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje7mCy+CDB6FWCz9fofNYu4UP4up yx+zODB7TPm9kdVjyZKfTAFMUVw2Kak5mWWpRfp2CVwZ/X8amQq2yVWcvtHG2sC4XaKLkYND QsBE4tLnkC5GTiBTTOLCvfVsXYxcHEIChxglVr99ygrhLGaUmL9gFRtIA5uAhUT3P22QBhGB TInP05azg9jMAjISM842MoHYwgJmEufunmeDqDGXaJ56lxGkVUTASuLC0SyQMIuAqsS2+T9Z QWxeAV+JRWsmgLUKCSRK9Kw6yAJicwrYSpz/fAxsPCPQbd9PrWGCWCUucevJfCaImwUkluw5 zwxhi0q8fPyPFcJWkvix4RILRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMbLnJmbmpJcbbmIERsnBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYwuOVk+8bfMp58pssrL53qkI1G98ujH2aG8PQu4+PJc7z9+ppPe yaN27gHvto4fxd92ljtXOB89NU9xU/ELXZ2J5r+4tPY9re7dtEZqB/vq4Abdm0K7qywvNe5x ieX6YWlu+jX4/aY2ibmlLk+Wq368fKjz2d9DTGnifXLc7YXXHm34537d9IcSS3FGoqEWc1Fx IgDrn07/YAIAAA== Cc: mmusic Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 09:58:16 -0000 Hi Adam, Again, thanks for your review! See my comments inline. > After speaking with Gonzalo I've reviewed draft-ietf-mmusic-udptl-dtls-03= . > Overall this draft is excellent and appears to cover all the corner=20 > cases I could think of. I do have a few comments, see below: >=20 > 1. In section 3.1, secure channel establishment, there is the=20 > following text: >=20 > "If the endpoint supports, and is willing to use, a cipher suite with=20 > an associated certificate, it MUST include an SDP fingerprint=20 > attribute [RFC4572 ] in the SDP." >=20 > "If a cipher suite with an associated certificate is selected during=20 > the DTLS handshake, the certificate received during the DTLS handshake=20 > MUST match the fingerprint received in the SDP fingerprint attribute." >=20 > To me this seems to indicate the particular cipher suites are=20 > associated with a particular certificate. While it's true that the=20 > certificate plays a role in overall TLS negotiation, it does not=20 > provide a list of ciphers to use. The intention of the text is NOT to indicate that a particular cipher suite= s are associated with a particular certificate.=20 > I think what this is saying is that > if the client wishes to use a certificate for DTLS it should provide a=20 > certificate fingerprint. Is that right? Only if the cipher suite has an associated certificate. But, e.g. a PSK based cipher suite (RFC4279) has no associated certificate= and thus there is no point of indicating certificate fingerprint for PSK b= ased cipher suite. > Given the overall complexity of PKI in general I think being extra clear = here would help avoid any confusion. We did spend quite a bit of time on this part of the text, and I can't see = what modifications I should do in order to make it more clear. ------------------------ > 2. Section 4.1 describes handling anonymous faxes with freshly=20 > generated self-signed certificates. It goes on to say: >=20 > "...and the content of the subjectAltName attribute inside the=20 > certificate MUST NOT contain information that either allows=20 > correlation or identification of the user making anonymous calls." >=20 > While the subjectAltName could potentially have identifiable data in=20 > it, it is not always present as a field within the certificate. Some=20 > certificates may have a subjectAltName, some may not. However, all=20 > certificates should have a commonName. I think that is the item that=20 > should be specifically called out as a place to avoid identifiable=20 > information. Or, perhaps, simply stipulating that no fields within the=20 > certificate should contain identifiable information. That's a good point. What about something like: "...and attributes inside the certificate SHALL NOT contain= information that either allows correlation or identification of the user making anonymous calls. This is = particularly important for the subjectAltName=20 and commonName attributes" ------------------------ > 3. Section 4.3 describes rekeying a connection that is established.=20 > The DTLS RFC describes how to handle this, but gives two options to an=20 > endpoint where out-of-order packets are received that have been=20 > encrypted with different keys; discard the packet, or, retain two sets=20 > of keying material for some recommended interval. DTLS is not specific=20 > as to what to do here. Section 4.3 says the receiver SHOULD maintain=20 > the keying material. Given the nature of T.38, I think it may be=20 > prudent to say the receiver MUST maintain the keying material. > Dropping and/or discarding > T.38 packets would never be my preference. We can change it to MUST. ------------------------ Regards, Christer From sumanth.suryanarayan@gmail.com Wed Jan 29 04:53:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBB01A0375 for ; Wed, 29 Jan 2014 04:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.501 X-Spam-Level: * X-Spam-Status: No, score=1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, MANGLED_RATES=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCyuUaFPJlXR for ; Wed, 29 Jan 2014 04:52:58 -0800 (PST) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6511A01F2 for ; Wed, 29 Jan 2014 04:52:57 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id e53so879522eek.11 for ; Wed, 29 Jan 2014 04:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=b1ZILbNbk8c/ofPYjFxDh6SrzoCdsgqFmtJnbbzVaOI=; b=E9aU9wlIsrTbycmPoP2lHbyDyXI58Yinp1j7Piva2SQa1usU2RSTLJiyhcKi++bkQp dROFzSaB9ODgKk5JQ6+ft7qcweFzGzn40aoqmaBkKkCdZN0ibpjBtQXuOzH7dMTT7vf6 vjb3wqC3hDRmvsh+H79AjyAftMVOqAlksWOy8b6gBIOHwXnGv8q54nTrBW/N9FB0D/DS LZmL4ZYkwbYKMBbOhjKSLtM7po3FmLuAkNbE9L6YGgB09wtW2y4AZY+TLK7mTICeXFtb YLLLuCOC5lYqZrKzIFXgrxtTRuwybQJQjc3J8n/pSSc+0ESkW5lWFZCakY40BD5oATSH leag== MIME-Version: 1.0 X-Received: by 10.15.21.2 with SMTP id c2mr2448119eeu.77.1390999974658; Wed, 29 Jan 2014 04:52:54 -0800 (PST) Received: by 10.14.177.69 with HTTP; Wed, 29 Jan 2014 04:52:54 -0800 (PST) Received: by 10.14.177.69 with HTTP; Wed, 29 Jan 2014 04:52:54 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 18:22:54 +0530 Message-ID: From: Sumanth Suryanarayan To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=089e0160d2b85f48d004f11b6bfe Subject: Re: [MMUSIC] mmusic Digest, Vol 117, Issue 19 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 12:53:03 -0000 --089e0160d2b85f48d004f11b6bfe Content-Type: text/plain; charset=ISO-8859-1 Cool dude. BTW, how much sqft does wardrobe come to? On Jan 29, 2014 12:51 AM, wrote: > Send mmusic mailing list submissions to > mmusic@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/mmusic > or, via email, send a message with subject or body 'help' to > mmusic-request@ietf.org > > You can reach the person managing the list at > mmusic-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mmusic digest..." > > > Today's Topics: > > 1. Re: Telephone-event and multiple clock rates (Christer Holmberg) > 2. Re: New Version Notification for > draft-reddy-mmusic-ice-happy-eyeballs-04.txt > (Pal Martinsen (palmarti)) > 3. Re: Telephone-event and multiple clock rates (Paul Kyzivat) > 4. Re: Telephone-event and multiple clock rates (Christer Holmberg) > 5. Re: Telephone-event and multiple clock rates (Harald Alvestrand) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jan 2014 13:02:50 +0000 > From: Christer Holmberg > To: Randell Jesup , "mmusic@ietf.org" > > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > Message-ID: > <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > I guess it would be good to add some text to BUNDLE, to indicate that you > must include the telephone-event PTs for every m- line which may use them. > I.e. you cannot indicate telephone-event for one m- line, and then use them > on every m- line within the bundle group. > > But, I guess there will be no need for people to support telephone-events > on more than one m- line to begin with, so... > > Regards, > > Christer > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup > Sent: 27. tammikuuta 2014 10:48 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > > On 1/24/2014 10:59 AM, Adam Roach wrote: > > On 1/24/14 04:29, Magnus Westerlund wrote: > >> My understanding for the reasoning behind this definition in the RFC > >> is due to that the events is supposed to be connected to the same > >> time-line as the audio. Thus it ended up using the same SSRC. To > >> avoid timestamp rate switching which we know has issues > >> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra > >> tes/) > >> > >> it was mandated to provide one PT for each rate negotiated for the > >> audio payload types. > > > > To make sure I understand what you're saying correctly: you are > > asserting that having four different clock rates for voice codecs > > requires us to use four different PTs for telephone-event if we're > > going to have them on the same SSRC. Is that correct? > > If those four PT's (not codecs) are accepted (and thus can be switched > between on-the-fly), yes. Multiple clock rates plays hell with RTP > timestamps. > > You could use a separate SSRC (or m=audio line) for each clock rate > instead. This would likely mean glitching at transitions however, so not a > great solution, but works. You might be able to avoid glitches by making > sure you send RTCP for the alternate SSRCs so synchronization info is > available, though this may require the receiver to know somehow that the > SSRC's need to be "lip-synced" (in this case audio to audio though). > Overall - here be (baby) dragons in the glitch-avoidance variation... > > In theory you could allow one telephone-event PT and do a renegotiate > after an effective codec/PT change. You might need to be careful about > asynchronicity due to the renegotiation and not re-use the same PT for a > different rate of telephone-event (ping-pong between two). There would > exist a window when there was a switch where it would be problematic to > send telephone-event (and you'd need to require that both sides switch when > one does). Overall - here be (big) dragons. > > -- > Randell Jesup -- rjesup a t mozilla d o t com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > ------------------------------ > > Message: 2 > Date: Tue, 28 Jan 2014 13:49:19 +0000 > From: "Pal Martinsen (palmarti)" > To: Ari Ker?nen > Cc: mmusic , "Tirumaleswar Reddy \(tireddy\)" > > Subject: Re: [MMUSIC] New Version Notification for > draft-reddy-mmusic-ice-happy-eyeballs-04.txt > Message-ID: <7C0E6D63-D816-4415-B621-73A0309C6AB2@cisco.com> > Content-Type: text/plain; charset="Windows-1252" > > > On 24 Jan 2014, at 14:59 pm, Ari Ker?nen wrote: > > > Hi, > > > > The way forward you proposed sounds good. Looking forward to the updated > draft. However, I didn?t really understand how is the lack of coordination > and different promo algorithms an advantage? > > My thought at the time was due to triggered checks it could in some cases > be good to have uncoordinated checklists for IPv6 due to less NATs and > other restrictive ?things?. But that is clearly a bad idea. Sorry for the > derailing. > > Just posted -05 version of the draft. > > Name: draft-reddy-mmusic-ice-happy-eyeballs > Revision: 05 > Title: Happy Eyeballs Extension for ICE > Document date: 2014-01-28 > Group: Individual Submission > Pages: 5 > URL: > http://www.ietf.org/internet-drafts/draft-reddy-mmusic-ice-happy-eyeballs-05.txt > Status: > https://datatracker.ietf.org/doc/draft-reddy-mmusic-ice-happy-eyeballs/ > Htmlized: > http://tools.ietf.org/html/draft-reddy-mmusic-ice-happy-eyeballs-05 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-reddy-mmusic-ice-happy-eyeballs-05 > > > Not sure if we hit the right balance between keeping it short, but still > readable without having all the ICE details fresh in memory. > > Do we ask for WG adoption, or do we need another MMUSIC session discussing > this? > > .-. > P?l-Erik > > > > > > > Cheers, > > Ari > > > > On 13 Jan 2014, at 13:46, Pal Martinsen (palmarti) > wrote: > > > >>> > >>> > >>> Also, if there is no coordination/signaling between the endpoints, > what are the odds they'd end up using the same promotion algorithm? > >>> > >> Exactly, and that might be an advantage.. > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 28 Jan 2014 11:32:02 -0500 > From: Paul Kyzivat > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > Message-ID: <52E7DB82.2080907@alum.mit.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 1/28/14 8:02 AM, Christer Holmberg wrote: > > Hi, > > > > I guess it would be good to add some text to BUNDLE, to indicate that > you must include the telephone-event PTs for every m- line which may use > them. I.e. you cannot indicate telephone-event for one m- line, and then > use them on every m- line within the bundle group. > > > > But, I guess there will be no need for people to support > telephone-events on more than one m- line to begin with, so... > > Why would you say that? > > Thanks, > Paul > > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup > > Sent: 27. tammikuuta 2014 10:48 > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > > > > On 1/24/2014 10:59 AM, Adam Roach wrote: > >> On 1/24/14 04:29, Magnus Westerlund wrote: > >>> My understanding for the reasoning behind this definition in the RFC > >>> is due to that the events is supposed to be connected to the same > >>> time-line as the audio. Thus it ended up using the same SSRC. To > >>> avoid timestamp rate switching which we know has issues > >>> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra > >>> tes/) > >>> > >>> it was mandated to provide one PT for each rate negotiated for the > >>> audio payload types. > >> > >> To make sure I understand what you're saying correctly: you are > >> asserting that having four different clock rates for voice codecs > >> requires us to use four different PTs for telephone-event if we're > >> going to have them on the same SSRC. Is that correct? > > > > If those four PT's (not codecs) are accepted (and thus can be switched > between on-the-fly), yes. Multiple clock rates plays hell with RTP > timestamps. > > > > You could use a separate SSRC (or m=audio line) for each clock rate > instead. This would likely mean glitching at transitions however, so not a > great solution, but works. You might be able to avoid glitches by making > sure you send RTCP for the alternate SSRCs so synchronization info is > available, though this may require the receiver to know somehow that the > SSRC's need to be "lip-synced" (in this case audio to audio though). > Overall - here be (baby) dragons in the glitch-avoidance variation... > > > > In theory you could allow one telephone-event PT and do a renegotiate > after an effective codec/PT change. You might need to be careful about > asynchronicity due to the renegotiation and not re-use the same PT for a > different rate of telephone-event (ping-pong between two). There would > exist a window when there was a switch where it would be problematic to > send telephone-event (and you'd need to require that both sides switch when > one does). Overall - here be (big) dragons. > > > > -- > > Randell Jesup -- rjesup a t mozilla d o t com > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > ------------------------------ > > Message: 4 > Date: Tue, 28 Jan 2014 18:25:17 +0000 > From: Christer Holmberg > To: Paul Kyzivat , "mmusic@ietf.org" > > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > Message-ID: <9dt0s2vbp3f9xidieks341ev.1390933514153@email.android.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Paul, > > I can't think of a use-case with multiple audio m- lines, where each would > need to support telephone-events. > > Perhaps such use-cases do exist, but I don't they are very common. > > Regards, > > Christer > > Sent from my Sony Ericsson Xperia arc S > > Paul Kyzivat wrote: > > > On 1/28/14 8:02 AM, Christer Holmberg wrote: > > Hi, > > > > I guess it would be good to add some text to BUNDLE, to indicate that > you must include the telephone-event PTs for every m- line which may use > them. I.e. you cannot indicate telephone-event for one m- line, and then > use them on every m- line within the bundle group. > > > > But, I guess there will be no need for people to support > telephone-events on more than one m- line to begin with, so... > > Why would you say that? > > Thanks, > Paul > > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup > > Sent: 27. tammikuuta 2014 10:48 > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > > > > On 1/24/2014 10:59 AM, Adam Roach wrote: > >> On 1/24/14 04:29, Magnus Westerlund wrote: > >>> My understanding for the reasoning behind this definition in the RFC > >>> is due to that the events is supposed to be connected to the same > >>> time-line as the audio. Thus it ended up using the same SSRC. To > >>> avoid timestamp rate switching which we know has issues > >>> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra > >>> tes/) > >>> > >>> it was mandated to provide one PT for each rate negotiated for the > >>> audio payload types. > >> > >> To make sure I understand what you're saying correctly: you are > >> asserting that having four different clock rates for voice codecs > >> requires us to use four different PTs for telephone-event if we're > >> going to have them on the same SSRC. Is that correct? > > > > If those four PT's (not codecs) are accepted (and thus can be switched > between on-the-fly), yes. Multiple clock rates plays hell with RTP > timestamps. > > > > You could use a separate SSRC (or m=audio line) for each clock rate > instead. This would likely mean glitching at transitions however, so not a > great solution, but works. You might be able to avoid glitches by making > sure you send RTCP for the alternate SSRCs so synchronization info is > available, though this may require the receiver to know somehow that the > SSRC's need to be "lip-synced" (in this case audio to audio though). > Overall - here be (baby) dragons in the glitch-avoidance variation... > > > > In theory you could allow one telephone-event PT and do a renegotiate > after an effective codec/PT change. You might need to be careful about > asynchronicity due to the renegotiation and not re-use the same PT for a > different rate of telephone-event (ping-pong between two). There would > exist a window when there was a switch where it would be problematic to > send telephone-event (and you'd need to require that both sides switch when > one does). Overall - here be (big) dragons. > > > > -- > > Randell Jesup -- rjesup a t mozilla d o t com > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > ------------------------------ > > Message: 5 > Date: Tue, 28 Jan 2014 19:01:46 +0100 > From: Harald Alvestrand > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > Message-ID: <52E7F08A.6070200@alvestrand.no> > Content-Type: text/plain; charset=ISO-8859-1 > > On 01/28/2014 02:02 PM, Christer Holmberg wrote: > > Hi, > > > > I guess it would be good to add some text to BUNDLE, to indicate that > you must include the telephone-event PTs for every m- line which may use > them. I.e. you cannot indicate telephone-event for one m- line, and then > use them on every m- line within the bundle group. > > > > But, I guess there will be no need for people to support > telephone-events on more than one m- line to begin with, so... > > Telephone-events are a hack for gateways into contexts where DTMF > signalling makes sense - which is primarily the telephone network and > telephone-related systems. > > In practice, I don't expect gateways into those contexts to support very > many clock rates - they should support G.711's 8000 and Opus' 48K, and > hopefully that's the end of it. > > I don't want to worry very much about two extra lines of SDP; let's just > declare (probably in -rtcweb-audio-) that if multiple audio codec > bitrates are offered, and one wishes to use DTMF no matter what codec is > selected, one must offer DTMF at each clock rate offered - each offer > consuming one PT. > > > > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup > > Sent: 27. tammikuuta 2014 10:48 > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] Telephone-event and multiple clock rates > > > > On 1/24/2014 10:59 AM, Adam Roach wrote: > >> On 1/24/14 04:29, Magnus Westerlund wrote: > >>> My understanding for the reasoning behind this definition in the RFC > >>> is due to that the events is supposed to be connected to the same > >>> time-line as the audio. Thus it ended up using the same SSRC. To > >>> avoid timestamp rate switching which we know has issues > >>> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra > >>> tes/) > >>> > >>> it was mandated to provide one PT for each rate negotiated for the > >>> audio payload types. > >> To make sure I understand what you're saying correctly: you are > >> asserting that having four different clock rates for voice codecs > >> requires us to use four different PTs for telephone-event if we're > >> going to have them on the same SSRC. Is that correct? > > If those four PT's (not codecs) are accepted (and thus can be switched > between on-the-fly), yes. Multiple clock rates plays hell with RTP > timestamps. > > > > You could use a separate SSRC (or m=audio line) for each clock rate > instead. This would likely mean glitching at transitions however, so not a > great solution, but works. You might be able to avoid glitches by making > sure you send RTCP for the alternate SSRCs so synchronization info is > available, though this may require the receiver to know somehow that the > SSRC's need to be "lip-synced" (in this case audio to audio though). > Overall - here be (baby) dragons in the glitch-avoidance variation... > > > > In theory you could allow one telephone-event PT and do a renegotiate > after an effective codec/PT change. You might need to be careful about > asynchronicity due to the renegotiation and not re-use the same PT for a > different rate of telephone-event (ping-pong between two). There would > exist a window when there was a switch where it would be problematic to > send telephone-event (and you'd need to require that both sides switch when > one does). Overall - here be (big) dragons. > > > > -- > > Randell Jesup -- rjesup a t mozilla d o t com > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > -- > Surveillance is pervasive. Go Dark. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > ------------------------------ > > End of mmusic Digest, Vol 117, Issue 19 > *************************************** > --089e0160d2b85f48d004f11b6bfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Cool dude. BTW, how much sqft does wardrobe come to?

On Jan 29, 2014 12:51 AM, <mmusic-request@ietf.org> wrote:
Send mmusic mailing list submissions to
=A0 =A0 =A0 =A0 mmusic@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/mmusic
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0 mmusic-request@i= etf.org

You can reach the person managing the list at
=A0 =A0 =A0 =A0 mmusic-owner@ietf.= org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mmusic digest..."


Today's Topics:

=A0 =A01. Re: Telephone-event and multiple clock rates (Christer Holmberg)<= br> =A0 =A02. Re: New Version Notification for
=A0 =A0 =A0 draft-reddy-mmusic-ice-happy-eyeballs-04.txt
=A0 =A0 =A0 (Pal Martinsen (palmarti))
=A0 =A03. Re: Telephone-event and multiple clock rates (Paul Kyzivat)
=A0 =A04. Re: Telephone-event and multiple clock rates (Christer Holmberg)<= br> =A0 =A05. Re: Telephone-event and multiple clock rates (Harald Alvestrand)<= br>

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

Message: 1
Date: Tue, 28 Jan 2014 13:02:50 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Randell Jesup <randell-iet= f@jesup.org>, "mmusic@ietf.o= rg"
=A0 =A0 =A0 =A0 <mmusic@ietf.org&= gt;
Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
Message-ID:
=A0 =A0 =A0 =A0 <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSM= B209.ericsson.se>
Content-Type: text/plain; charset=3D"us-ascii"

Hi,

I guess it would be good to add some text to BUNDLE, to indicate that you m= ust include the telephone-event PTs for every m- line which may use them. I= .e. you cannot indicate telephone-event for one m- line, and then use them = on every m- line within the bundle group.

But, I guess there will be no need for people to support telephone-events o= n more than one m- line to begin with, so...

Regards,

Christer


-----Original Message-----
From: mmusic [mailto:mmusic-boun= ces@ietf.org] On Behalf Of Randell Jesup
Sent: 27. tammikuuta 2014 10:48
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Telephone-event and multiple clock rates

On 1/24/2014 10:59 AM, Adam Roach wrote:
> On 1/24/14 04:29, Magnus Westerlund wrote:
>> My understanding for the reasoning behind this definition in the R= FC
>> is due to that the events is supposed to be connected to the same<= br> >> time-line as the audio. Thus it ended up using the same SSRC. To >> avoid timestamp rate switching which we know has issues
>> (https://datatracker.ietf.org/doc/draft-ie= tf-avtext-multiple-clock-ra
>> tes/)
>>
>> it was mandated to provide one PT for each rate negotiated for the=
>> audio payload types.
>
> To make sure I understand what you're saying correctly: you are > asserting that having four different clock rates for voice codecs
> requires us to use four different PTs for telephone-event if we're=
> going to have them on the same SSRC. Is that correct?

If those four PT's (not codecs) are accepted (and thus can be switched = between on-the-fly), yes. =A0Multiple clock rates plays hell with RTP times= tamps.

You could use a separate SSRC (or m=3Daudio line) for each clock rate inste= ad. =A0This would likely mean glitching at transitions however, so not a gr= eat solution, but works. =A0You might be able to avoid glitches by making s= ure you send RTCP for the alternate SSRCs so synchronization info is availa= ble, though this may require the receiver to know somehow that the SSRC'= ;s need to be "lip-synced" (in this case audio to audio though). = =A0Overall - here be (baby) dragons in the glitch-avoidance variation...
In theory you could allow one telephone-event PT and do a renegotiate after= an effective codec/PT change. =A0You might need to be careful about asynch= ronicity due to the renegotiation and not re-use the same PT for a differen= t rate of telephone-event (ping-pong between two). =A0There would exist a w= indow when there was a switch where it would be problematic to send telepho= ne-event (and you'd need to require that both sides switch when one doe= s). Overall - here be (big) dragons.

--
Randell Jesup -- rjesup a t mozilla d o t com

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


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

Message: 2
Date: Tue, 28 Jan 2014 13:49:19 +0000
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Ari Ker?nen <ari.keranen= @ericsson.com>
Cc: mmusic <mmusic@ietf.org>, = "Tirumaleswar Reddy \(tireddy\)"
=A0 =A0 =A0 =A0 <tireddy@cisco.com<= /a>>
Subject: Re: [MMUSIC] New Version Notification for
=A0 =A0 =A0 =A0 draft-reddy-mmusic-ice-happy-eyeballs-04.txt
Message-ID: <7C0E6D63-D816-4415-B621-73A0309C6AB2@cisco.com>
Content-Type: text/plain; charset=3D"Windows-1252"


On 24 Jan 2014, at 14:59 pm, Ari Ker?nen <ari.keranen@ericsson.com> wrote:

> Hi,
>
> The way forward you proposed sounds good. Looking forward to the updat= ed draft. However, I didn?t really understand how is the lack of coordinati= on and different promo algorithms an advantage?

My thought at the time was due to triggered checks it could in some cases b= e good to have uncoordinated checklists for IPv6 due to less NATs and other= restrictive ?things?. But that is clearly a bad idea. Sorry for the derail= ing.

Just posted -05 version of the draft.

Name: =A0 =A0 =A0 =A0 =A0 draft-reddy-mmusic-ice-happy-eyeballs
Revision: =A0 =A0 =A0 05
Title: =A0 =A0 =A0 =A0 =A0Happy Eyeballs Extension for ICE
Document date: =A02014-01-28
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A05
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.= ietf.org/internet-drafts/draft-reddy-mmusic-ice-happy-eyeballs-05.txt Status: =A0 =A0 =A0 =A0 https://datatracker.ietf= .org/doc/draft-reddy-mmusic-ice-happy-eyeballs/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/dra= ft-reddy-mmusic-ice-happy-eyeballs-05
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.or= g/rfcdiff?url2=3Ddraft-reddy-mmusic-ice-happy-eyeballs-05


Not sure if we hit the right balance between keeping it short, but still re= adable without having all the ICE details fresh in memory.

Do we ask for WG adoption, or do we need another MMUSIC session discussing = this?

.-.
P?l-Erik

>
>
> Cheers,
> Ari
>
> On 13 Jan 2014, at 13:46, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:
>
>>>
>>>
>>> Also, if there is no coordination/signaling between the endpoi= nts, what are the odds they'd end up using the same promotion algorithm= ?
>>>
>> Exactly, and that might be an advantage..
>



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

Message: 3
Date: Tue, 28 Jan 2014 11:32:02 -0500
From: Paul Kyzivat <pkyzivat@al= um.mit.edu>
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
Message-ID: <52E7DB82.2= 080907@alum.mit.edu>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

On 1/28/14 8:02 AM, Christer Holmberg wrote:
> Hi,
>
> I guess it would be good to add some text to BUNDLE, to indicate that = you must include the telephone-event PTs for every m- line which may use th= em. I.e. you cannot indicate telephone-event for one m- line, and then use = them on every m- line within the bundle group.
>
> But, I guess there will be no need for people to support telephone-eve= nts on more than one m- line to begin with, so...

Why would you say that?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

> Regards,
>
> Christer
>
>
> -----Original Message-----
> From: mmusic [mailto:mmusic= -bounces@ietf.org] On Behalf Of Randell Jesup
> Sent: 27. tammikuuta 2014 10:48
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
>
> On 1/24/2014 10:59 AM, Adam Roach wrote:
>> On 1/24/14 04:29, Magnus Westerlund wrote:
>>> My understanding for the reasoning behind this definition in t= he RFC
>>> is due to that the events is supposed to be connected to the s= ame
>>> time-line as the audio. Thus it ended up using the same SSRC. = To
>>> avoid timestamp rate switching which we know has issues
>>> (https://datatracker.ietf.org/doc/draf= t-ietf-avtext-multiple-clock-ra
>>> tes/)
>>>
>>> it was mandated to provide one PT for each rate negotiated for= the
>>> audio payload types.
>>
>> To make sure I understand what you're saying correctly: you ar= e
>> asserting that having four different clock rates for voice codecs<= br> >> requires us to use four different PTs for telephone-event if we= 9;re
>> going to have them on the same SSRC. Is that correct?
>
> If those four PT's (not codecs) are accepted (and thus can be swit= ched between on-the-fly), yes. =A0Multiple clock rates plays hell with RTP = timestamps.
>
> You could use a separate SSRC (or m=3Daudio line) for each clock rate = instead. =A0This would likely mean glitching at transitions however, so not= a great solution, but works. =A0You might be able to avoid glitches by mak= ing sure you send RTCP for the alternate SSRCs so synchronization info is a= vailable, though this may require the receiver to know somehow that the SSR= C's need to be "lip-synced" (in this case audio to audio thou= gh). =A0Overall - here be (baby) dragons in the glitch-avoidance variation.= ..
>
> In theory you could allow one telephone-event PT and do a renegotiate = after an effective codec/PT change. =A0You might need to be careful about a= synchronicity due to the renegotiation and not re-use the same PT for a dif= ferent rate of telephone-event (ping-pong between two). =A0There would exis= t a window when there was a switch where it would be problematic to send te= lephone-event (and you'd need to require that both sides switch when on= e does). Overall - here be (big) dragons.
>
> --
> Randell Jesup -- rjesup a t mozilla d o t com
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>



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

Message: 4
Date: Tue, 28 Jan 2014 18:25:17 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum= .mit.edu>, "mmusic@ietf.org<= /a>"
=A0 =A0 =A0 =A0 <mmusic@ietf.org&= gt;
Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
Message-ID: <9dt0s2vbp3f9xidieks341ev.1390933514153@email.android.com>
Content-Type: text/plain; charset=3D"us-ascii"

Hi Paul,

I can't think of a use-case with multiple audio m- lines, where each wo= uld need to support telephone-events.

Perhaps such use-cases do exist, but I don't they are very common.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat <pkyzivat@alum.mit= .edu> wrote:


On 1/28/14 8:02 AM, Christer Holmberg wrote:
> Hi,
>
> I guess it would be good to add some text to BUNDLE, to indicate that = you must include the telephone-event PTs for every m- line which may use th= em. I.e. you cannot indicate telephone-event for one m- line, and then use = them on every m- line within the bundle group.
>
> But, I guess there will be no need for people to support telephone-eve= nts on more than one m- line to begin with, so...

Why would you say that?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

> Regards,
>
> Christer
>
>
> -----Original Message-----
> From: mmusic [mailto:mmusic= -bounces@ietf.org] On Behalf Of Randell Jesup
> Sent: 27. tammikuuta 2014 10:48
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
>
> On 1/24/2014 10:59 AM, Adam Roach wrote:
>> On 1/24/14 04:29, Magnus Westerlund wrote:
>>> My understanding for the reasoning behind this definition in t= he RFC
>>> is due to that the events is supposed to be connected to the s= ame
>>> time-line as the audio. Thus it ended up using the same SSRC. = To
>>> avoid timestamp rate switching which we know has issues
>>> (https://datatracker.ietf.org/doc/draf= t-ietf-avtext-multiple-clock-ra
>>> tes/)
>>>
>>> it was mandated to provide one PT for each rate negotiated for= the
>>> audio payload types.
>>
>> To make sure I understand what you're saying correctly: you ar= e
>> asserting that having four different clock rates for voice codecs<= br> >> requires us to use four different PTs for telephone-event if we= 9;re
>> going to have them on the same SSRC. Is that correct?
>
> If those four PT's (not codecs) are accepted (and thus can be swit= ched between on-the-fly), yes. =A0Multiple clock rates plays hell with RTP = timestamps.
>
> You could use a separate SSRC (or m=3Daudio line) for each clock rate = instead. =A0This would likely mean glitching at transitions however, so not= a great solution, but works. =A0You might be able to avoid glitches by mak= ing sure you send RTCP for the alternate SSRCs so synchronization info is a= vailable, though this may require the receiver to know somehow that the SSR= C's need to be "lip-synced" (in this case audio to audio thou= gh). =A0Overall - here be (baby) dragons in the glitch-avoidance variation.= ..
>
> In theory you could allow one telephone-event PT and do a renegotiate = after an effective codec/PT change. =A0You might need to be careful about a= synchronicity due to the renegotiation and not re-use the same PT for a dif= ferent rate of telephone-event (ping-pong between two). =A0There would exis= t a window when there was a switch where it would be problematic to send te= lephone-event (and you'd need to require that both sides switch when on= e does). Overall - here be (big) dragons.
>
> --
> Randell Jesup -- rjesup a t mozilla d o t com
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

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


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

Message: 5
Date: Tue, 28 Jan 2014 19:01:46 +0100
From: Harald Alvestrand <harald@= alvestrand.no>
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
Message-ID: <52E7F08A.= 6070200@alvestrand.no>
Content-Type: text/plain; charset=3DISO-8859-1

On 01/28/2014 02:02 PM, Christer Holmberg wrote:
> Hi,
>
> I guess it would be good to add some text to BUNDLE, to indicate that = you must include the telephone-event PTs for every m- line which may use th= em. I.e. you cannot indicate telephone-event for one m- line, and then use = them on every m- line within the bundle group.
>
> But, I guess there will be no need for people to support telephone-eve= nts on more than one m- line to begin with, so...

Telephone-events are a hack for gateways into contexts where DTMF
signalling makes sense - which is primarily the telephone network and
telephone-related systems.

In practice, I don't expect gateways into those contexts to support ver= y
many clock rates - they should support G.711's 8000 and Opus' 48K, = and
hopefully that's the end of it.

I don't want to worry very much about two extra lines of SDP; let's= just
declare (probably in -rtcweb-audio-) that if multiple audio codec
bitrates are offered, and one wishes to use DTMF no matter what codec is selected, one must offer DTMF at each clock rate offered - each offer
consuming one PT.

>
> Regards,
>
> Christer
>
>
> -----Original Message-----
> From: mmusic [mailto:mmusic= -bounces@ietf.org] On Behalf Of Randell Jesup
> Sent: 27. tammikuuta 2014 10:48
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
>
> On 1/24/2014 10:59 AM, Adam Roach wrote:
>> On 1/24/14 04:29, Magnus Westerlund wrote:
>>> My understanding for the reasoning behind this definition in t= he RFC
>>> is due to that the events is supposed to be connected to the s= ame
>>> time-line as the audio. Thus it ended up using the same SSRC. = To
>>> avoid timestamp rate switching which we know has issues
>>> (https://datatracker.ietf.org/doc/draf= t-ietf-avtext-multiple-clock-ra
>>> tes/)
>>>
>>> it was mandated to provide one PT for each rate negotiated for= the
>>> audio payload types.
>> To make sure I understand what you're saying correctly: you ar= e
>> asserting that having four different clock rates for voice codecs<= br> >> requires us to use four different PTs for telephone-event if we= 9;re
>> going to have them on the same SSRC. Is that correct?
> If those four PT's (not codecs) are accepted (and thus can be swit= ched between on-the-fly), yes. =A0Multiple clock rates plays hell with RTP = timestamps.
>
> You could use a separate SSRC (or m=3Daudio line) for each clock rate = instead. =A0This would likely mean glitching at transitions however, so not= a great solution, but works. =A0You might be able to avoid glitches by mak= ing sure you send RTCP for the alternate SSRCs so synchronization info is a= vailable, though this may require the receiver to know somehow that the SSR= C's need to be "lip-synced" (in this case audio to audio thou= gh). =A0Overall - here be (baby) dragons in the glitch-avoidance variation.= ..
>
> In theory you could allow one telephone-event PT and do a renegotiate = after an effective codec/PT change. =A0You might need to be careful about a= synchronicity due to the renegotiation and not re-use the same PT for a dif= ferent rate of telephone-event (ping-pong between two). =A0There would exis= t a window when there was a switch where it would be problematic to send te= lephone-event (and you'd need to require that both sides switch when on= e does). Overall - here be (big) dragons.
>
> --
> Randell Jesup -- rjesup a t mozilla d o t com
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--
Surveillance is pervasive. Go Dark.



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

Subject: Digest Footer

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


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

End of mmusic Digest, Vol 117, Issue 19
***************************************
--089e0160d2b85f48d004f11b6bfe-- From ietf-secretariat-reply@ietf.org Wed Jan 29 07:43:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8041A0416 for ; Wed, 29 Jan 2014 07:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkWi1dqEK5PF for ; Wed, 29 Jan 2014 07:43:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 279261A041B for ; Wed, 29 Jan 2014 07:43:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140129154301.8811.83938.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2014 07:43:01 -0800 From: IETF Secretariat Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:43:03 -0000 URL: http://datatracker.ietf.org/wg/mmusic/charter/ From ietf-secretariat-reply@ietf.org Wed Jan 29 08:37:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3F01A0230 for ; Wed, 29 Jan 2014 08:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXNs_yGgBwXY for ; Wed, 29 Jan 2014 08:37:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 069831A02F2 for ; Wed, 29 Jan 2014 08:37:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140129163754.23612.58318.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2014 08:37:54 -0800 From: IETF Secretariat Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 16:37:57 -0000 Changed milestone "Submit a framework for SDP attributes when multiplexing as Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mmusic/charter/ From internet-drafts@ietf.org Wed Jan 29 10:03:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45421A0468; Wed, 29 Jan 2014 10:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTlguI6aTsot; Wed, 29 Jan 2014 10:03:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0761A0440; Wed, 29 Jan 2014 10:03:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140129180334.21631.85872.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2014 10:03:34 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:03:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Offer/Answer Considerations for G723 Annex A and = G729 Annex B Authors : Muthu Arul Mozhi Perumal Parthasarathi Ravindran Filename : draft-ietf-mmusic-sdp-g723-g729-05.txt Pages : 8 Date : 2014-01-29 Abstract: This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D and G729E when the value of the annexa or annexb parameter does not match in the Session Description protocol (SDP) offer and answer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mperumal@cisco.com Wed Jan 29 10:09:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F8B1A0497 for ; Wed, 29 Jan 2014 10:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvBhvc-UwDuy for ; Wed, 29 Jan 2014 10:09:06 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id DF56C1A03E9 for ; Wed, 29 Jan 2014 10:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2021; q=dns/txt; s=iport; t=1391018922; x=1392228522; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xt7FVmV+Dh/gDypZJcWCnzQveEofBHzwzwoCspvATa0=; b=eScO4Q7kD25uekShIp/Y2pU242pCVKRfzJwObV17rfF5TlOchvFFqnrZ GUhppy0tnHd+jguuPrQD+Pq3a+UvFGU/4EJPUc/7vL/xKlwgq2t8xFgrI oLKsm3VB4iGrup1Ho4tzC+G9x1y+5JOpVm8nfxXdiHup0vcTyiKKdaOfc E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFAJxC6VKtJV2Y/2dsb2JhbABZgww4UAa9AoEHFnSCJQEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQHAQEFAwIEEwgBh3wIBcoNF45OMwUGgx6BFASZWosvhT6DLYIq X-IronPort-AV: E=Sophos;i="4.95,743,1384300800"; d="scan'208";a="16453638" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 29 Jan 2014 18:08:41 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0TI8fZf003777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 29 Jan 2014 18:08:41 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.29]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 12:08:41 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-g723-g729-05.txt Thread-Index: AQHPHRx6UTDqKxdWTU6YLnlPxa/dEJqb/z8Q Date: Wed, 29 Jan 2014 18:08:41 +0000 Message-ID: References: <20140129180334.21631.85872.idtracker@ietfa.amsl.com> In-Reply-To: <20140129180334.21631.85872.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-g723-g729-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:09:08 -0000 WG, This addresses the IETF Last Call and Gen-ART review comments. Muthu -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Wednesday, January 29, 2014 11:34 PM To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: I-D Action: draft-ietf-mmusic-sdp-g723-g729-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Offer/Answer Considerations for G723 Annex A and = G729 Annex B Authors : Muthu Arul Mozhi Perumal Parthasarathi Ravindran Filename : draft-ietf-mmusic-sdp-g723-g729-05.txt Pages : 8 Date : 2014-01-29 Abstract: This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D and G729E when the value of the annexa or annexb parameter does not match in the Session Description protocol (SDP) offer and answer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 mperumal@cisco.com Wed Jan 29 10:11:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F601A029B for ; Wed, 29 Jan 2014 10:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.736 X-Spam-Level: X-Spam-Status: No, score=-9.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMFJtzbULW3m for ; Wed, 29 Jan 2014 10:11:36 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 357901A0230 for ; Wed, 29 Jan 2014 10:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4239; q=dns/txt; s=iport; t=1391019093; x=1392228693; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TArUnrv0U3FA5Y5OmlsG6uhXp6chS/SXgWvbCieTBrA=; b=XI0JjyiXctZ9ZHaGEIOU1WLPVAZWIuNNF04L1+EPAZLSBRm1V/0pCf4j HOasLFBSVT7lzaQu5uFc2pI8gTDvbh03pUa7EYCeYgkI4AzJyi0XMDQAl c2GzpjYfoBakVQ5b5LXnZy/JylMP1FdP/LuRTgGKn/152ADWTnhY1prI/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAMhD6VKtJXHB/2dsb2JhbABZgwyBDr0CgQcWdIIlAQEBBHkMBAIBCBEEAQELGQsyHQgCBAENBQiHfcoZF45OMQcGgx6BFASJEaE2gW+BPoIq X-IronPort-AV: E=Sophos;i="4.95,743,1384300800"; d="scan'208";a="16454732" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-4.cisco.com with ESMTP; 29 Jan 2014 18:11:32 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0TIBWqp015388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 18:11:32 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.29]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 12:11:32 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Flemming Andreasen (fandreas)" , SM , "DRAGE, Keith (Keith)" , =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard Thread-Index: AQHO8XBksVWA6H39DU+VrLLXgZIJH5qRwTbPgAqWXEA= Date: Wed, 29 Jan 2014 18:11:31 +0000 Message-ID: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> <949EF20990823C4C85C18D59AA11AD8B0F23CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> <6.2.5.6.2.20131204204318.0b8c2430@resistor.net> <52E0622E.5070806@cisco.com> In-Reply-To: <52E0622E.5070806@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:11:39 -0000 We just published the -05 version addressing these comments.. Muthu |-----Original Message----- |From: Flemming Andreasen (fandreas) |Sent: Thursday, January 23, 2014 5:59 AM |To: SM; Muthu Arul Mozhi Perumal (mperumal); DRAGE, Keith (Keith); Ari Ker= =E4nen |Cc: mmusic@ietf.org |Subject: Re: [MMUSIC] Last Call: = (Offer/Answer Considerations |for G723 Annex A and G729 Annex B) to Proposed Standard | |Greetings | |The chairs have reviewed this thread carefully and also discussed it |with our AD. To conclude, we believe we have concensus to proceed with |the document as follows: |- The document does not formally update RFC 4856 (or any other RFC) and |hence the front page and abstract will be updated accordingly. |- The document will remain Standards Track. |- Since the "annexa" and "annexb" parameters are defined in RFC 4856, it |makes sense to keep the reference to RFC 4856 in the introductory text, |along the lines of Muthu's suggested "New Introduction" text in the |previous message in this thread. | |If anybody disagrees with this conclusion, please let the chairs know. | |Thanks | | Ari & Flemming (MMUSIC co-chairs) | | | | |On 12/4/13, 11:54 PM, SM wrote: |> Hi Muthu, |> At 20:13 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: |>> I see your point. |>> |>> Our opinion was that an RFC that specifies the mapping of media type |>> parameters with SDP and registers the media types with IANA should |>> also describe its usage, especially with the offer/answer model (e.g, |>> RFC435). In that sense we thought draft-ietf-mmusic-sdp-g723-g729 is |>> an update to RFC4856. |>> |>> Your opinion is that they should be delinked -- one RFC can register |>> the media types and another RFC can describe the usage for the |>> registered media types independently. I am fine with that. The |>> abstract and introduction in draft-ietf-mmusic-sdp-g723-g729 can |>> easily be changed to reflect it. |> |> Yes, but you can have both in one RFC. The registration can be |> requested in the IANA Considerations section. |> |>> --------------------------------------------------------------------- |>> Current Abstract: |>> 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 Session Description |>> protocol(SDP) offer and answer. This document provides the offer/ |>> answer considerations for these parameters and updates RFC4856. |>> |>> New Abstract: |>> There are no specifications that describe the offerer and answerer |>> behavior when the value of the annexa parameter of G729 or the annex= b |>> parameter of G729, G729D and G729E does not match in the Session |>> Description protocol(SDP) offer and answer. This document provides |>> the |>> offer/answer considerations for these parameters. |> |> I suggest removing "there are no specifications ..." and explain what |> the document specifies. |> |>> Current Introduction: |>> [RFC4856] describes the annexa parameter for G723 as follows: |>> |>> annexa: indicates that Annex A, voice activity detection, is used |>> or preferred. Permissible values are "yes" and "no" (without the |>> quotes); "yes" is implied if this parameter is omitted. |>> |>> Also, [RFC4856] describes the annexb parameter for G729, G729D and |>> G729E as follows: |>> |>> annexb: indicates that Annex B, voice activity detection, is used |>> or preferred. Permissible values are "yes" and "no" (without the |>> quotes); "yes" is implied if this parameter is omitted. |> |> The above starts with RFC 4856. I suggest starting with the RFC 4566 |> followed by the RFC 3264 text (I did not verify the reference). You |> can then specify the fmtp parameters for Annex A, etc. Once you have |> done that, verify whether there are some registry requirements and add |> text for that in a IANA Considerations section. |> |> Regards, |> -sm |> . |> From keith.drage@alcatel-lucent.com Wed Jan 29 16:39:33 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CAD1A0425; Wed, 29 Jan 2014 16:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsfQUOC2sUaF; Wed, 29 Jan 2014 16:39:32 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEDF1A0424; Wed, 29 Jan 2014 16:39:32 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0U0dRk3024724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2014 18:39:28 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0U0dQ0K025060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 01:39:27 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 30 Jan 2014 01:39:27 +0100 From: "DRAGE, Keith (Keith)" To: "avtcore@ietf.org" , "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" Thread-Topic: draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: Ac8dU7miUI8F3eIfTMKku34324AzNA== Date: Thu, 30 Jan 2014 00:39:25 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B125741@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] draft-ietf-avtext-rtp-grouping-taxonomy-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 00:39:33 -0000 To all potential users of the taxonomy document in other working groups. We could do with a few people reading the above draft and identifying omiss= ions, open issues, or corrections, so the editors can get a new version out= prior to the AVTEXT meeting in London. https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ In particular, those of you who have drafts that might use some of this ter= minology. Please respond to the avtext list. Regards Keith AVTEXT WG cochair.= From Christian.Groves@nteczone.com Wed Jan 29 20:24:45 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B7A1A02DA for ; Wed, 29 Jan 2014 20:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70_a7NIK2IQv for ; Wed, 29 Jan 2014 20:24:43 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553E31A0190 for ; Wed, 29 Jan 2014 20:24:43 -0800 (PST) Received: from ppp118-209-220-51.lns20.mel6.internode.on.net ([118.209.220.51]:59010 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W8jAi-00068M-M9 for mmusic@ietf.org; Thu, 30 Jan 2014 15:24:12 +1100 Message-ID: <52E9D403.8040205@nteczone.com> Date: Thu, 30 Jan 2014 15:24:35 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D13BB05@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D13BB05@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MMUSIC] Questions on draft-ietf-mmusic-sctp-sdp-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 04:24:45 -0000 Hello, Not an answer but a further question related to Q4. Is it possible to have several of the same media-subtypes per SCTP association? i.e. a=sctpmap:5000 webrtc-datachannel 16 a=sctpmap:5001 bfcp 2 a=sctpmap:5002 bfcp 1 I think it has been pointed about before but the media-subtypes ABNF is incomplete. The draft also indicates that the use of existing MIME subtypes for the media-subtype format is encouraged. I assume this means the use of one of the values from the IANA media type registry ? If so then "bfcp" is not a registered type there. However T38 (audio or image) is. draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 also uses BFCP and MSRP. It mentions these in terms of "sub-protocol" which I assume more relates to the proto field at http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2. However BFCP and MSRP are not individual values there either and it doesn't define t38. I couldn't find the rtcweb draft that proposes to register webrtc-Datachannel in either of the above registries. I saw draft-ejzak-dispatch-webrtc-data-channel-sdpneg proposing a a=webrtc-Datachannel attribute. I thought SDP attributes needed a static name (i.e. so it can be registered by IANA). In cl.4.3 of the draft it appears that the attribute name is based on the "protocol" in the sctpmap. However this would imply a dynamic allocation of attribute names. I'm confused. Can any one clarify what the media-subtype is meant to be? Regards, Christian On 27/01/2014 10:36 PM, Christer Holmberg wrote: > > Hi, > > Section 5.1 of draft-ietf-mmusic-sctp-sdp-05 describes how an offered > SCTP association can be rejected, by in the Answer setting the port > value in the associated SDP sctpmap attribute to zero. > > *Q1:* When an SCTP association is rejected, shall the > associated port value in the m- line fmt list also be set to zero? The > text only talks about the sctpmap attribute. > > The draft does not talk about subsequent offers. > > *Q2:* Do I need to include all sctpmap attributes in > subsequent offers, even if some are associated with previously > rejected STCP associations, in order to maintain the order? > > *Q3:* Can I, in a subsequent offer, remove an SCTP association > by setting the associated port value to zero? If so, do I set the port > value to zero in the associated sctpmap attribute, and/or the m- line > fmt list? > > The draft only talks about having a single media-subtype per SCTP > association. > > *Q4*: Is it possible to define multiple media-subtypes per > SCTP association? > > Example: > > m=application 54111 DTLS/SCTP *5000* > > c=IN IP4 79.97.215.79 > > a=sctpmap:*5000* webrtc-datachannel 16 > > a=sctpmap:*5000* bfcp 2 > > a=sctpmap:*5000* t38 1 > > (Each media-subtype could use different SCTP streams > within the SCTP association) > > Thanks! > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Wed Jan 29 21:12:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CF51A0493 for ; Wed, 29 Jan 2014 21:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nge3hmcvJ9-y for ; Wed, 29 Jan 2014 21:12:01 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 6356E1A0191 for ; Wed, 29 Jan 2014 21:12:01 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id L5BS1n0011c6gX85A5Bx9e; Thu, 30 Jan 2014 05:11:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id L5Bx1n00Y3ZTu2S3j5BxbQ; Thu, 30 Jan 2014 05:11:57 +0000 Message-ID: <52E9DF1D.5040708@alum.mit.edu> Date: Thu, 30 Jan 2014 00:11:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D13BB05@ESESSMB209.ericsson.se> <52E9D403.8040205@nteczone.com> In-Reply-To: <52E9D403.8040205@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391058717; bh=cNejGRrgyYhvo7lc+zTMxvN643oRr9VnAXlLKMun6ow=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OvRmzhLTD8qa45KbkDCKKwnXcGr9po9zQwHHK6nqqdRXk9Syo7RxVvo2mmuVWZQmu 1kEwfa3bA4mkROgw2gX+Ox1Yp4hKAyLU65lO7BUfsOwqbla4PeM4jG9anKNDRaq69e MsazijiDb5/cS618HRJXwsxP/9K4NfYsOPMeLDbBUUxZNFycc5CLmYUsQeV6SWNrms M7xKJ5DRqBw2lPkHhL47H4ss69l50TCKJgNHrneqB+ZPwPW4YAz9LhbDrg+wqdfsiB LBFUpQBDdYSBIwlD4kwixkbaT7H27Z3YhlmU1cybKfVebUubKCn3yOp6nYfmZ+nEpZ nwyv3gWSyJLcQ== Subject: Re: [MMUSIC] Questions on draft-ietf-mmusic-sctp-sdp-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 05:12:03 -0000 On 1/29/14 11:24 PM, Christian Groves wrote: > Hello, > > Not an answer but a further question related to Q4. > Is it possible to have several of the same media-subtypes per SCTP > association? > i.e. a=sctpmap:5000 webrtc-datachannel 16 > a=sctpmap:5001 bfcp 2 > a=sctpmap:5002 bfcp 1 AFAICT this should be ok. BUT, I find associating a media subtype with an sctp association nonsensical. Each association represents a set of independent channels. What sense does it make to associate a media sub-type with set of channels? The existing media subtypes, such as bfcp, are are intended to be mapped onto a packet stream, such as you get with UDP or RTP. A "type" that is associated with an sctp association ought to describe a particular usage of a *set* of packet streams, or channels. That is a very different sort of thing. > I think it has been pointed about before but the media-subtypes ABNF is > incomplete. > > The draft also indicates that the use of existing MIME subtypes for the > media-subtype format is encouraged. I assume this means the use of one > of the values from the IANA media type registry > ? If so > then "bfcp" is not a registered type there. However T38 (audio or image) > is. > > draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 also uses BFCP and > MSRP. It mentions these in terms of "sub-protocol" which I assume more > relates to the proto field at > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2. > However BFCP and MSRP are not individual values there either and it > doesn't define t38. There are a lot of details to iron out, but at least the ejzak draft is independently declaring the data type per channel within an association. Thanks, Paul > I couldn't find the rtcweb draft that proposes to register > webrtc-Datachannel in either of the above registries. > > I saw draft-ejzak-dispatch-webrtc-data-channel-sdpneg proposing a > a=webrtc-Datachannel attribute. I thought SDP attributes needed a static > name (i.e. so it can be registered by IANA). In cl.4.3 of the draft it > appears that the attribute name is based on the "protocol" in the > sctpmap. However this would imply a dynamic allocation of attribute names. > > I'm confused. Can any one clarify what the media-subtype is meant to be? > > Regards, > Christian > > > On 27/01/2014 10:36 PM, Christer Holmberg wrote: >> >> Hi, >> >> Section 5.1 of draft-ietf-mmusic-sctp-sdp-05 describes how an offered >> SCTP association can be rejected, by in the Answer setting the port >> value in the associated SDP sctpmap attribute to zero. >> >> *Q1:* When an SCTP association is rejected, shall the >> associated port value in the m- line fmt list also be set to zero? The >> text only talks about the sctpmap attribute. >> >> The draft does not talk about subsequent offers. >> >> *Q2:* Do I need to include all sctpmap attributes in >> subsequent offers, even if some are associated with previously >> rejected STCP associations, in order to maintain the order? >> >> *Q3:* Can I, in a subsequent offer, remove an SCTP association >> by setting the associated port value to zero? If so, do I set the port >> value to zero in the associated sctpmap attribute, and/or the m- line >> fmt list? >> >> The draft only talks about having a single media-subtype per SCTP >> association. >> >> *Q4*: Is it possible to define multiple media-subtypes per >> SCTP association? >> >> Example: >> >> m=application 54111 DTLS/SCTP *5000* >> >> c=IN IP4 79.97.215.79 >> >> a=sctpmap:*5000* webrtc-datachannel 16 >> >> a=sctpmap:*5000* bfcp 2 >> >> a=sctpmap:*5000* t38 1 >> >> (Each media-subtype could use different SCTP streams >> within the SCTP association) >> >> Thanks! >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Wed Jan 29 23:23:51 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED9C1A04FA for ; Wed, 29 Jan 2014 23:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0H_FdwvVKv1 for ; Wed, 29 Jan 2014 23:23:49 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 72DC31A0476 for ; Wed, 29 Jan 2014 23:23:49 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-6a-52e9fe01585b Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 21.67.04249.10EF9E25; Thu, 30 Jan 2014 08:23:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Thu, 30 Jan 2014 08:23:45 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Questions on draft-ietf-mmusic-sctp-sdp-05 Thread-Index: Ac8bUQl73YOfrjw4RXqWisjZiYMaaACGcLqAAAGnfoAABpelsA== Date: Thu, 30 Jan 2014 07:23:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D14B74F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D13BB05@ESESSMB209.ericsson.se> <52E9D403.8040205@nteczone.com> <52E9DF1D.5040708@alum.mit.edu> In-Reply-To: <52E9DF1D.5040708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvjS7jv5dBBlsv6VhMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGjfe72Qq2sVZsmvKTsYGxgaWLkZNDQsBE 4ubaz2wQtpjEhXvrgWwuDiGBI4wSbfeesUA4ixklriw9xtjFyMHBJmAh0f1PG6RBRMBX4tnj 22DNwgIOEkc/nmKCiDtKnH3Rzw5hO0n0XnvCCmKzCKhKnLzwjhHE5gXqbXvTD1YvJNDPKDHn eCyIzSmgI3H28mKwOCPQQd9PrQGzmQXEJW49mc8EcaiAxJI955khbFGJl4//sULYihI7z7Yz Q9TrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSNHcWpxUm66 kcEmRmA0HNzy22IH4+W/NocYpTlYlMR5P751DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA WLih8vCafD0Xvdb/+fNSp2lz/Sp+Pd9gQyuXbVTLlbmyMi98zgpUrjnjLRfJafrx4P342D/f V96aVLttSvH3i6Zyp8tFFls86g46z+BylNWriz+S8/W0iWoqH9xuvsstCin1Ea+aLn73lLNx VD7/rb+Ougtv7Lx2bB/vryUqxZ9SPG9//7bORYmlOCPRUIu5qDgRALEkU6RUAgAA Subject: Re: [MMUSIC] Questions on draft-ietf-mmusic-sctp-sdp-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 07:23:51 -0000 Hi, > Not an answer but a further question related to Q4. > Is it possible to have several of the same media-subtypes per SCTP=20 > association? > i.e. a=3Dsctpmap:5000 webrtc-datachannel 16 > a=3Dsctpmap:5001 bfcp 2 > a=3Dsctpmap:5002 bfcp 1 As the port values are different, aren't you using two DIFFERENT SCTP assoc= iations in the example? Section 4.1 of the draft says: "Running SCTP over DTLS make possible to have multiple SCTP associations on top of the same DTLS connection; each SCTP association make use of a distinct port number that is mainly used to demultiplex the associations." Regards, Christer From Christian.Groves@nteczone.com Thu Jan 30 01:46:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5D1A03C5 for ; Thu, 30 Jan 2014 01:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_17=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRUDc1NFrzok for ; Thu, 30 Jan 2014 01:46:38 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD94F1A03BE for ; Thu, 30 Jan 2014 01:46:37 -0800 (PST) Received: from ppp118-209-220-51.lns20.mel6.internode.on.net ([118.209.220.51]:65467 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W8oCC-0007kJ-Qf for mmusic@ietf.org; Thu, 30 Jan 2014 20:46:04 +1100 Message-ID: <52EA1F76.6080905@nteczone.com> Date: Thu, 30 Jan 2014 20:46:30 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D13BB05@ESESSMB209.ericsson.se> <52E9D403.8040205@nteczone.com> <52E9DF1D.5040708@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D14B74F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14B74F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MMUSIC] Questions on draft-ietf-mmusic-sctp-sdp-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 09:46:39 -0000 Hello Christer, I guess then in my example there is different SCTP associations. I should have probably said the same media-subtype in several a=sctpmap attributes under the same m-line. Christian On 30/01/2014 6:23 PM, Christer Holmberg wrote: > Hi, > >> Not an answer but a further question related to Q4. >> Is it possible to have several of the same media-subtypes per SCTP >> association? >> i.e. a=sctpmap:5000 webrtc-datachannel 16 >> a=sctpmap:5001 bfcp 2 >> a=sctpmap:5002 bfcp 1 > As the port values are different, aren't you using two DIFFERENT SCTP associations in the example? > > Section 4.1 of the draft says: > > "Running SCTP over DTLS make possible to have multiple SCTP > associations on top of the same DTLS connection; each SCTP > association make use of a distinct port number that is mainly used to > demultiplex the associations." > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From ari.keranen@ericsson.com Thu Jan 30 03:34:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA4B1A0437 for ; Thu, 30 Jan 2014 03:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS2mlmMoCx25 for ; Thu, 30 Jan 2014 03:34:39 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id B573A1A042C for ; Thu, 30 Jan 2014 03:34:38 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-fc-52ea38ca84cb Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id A8.7B.04853.AC83AE25; Thu, 30 Jan 2014 12:34:34 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.2.347.0; Thu, 30 Jan 2014 12:34:34 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 39AA31102A9; Thu, 30 Jan 2014 13:34:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EADF75683D; Thu, 30 Jan 2014 13:34:29 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 989EA5683C; Thu, 30 Jan 2014 13:34:29 +0200 (EET) Message-ID: <52EA38C9.4070003@ericsson.com> Date: Thu, 30 Jan 2014 13:34:33 +0200 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" References: <20131209121243.31704.62698.idtracker@ietfa.amsl.com> <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> <52D01911.8030804@ericsson.com> <647464EE-B8E0-47FA-A375-8C758046D854@cisco.com> <7C0E6D63-D816-4415-B621-73A0309C6AB2@cisco.com> In-Reply-To: <7C0E6D63-D816-4415-B621-73A0309C6AB2@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje4pi1dBBpd/mFhMXf6YxeL99ZUs Fid2b2N0YPaY8nsjq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI2bV3GXPBWuOLr3EksDYy7+LsY OTkkBEwkem83s0LYYhIX7q1n62Lk4hASOMEosbH5OjuEs4FRou16JyuEs4dR4kt7F1TZWkaJ U8fWMkM4yxklFn19yggyjFdAW+JJ/xp2EJtFQFXi99pNYDabgKPE7YcvwRaKCiRLPNo2nRmi XlDi5MwnLCC2iICxRPORo2D1zAJBEo82XwCrERaIl+h+sA1svpDACiaJDc/yQWxOAVuJPw9a gS7iAKq3l3iwtQyiVV5i+9s5zBC/qUlcPbeJGaJVVeLqv1eMExhFZyHZPAuhexaS7gWMzKsY JYtTi4tz040M9HLTc0v0Uosyk4uL8/P0ilM3MQKj5OCW30Y7GE/usT/EKM3BoiTOe521JkhI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD44rkpNuPf3/Qfy7+MnB6/o/d3E/4OGKrFWe98Ny0 QtrhoaQks/n2CVr/v+xctJHTObrSVyA07LilwdXthmWRnbN4JF5wXO3jtuL4XSIfuCT70cL+ Z7m6khePfI70n7OnOGTXrcb/wa/Vvl7Km7/92BXxl+0tKx/u7PCbsuOq8+xZ505fmLrwXJAS S3FGoqEWc1FxIgCuvI6KYAIAAA== Cc: mmusic , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 11:34:40 -0000 Hi, On 28/01/14 15:49, Pal Martinsen (palmarti) wrote: > Just posted -05 version of the draft. Thanks! Here's a few comments on the latest version. The abstract says: > This document provides guidelines on how to make ICE [RFC5245] > conclude faster in IPv4/IPv6 dual-stack scenarios where broken paths > exist. This will lead to more sustained IPv6 deployment as users > will no longer have an incentive to disable IPv6. Out of (much of) context, especially the second sentence seems like a quite strong statement. I guess there could be other reasons than this for disabling v6, for example. And nit: usually abstract should not contain references and open the ICE acronym. > An ICE agent can choose an algorithm or a technique of its choice to > ensure that the resulting check lists have a fair intermingled mix of > IPv4 and IPv6 address families. Modifying the check list directly > can lead to uncoordinated local and remote check lists that result in > ICE taking longer to complete. Not only can the tests take longer, but they can potentially also fail if the lists get badly out of sync since once you have made a NAT binding with a connectivity check packet, the check to other direction must come before the binding expires. But I suppose this will not be a problem with the proposed solution since the lists will be in sync? > The local and remote agent can have different algorithms for choosing > the type preference value without any impact on coordination between > the local and remote check list. What do you mean by "without any impact on coordination"? > Where G is the candidate provided by the controlling agent and D the s/candidate/priority of the candidate/ > Do we ask for WG adoption, or do we need another MMUSIC session discussing this? Given this new approach, I think it's too early to ask for WG adoption. Rather we need more discussion especially here on the list and possibly at the meeting. What I would find helpful for discussion is that if you could provide a step-by-step example of how the candidate lists are formed and connectivity checks done in cases where a) both support this with same promo algo b) both support this but with different promo algo c) only one endpoint supports this. Also maybe a recommended promo algo would make sense so that there is at least a fair chance that both will use the same algo/values and get most out of this. Cheers, Ari From ari.keranen@nomadiclab.com Thu Jan 30 05:01:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B351A042D for ; Thu, 30 Jan 2014 05:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXXHKqRS0bnu for ; Thu, 30 Jan 2014 05:01:06 -0800 (PST) Received: from gw.nomadiclab.com (gw.nomadiclab.com [193.234.218.122]) by ietfa.amsl.com (Postfix) with ESMTP id 01ED71A0420 for ; Thu, 30 Jan 2014 05:01:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id C18FE4E6EF; Thu, 30 Jan 2014 15:01:01 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txn9YYVmRGAd; Thu, 30 Jan 2014 15:01:00 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id CBB444E6BB; Thu, 30 Jan 2014 15:01:00 +0200 (EET) Message-ID: <52EA4D0C.3060201@nomadiclab.com> Date: Thu, 30 Jan 2014 15:01:00 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Magnus Westerlund , "mmusic (E-mail)" References: <52DFCF18.8080104@ericsson.com> In-Reply-To: <52DFCF18.8080104@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat: ICE restart fails, then what? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 13:01:08 -0000 Hi Magnus, I agree that one should not terminate existing session that works just because an ICE restart fails. I think the text you quoted is rather for a situation where this is the first session and there are no existing (working) sessions. Hence, your text proposal looks good to me, with a few nits (see inline). On 22/01/14 16:00, Magnus Westerlund wrote: [...] > Thus my current proposal for Section 6.12 of draft-ietf-mmmusic-rtsp-nat > is the following: > > If the RTSP session is in playing state at the time of sending the > SETUP request requiring ICE restart, then the ICE connectivity checks > SHALL use Regular nomination. Any ongoing media delivery continues > on the previously nominated candidate pairs until the new pairs have > been nominated for the individual candidate. Once the nomination of "nominating pairs for candidate" sounds a bit strange. Should that be e.g., "nominated for the individual stream"? > the new candidate pair has completed, all unused candidates may be > released. If the ICE processing fails and no new candidate pairs are > promoted for use, then one MAY continue to use the previously s/promoted/nominated/ > nominated candidate pairs while they still function. If they have s/have// > appear to fail to transport media packets anymore then the client can > select between two actions. First, if it has any actions available > that might make ICE work, like trying another STUN/TURN server or > change the transport parameters it modifies the session, and if ICE > is still to be used restart ICE. The sentence above probably needs some more commas in right places (or maybe break it in pieces). Cheers, Ari From balmenyh@cisco.com Thu Jan 30 05:30:15 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9B51A0230 for ; Thu, 30 Jan 2014 05:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C495St7k_Jgx for ; Thu, 30 Jan 2014 05:30:14 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id CF5CE1A01FC for ; Thu, 30 Jan 2014 05:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1587; q=dns/txt; s=iport; t=1391088610; x=1392298210; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=C9uAyZ1lyPA7+GERYW5SV81bZ1M5ndB03l+Vnr9a4oY=; b=gpN4Uwq3EauKs8M+oYb90ocldt/jaxmvANyocr2t0lDkFLgNkcKXWi4f bBF454ASNd0jG+GlW7oZooBvVChj0AlxUANLDZKjg1btUOKh7NyWWl8qw LkM4LuHrcDWfoXj1Ce2lAKIwPcP5tIBRDvBRgOn1QUHXiWUOZYplib2MF s=; X-IronPort-AV: E=Sophos;i="4.95,750,1384300800"; d="scan'208";a="3752169" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 30 Jan 2014 13:30:10 +0000 Received: from [64.103.81.63] ([64.103.81.63]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0UDU989015205; Thu, 30 Jan 2014 13:30:09 GMT Message-ID: <52EA53E1.20701@cisco.com> Date: Thu, 30 Jan 2014 13:30:09 +0000 From: Balint Menyhart Organization: Cisco Systems Ltd. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mmusic (E-mail)" , "Pal Martinsen (palmarti)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Candidate priority in draft-reddy-mmusic-ice-happy-eyeballs-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 13:30:15 -0000 Hi, This is a comment related to http://www.ietf.org/id/draft-reddy-mmusic-ice-happy-eyeballs-05.txt. Section 4 states: ICE [RFC5245] section 4.1.2.2 has guidelines for how the type preference value should be chosen. Instead of having a static value for IPv4 and a static value for IPv6 type of addresses, it is possible to choose this value dynamically in such a way that IPv4 and IPv6 address candidate priorities ends up intermingled. The local and remote agent can have different algorithms for choosing the type preference value without any impact on coordination between the local and remote check list. I believe the intention here was to reference the local preference, instead of the type preference. The former is meant to distinguish between network interfaces from which the candidates have been gathered, while the later was intended to distinguish the type of the candidate obtained. It sounds to me, that IPv4 / IPv6 difference falls therefore in the local preference category, and not the type preference. From a different perspective, applying the formula given above: priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID) it also makes sense to "play" with the less significant bits, which are the local preference, as opposed to the more significant bits, which are the type preference. This will indeed lead to a finer grained intermingling of the IPv4 and IPv6 candidates. Regards, Balint From magnus.westerlund@ericsson.com Thu Jan 30 05:45:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF651A028B for ; Thu, 30 Jan 2014 05:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un1Kd9EwOU2M for ; Thu, 30 Jan 2014 05:45:39 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 98E2C1A0270 for ; Thu, 30 Jan 2014 05:45:38 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-c7-52ea577e03bb Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id FA.8D.04853.E775AE25; Thu, 30 Jan 2014 14:45:34 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.347.0; Thu, 30 Jan 2014 14:45:34 +0100 Message-ID: <52EA577E.8090200@ericsson.com> Date: Thu, 30 Jan 2014 14:45:34 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ari Keranen , "mmusic (E-mail)" References: <52DFCF18.8080104@ericsson.com> <52EA4D0C.3060201@nomadiclab.com> In-Reply-To: <52EA4D0C.3060201@nomadiclab.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+JvjW5d+KsggzNrVCza3vxis2h/c4TJ YuryxywOzB5Llvxk8uhcFO3x5fJntgDmKC6blNSczLLUIn27BK6MlW8/sxSsFa6YtHkNYwNj K38XIyeHhICJxNx3k5kgbDGJC/fWs3UxcnEICZxglLh64gcThLOcUWLX7v1sIFW8AtoS12Z+ ZwSxWQRUJRa09LKA2GwCFhI3fzSC1YgKBEvcmvaAHaJeUOLkzCdANRwcIkDxL/tMQExmAX2J ae80QSqEBQIlVtybyQYSFhLwlbjwxB4kzCmgJ/G38RATSFhCQFyipzEIJMwMFJ5ytYURwpaX aN46mxnEFgK6q6Gpg3UCo9AsJGtnIWmZhaRlASPzKkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8 PL3i1E2MwNA+uOW30Q7Gk3vsDzFKc7AoifNeZ60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cCoI7llLgfTHu9VPt8Czkw9LS88LWrvlQ+z97351WR0w7sz9551tW0m+9+81Ue5Fgf/NGqZ VTXhhd7bw3O+9SwWbdKVP17FLaO1Vmx55tWVx25vCQo4LDsz9vj99890o8xzCneanvn0zmRm bpOQH4v4B6W6mMSDiddOfgudsLBtt0pmWPCn+p5FSizFGYmGWsxFxYkAG/UyTDsCAAA= Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat: ICE restart fails, then what? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 13:45:40 -0000 On 2014-01-30 14:01, Ari Keranen wrote: > Hi Magnus, > > I agree that one should not terminate existing session that works just > because an ICE restart fails. I think the text you quoted is rather for > a situation where this is the first session and there are no existing > (working) sessions. > > Hence, your text proposal looks good to me, with a few nits (see inline). Thanks for the review, I will fix the nits and push a new version. Cheers Magnus > > On 22/01/14 16:00, Magnus Westerlund wrote: > [...] >> Thus my current proposal for Section 6.12 of draft-ietf-mmmusic-rtsp-nat >> is the following: >> >> If the RTSP session is in playing state at the time of sending the >> SETUP request requiring ICE restart, then the ICE connectivity checks >> SHALL use Regular nomination. Any ongoing media delivery continues >> on the previously nominated candidate pairs until the new pairs have >> been nominated for the individual candidate. Once the nomination of > > "nominating pairs for candidate" sounds a bit strange. Should that be > e.g., "nominated for the individual stream"? > >> the new candidate pair has completed, all unused candidates may be >> released. If the ICE processing fails and no new candidate pairs are >> promoted for use, then one MAY continue to use the previously > > s/promoted/nominated/ > >> nominated candidate pairs while they still function. If they have > s/have// > >> appear to fail to transport media packets anymore then the client can >> select between two actions. First, if it has any actions available >> that might make ICE work, like trying another STUN/TURN server or >> change the transport parameters it modifies the session, and if ICE >> is still to be used restart ICE. > > The sentence above probably needs some more commas in right places (or > maybe break it in pieces). > > > Cheers, > Ari > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 ari.keranen@ericsson.com Thu Jan 30 06:25:45 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7A41A03E1 for ; Thu, 30 Jan 2014 06:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdJp0P1sEqKJ for ; Thu, 30 Jan 2014 06:25:45 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 09B1B1A03C7 for ; Thu, 30 Jan 2014 06:25:38 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-61-52ea60dfeb5c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6E.23.04249.FD06AE25; Thu, 30 Jan 2014 15:25:35 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Thu, 30 Jan 2014 15:25:34 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B93131102A9; Thu, 30 Jan 2014 16:25:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 952DD56845; Thu, 30 Jan 2014 16:25:30 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 46EA94F4CA; Thu, 30 Jan 2014 16:25:30 +0200 (EET) Message-ID: <52EA60DD.9090402@ericsson.com> Date: Thu, 30 Jan 2014 16:25:33 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+Jvje79hFdBBq+3ClksOt7OYvH+gq7F 1OWPWRyYPab83sjqsWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBlLO9dw1bwgadi7qQOxgbG Nq4uRk4OCQETiY9rd7ND2GISF+6tZ+ti5OIQEjjCKHH221wWCGcDo8SXRa1Qzh5Gibt/fjNC OGsZJX4ducUK4SxnlLj/YhJzFyMHB6+AtsT5ngCQuSwCqhI/PxwF28EmYC9xc8J1MFtUIFni 0bbpzCA2r4CgxMmZT1hAbBEBQ4ktG8+xgdjMAjISM842MoHYwgL6EucmTGaCiNtKXJhznQXC lpfY/nYOM8QPahJXz20Cs4WA9l7994pxAqPwLCQrZiFpn4WkfQEj8ypGjuLU4qTcdCODTYzA 4D645bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTFpA4PB kseVB6xMX/6ZPKHuec0WC88l3xP2Lmu9m6MdI7fdafKrSW/EXqZ6LVi1avmD/y/+3nzyR39W iu67A90dLj9/9XK5b39d3m2lvlxL/XrIVqe+qPdTz1yz6vOTLX8YZcIl/c6i5rDfQ6GIo2ut Xp8WOjslKkaUR0p93/XfuUuzrmZImoQpsRRnJBpqMRcVJwIA58HzvDwCAAA= Cc: mmusic Subject: [MMUSIC] draft-ietf-mmusic-udptl-dtls-03 review X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 14:25:46 -0000 Hi, I reviewed the UDPTL DTLS draft and overall it seems to be in good shape. Please find below a few (mostly editorial) comments to consider. 1. Introduction This was mainly because of the challenges involved with physical access to telephony equipment. s/physical access/malevolent physical access/ (or something else saying that there's an unauthorized accessing for making an attack in question) This document specifies the transport of UDPTL over DTLS using the DTLS record layer "application_data" packets [RFC6347]. "application_data" is actually defined in the TLS RFC (5246) and 6347 doesn't mention that name (as such) at all. Maybe having both RFCs as reference makes sense. 4.2.2. Latching Control without ICE and the passive MUST NOT wait for a STUN answer before sending its s/passive/passive side/ Moreover, the term "Latching" may not be obvious for everyone. Do you mean the same as in draft-ietf-mmusic-latching? A sentence explaining this could help or alternatively changing the title to more descriptive one. 4.2.3. STUN Interaction The UA MUST demultiplex packets arriving on the IP address and port associated with the DTLS association as follows: Why is this a MUST? Wouldn't other ways be OK too (say, magic cookie)? Maybe s/MUST/can/? A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in An Existing Audio-Only Session Traditionally, most session with non-secure transport of T.38 fax, transported using UDPTL, are established by modifying an ongoing s/session/sessions/ Cheers, Ari From internet-drafts@ietf.org Thu Jan 30 06:28:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD621A03E1; Thu, 30 Jan 2014 06:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdvvwkvhV2FS; Thu, 30 Jan 2014 06:28:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8378B1A03C2; Thu, 30 Jan 2014 06:28:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140130142851.27536.84134.idtracker@ietfa.amsl.com> Date: Thu, 30 Jan 2014 06:28:51 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-19.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 14:28:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : A Network Address Translator (NAT) Traversal Mech= anism for Media Controlled by Real-Time Streaming Protocol (RTSP) Authors : Jeff Goldberg Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-19.txt Pages : 32 Date : 2014-01-30 Abstract: This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams set up and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary RTSP extensions and procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Thu Jan 30 06:34:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577F21A03EF for ; Thu, 30 Jan 2014 06:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxQqF3DdNpde for ; Thu, 30 Jan 2014 06:34:53 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B851C1A0398 for ; Thu, 30 Jan 2014 06:34:52 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-7f-52ea6308e49a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 25.B1.10875.8036AE25; Thu, 30 Jan 2014 15:34:48 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Thu, 30 Jan 2014 15:34:48 +0100 Message-ID: <52EA6308.4060702@ericsson.com> Date: Thu, 30 Jan 2014 15:34:48 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20140130142851.27536.84134.idtracker@ietfa.amsl.com> In-Reply-To: <20140130142851.27536.84134.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+JvjS5H8qsgg5W/bSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN19R5gKzglXTDp3i72BcRN/FyMnh4SAicS1X23MELaYxIV7 69m6GLk4hAQOMUocX/qOGcJZziix6sNmNpAqXgFtidU7/gPZHBwsAqoSW6+ADWITsJC4+aMR rERUIFji1rQH7BDlghInZz5hAbFFBNQlWjf3sYLYwgJWElv2rWQCsYUEHCU2PbkKZnMKOEm8 6P/MDjJeQkBcoqcxCCTMLKAnMeVqCyOELS/RvHU2M0SrtkRDUwfrBEbBWUi2zULSMgtJywJG 5lWM7LmJmTnp5YabGIHBd3DLb90djKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDo1PBqq+FS6UlvQK1X4Qv+sh+ctPKe3NaWPvTVOOzRX5Z6MbymAWfC27cuUtw V4XqG5ePBkuOGAutm8F+YOGE9/vurtW+cEfKS/zMqY/vqh6Zmi5fwslmu2Xytjmv5Wat7VGp 3pDDGit8/XqJZf3ByJlfjB6fy9R6zSGcErDz7qWrKqrT835m31diKc5INNRiLipOBAC5sVS4 DAIAAA== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-19.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 14:34:58 -0000 Hi, This version just addresses some nits from Ari. Cheers Magnus On 2014-01-30 15:28, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP) > Authors : Jeff Goldberg > Magnus Westerlund > Thomas Zeng > Filename : draft-ietf-mmusic-rtsp-nat-19.txt > Pages : 32 > Date : 2014-01-30 > > Abstract: > This document defines a solution for Network Address Translation > (NAT) traversal for datagram based media streams set up and > controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). > It uses Interactive Connectivity Establishment (ICE) adapted to use > RTSP as a signalling channel, defining the necessary RTSP extensions > and procedures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-19 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-19 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Fri Jan 31 02:25:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9BA1A0579; Fri, 31 Jan 2014 02:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCYrArnr5nmj; Fri, 31 Jan 2014 02:25:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3211A041B; Fri, 31 Jan 2014 02:25:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 02:25:00 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 10:25:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For = Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The = Public Switched Telephone Network (PSTN) Authors : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-22.txt Pages : 37 Date : 2014-01-31 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Simo.Veikkolainen@nokia.com Fri Jan 31 03:02:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618F21A0579 for ; Fri, 31 Jan 2014 03:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfe_zH1a1oOH for ; Fri, 31 Jan 2014 03:02:10 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C1EF81A0571 for ; Fri, 31 Jan 2014 03:02:10 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.61]) by mgw-da02.nokia.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s0VB1Us4023814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 31 Jan 2014 13:01:32 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.45]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.03.0158.002; Fri, 31 Jan 2014 11:01:32 +0000 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt Thread-Index: AQHPHm620e/80jfD1UW9be2tq4vEmZqeqHFw Date: Fri, 31 Jan 2014 11:01:31 +0000 Message-ID: References: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> In-Reply-To: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.25.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only; x-headerinfofordlp: x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoztK79W28gvbdMo7B6DfwsdIR06An8I2UDaQmd03UvWU/z766xNMvXCWBc/yMePYh9E3LHHoRlj/n/KGMxQ5JffG5PvgAQH9b7MhVy4fOn+n/wJ3kpRIUyWyJHQ9mcKulcD02R+PmCSEzQiYIejxmuhoaSAtKyoQ7Oii5FcJoVQdr7IeXNR+tGYjMYiR/Eg8RNtVnO1a8zXlvWnAgDbJ1cteVmoj2CI0FIYn29q/Yay x-originating-ip: [172.21.80.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Cc: gonzalo.camarillo@ericsson.com Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jan 2014 11:02:13 -0000 Hello WG, We have submitted a new version of http://tools.ietf.org/html/draft-ietf-mm= usic-sdp-cs-22=20 To recap, there was discussion on the MMUSIC WG list on which correlation = mechanisms should be mandatory to implement (see Gonzalo's email http://www= .ietf.org/mail-archive/web/mmusic/current/msg12274.html ). As stated by Gon= zalo, 3GPP is going to use this draft, more specifically the plan now is to= use the caller id based correlation mechanism. This was the message I got = from Andrew after a recent 3GPP CT1 meeting. We have now made the following changes to the draft: - the endpoint may choose which correlation mechanisms to implement (before= all three were MTI). - we have introduced a fourth correlation type ("external") which indicates= explicit support for cases where also some external means, typically the h= uman user, can do the correlation. This can be as a fallback in cases where= no other common correlation mechanism is found, or the negotiated correlat= ion mechanisms fail due to being not supported in the PSTN network. This is= much like current systems like Webex work. This was also the guidance from the IESG informal telechat in December wher= e Gonzalo presented the draft. We would like to hear from the WG whether there are any concerns with these= changes. On behalf of the authors, Simo PS. I'll add the proposed change in http://www.ietf.org/mail-archive/web/mm= usic/current/msg12792.html to next version, slipped my mind this time. -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext internet-dra= fts@ietf.org Sent: 31 January, 2014 12:25 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For = Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The = Public Switched Telephone Network (PSTN) Authors : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-22.txt Pages : 37 Date : 2014-01-31 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-22 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Jan 31 03:56:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E21A0594 for ; Fri, 31 Jan 2014 03:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTdmXD-RVwes for ; Fri, 31 Jan 2014 03:56:43 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCED1A0588 for ; Fri, 31 Jan 2014 03:56:42 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-09-52eb8f757204 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C0.B7.23809.57F8BE25; Fri, 31 Jan 2014 12:56:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Fri, 31 Jan 2014 12:56:37 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "draft-ietf-mmusic-udptl-dtls@tools.ietf.org" Thread-Topic: draft-ietf-mmusic-udptl-dtls-03 review Thread-Index: AQHPHcckatfvrQ/Cl0um0naW4oLZXpqeu1cg Date: Fri, 31 Jan 2014 11:56:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D151248@ESESSMB209.ericsson.se> References: <52EA60DD.9090402@ericsson.com> In-Reply-To: <52EA60DD.9090402@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvjW5Z/+sggz+TOCwWHW9nsZi6/DGL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxfV8vc8Ej4YqVi7uZGxjP8ncxcnJICJhI vGi4zgphi0lcuLeerYuRi0NI4BCjxNrZU6GcxYwShztWsXQxcnCwCVhIdP/TBomLCMxjlFj4 eg5YN7OAjMSMs41MILawgLHEtsVfwGwRoA0Hm/YwQ9hGEisPnGUHmcMioCrR3SMKEuYV8JU4 vuAYWImQgLbEjPXb2UBsTgEdiduPV4DZjEDHfT+1hglilbjErSfzmSCOFpBYsuc8M4QtKvHy 8T+oZxQldp5tZ4ao15O4MXUKG4StLbFs4WtmiL2CEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEj yypG9tzEzJz0cqNNjMAYObjlt+oOxjvnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBMW2+6RxPpQ0Trt/04Tr25KTwtPmM8XpGbnvjnv0/dJLJKeT8F3uH8/+KRGcp rS7lsOFINv59R37ra/4DbQY/p4l51lofKHvdyuXiZmnAzXhvncWkaR5zL/OmHRIP8n3pFuH5 p5lV+Laq7Mr69bKNUntMH7RWRn3Jst0pUnWkyNu8+QTLHvu5SizFGYmGWsxFxYkAv0CLL18C AAA= Cc: mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-udptl-dtls-03 review X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jan 2014 11:56:44 -0000 Hi Ari, Thanks for your review! Comments inline. > 1. Introduction > > This was mainly because of the challenges involved with > physical access to telephony equipment. > > s/physical access/malevolent physical access/ (or something else=20 > saying that there's an unauthorized accessing for making an attack in > question) I will change as suggested. > This document specifies the transport of UDPTL over DTLS using the > DTLS record layer "application_data" packets [RFC6347]. > > "application_data" is actually defined in the TLS RFC (5246) and 6347=20 > doesn't mention that name (as such) at all. Maybe having both RFCs as=20 > reference makes sense. I suggest the following modification: "This document specifies the transport of UDPTL over DTLS using the DTLS record layer "application_data" packets [RFC5246] [RFC6347]." --------------------------- > 4.2.2. Latching Control without ICE > > and the passive MUST NOT wait for a STUN answer before sending its > > s/passive/passive side/ I will change as suggested. > Moreover, the term "Latching" may not be obvious for everyone. Do you=20 > mean the same as in draft-ietf-mmusic-latching? A sentence explaining=20 > this could help or alternatively changing the title to more descriptive o= ne. I would rather suggest to change the section titles, as following: 4.2.1. NAT Traversal With ICE 4.2.2. NAT Traversal Without ICE ...because, the text doesn't really talk so much about latching per se, but= more about the opening of pin holes etc. --------------------------- > 4.2.3. STUN Interaction > The UA MUST demultiplex packets arriving on the IP address and port > associated with the DTLS association as follows: > > Why is this a MUST? Wouldn't other ways be OK too (say, magic cookie)?=20 > Maybe s/MUST/can/? I suggest to add "e.g.", to show that the documented demux mechanism is onl= y one way it can be done. "The UA MUST demultiplex packets arriving on the IP address and port associated with the DTLS association, e.g. as follows:" --------------------------- > A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in An > Existing Audio-Only Session > > Traditionally, most session with non-secure transport of T.38 fax, > transported using UDPTL, are established by modifying an ongoing > > s/session/sessions/ I will change as suggested. --------------------------- Thanks! Regards, Christer From ari.keranen@ericsson.com Fri Jan 31 05:41:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D701A058B for ; Fri, 31 Jan 2014 05:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-z6lY0cBb2P for ; Fri, 31 Jan 2014 05:41:08 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B91931A049B for ; Fri, 31 Jan 2014 05:41:07 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-58-52eba7ef838b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 99.47.04249.FE7ABE25; Fri, 31 Jan 2014 14:41:03 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.347.0; Fri, 31 Jan 2014 14:41:03 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1F196110458; Fri, 31 Jan 2014 15:41:03 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 18F4A56862; Fri, 31 Jan 2014 15:40:59 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C2BC856824; Fri, 31 Jan 2014 15:40:58 +0200 (EET) Message-ID: <52EBA7EE.6040609@ericsson.com> Date: Fri, 31 Jan 2014 15:41:02 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "draft-ietf-mmusic-udptl-dtls@tools.ietf.org" References: <52EA60DD.9090402@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D151248@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D151248@ESESSMB209.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+Jvje775a+DDNrXK1ssOt7OYjF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvjbxN3wWLRio5F1g2M1wW6GDk5JARMJOb+ nMsOYYtJXLi3nq2LkYtDSOAIo8SLW3+ZIZwNjBJTb01mgnD2MEpsP3ePEcJZyyix7MhkKGc5 o8SpnRvAhvEKaEtM7VzKCGKzCKhKPH74iRnEZhOwl7g54TpYjahAssSjbdOZIeoFJU7OfMIC MkhEYDqjxIezn8GKmAVkJGacbWQCsYUFjCWmbNjEBmILCeRK9NzsB2vmFPCT+PLjHhNEva3E hTnXWSBseYntb+cwQ3ynJnH13CZmiF5Viav/XjFOYBSdhWT3LCTts5C0L2BkXsXIUZxanJSb bmSwiREY+ge3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MLq9j+A3E1r54Sy7xF6zTdOayx71PjgUt+jrH/Pfc6afVYxZMSntxb2d97YZMjIu2CbSVzU9 QuM6c0boy1inpQrrzGL/KV0P7o4rKuneaMGzui3ku3ShycddO8/9ZeRf9b+L0aPJYvfS6vu/ D/S94cuYP+tHcsi9f8aGjT+eOPl7uiZ++a7lpKPEUpyRaKjFXFScCABIsscBSwIAAA== Cc: mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-udptl-dtls-03 review X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jan 2014 13:41:09 -0000 Hi Christer, Looks good, thanks! Cheers, Ari On 31/01/14 13:56, Christer Holmberg wrote: > Hi Ari, > > Thanks for your review! Comments inline. > >> 1. Introduction >> >> This was mainly because of the challenges involved with >> physical access to telephony equipment. >> >> s/physical access/malevolent physical access/ (or something else >> saying that there's an unauthorized accessing for making an attack in >> question) > > I will change as suggested. > >> This document specifies the transport of UDPTL over DTLS using the >> DTLS record layer "application_data" packets [RFC6347]. >> >> "application_data" is actually defined in the TLS RFC (5246) and 6347 >> doesn't mention that name (as such) at all. Maybe having both RFCs as >> reference makes sense. > > I suggest the following modification: > > "This document specifies the transport of UDPTL over DTLS using the > DTLS record layer "application_data" packets [RFC5246] [RFC6347]." > > > --------------------------- > >> 4.2.2. Latching Control without ICE >> >> and the passive MUST NOT wait for a STUN answer before sending its >> >> s/passive/passive side/ > > I will change as suggested. > >> Moreover, the term "Latching" may not be obvious for everyone. Do you >> mean the same as in draft-ietf-mmusic-latching? A sentence explaining >> this could help or alternatively changing the title to more descriptive one. > > I would rather suggest to change the section titles, as following: > > 4.2.1. NAT Traversal With ICE > 4.2.2. NAT Traversal Without ICE > > ...because, the text doesn't really talk so much about latching per se, but more about the opening of pin holes etc. > > --------------------------- > >> 4.2.3. STUN Interaction >> The UA MUST demultiplex packets arriving on the IP address and port >> associated with the DTLS association as follows: >> >> Why is this a MUST? Wouldn't other ways be OK too (say, magic cookie)? >> Maybe s/MUST/can/? > > I suggest to add "e.g.", to show that the documented demux mechanism is only one way it can be done. > > "The UA MUST demultiplex packets arriving on the IP address and port > associated with the DTLS association, e.g. as follows:" > > --------------------------- > >> A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in An >> Existing Audio-Only Session >> >> Traditionally, most session with non-secure transport of T.38 fax, >> transported using UDPTL, are established by modifying an ongoing >> >> s/session/sessions/ > > I will change as suggested. > > --------------------------- > > Thanks! > > Regards, > > Christer > From palmarti@cisco.com Fri Jan 31 05:44:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9471A0193 for ; Fri, 31 Jan 2014 05:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.736 X-Spam-Level: X-Spam-Status: No, score=-14.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekZo0O7HrZha for ; Fri, 31 Jan 2014 05:44:41 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F2B971A011B for ; Fri, 31 Jan 2014 05:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5497; q=dns/txt; s=iport; t=1391175877; x=1392385477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BFotr30lzC0RktPW4WrY+cg2YtY/PE/nmKVatlXfmDI=; b=SgqyP2Idte4K/BsS81v0p96NP8KksjIe4C+nJxSpKjRl8YN/LGqrxqdK ntLI/BPOpLKmr4yy3mUT8s7AhzS+twfjSTUfqvFv5F5XFwWDYjtdlqKkP LAj/grqAxNNQWoARqqSpOOBoC97k/f8ivRF0CRC/a4WOg6dyZWav4YM/9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAGao61KtJXHB/2dsb2JhbABZgww4V704gQYWdIIlAQEBAwEnUAIFCwIBCBguMiUCBA4FG4diCA3MLRMEjk8zB4MkgRQBA5gqkiGBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,758,1384300800"; d="scan'208";a="300985984" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jan 2014 13:44:37 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0VDiboV024716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jan 2014 13:44:37 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.190]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 07:44:36 -0600 From: "Pal Martinsen (palmarti)" To: =?Windows-1252?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt Thread-Index: AQHPEFUUlb4N8W3Wl06M5kiJnPk5wZqUXPIAgAZGcwCAAv8DgIABtqYA Date: Fri, 31 Jan 2014 13:44:36 +0000 Message-ID: <37A6AA83-867F-4DD1-A79D-081ECFA23B22@cisco.com> References: <20131209121243.31704.62698.idtracker@ietfa.amsl.com> <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> <52D01911.8030804@ericsson.com> <647464EE-B8E0-47FA-A375-8C758046D854@cisco.com> <7C0E6D63-D816-4415-B621-73A0309C6AB2@cisco.com> <52EA38C9.4070003@ericsson.com> In-Reply-To: <52EA38C9.4070003@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.69] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jan 2014 13:44:43 -0000 On 30 Jan 2014, at 12:34 pm, Ari Ker=E4nen wrote= : > Hi, >=20 > On 28/01/14 15:49, Pal Martinsen (palmarti) wrote: >> Just posted -05 version of the draft. >=20 > Thanks! Here's a few comments on the latest version. >=20 > The abstract says: >=20 >> This document provides guidelines on how to make ICE [RFC5245] >> conclude faster in IPv4/IPv6 dual-stack scenarios where broken paths >> exist. This will lead to more sustained IPv6 deployment as users >> will no longer have an incentive to disable IPv6. >=20 > Out of (much of) context, especially the second sentence seems like a qui= te strong statement. I guess there could be other reasons than this for dis= abling v6, for example. Agree. Sentence removed. >=20 > And nit: usually abstract should not contain references and open the ICE = acronym. >=20 Fixed. >> An ICE agent can choose an algorithm or a technique of its choice to >> ensure that the resulting check lists have a fair intermingled mix of >> IPv4 and IPv6 address families. Modifying the check list directly >> can lead to uncoordinated local and remote check lists that result in >> ICE taking longer to complete. >=20 > Not only can the tests take longer, but they can potentially also fail if= the lists get badly out of sync since once you have made a NAT binding wit= h a connectivity check packet, the check to other direction must come befor= e the binding expires. But I suppose this will not be a problem with the pr= oposed solution since the lists will be in sync? >=20 Added failure as well to further scare the reader. :-) And yes, the list must be kept in sync. >> The local and remote agent can have different algorithms for choosing >> the type preference value without any impact on coordination between >> the local and remote check list. >=20 > What do you mean by "without any impact on coordination=94? kept in sync? New text: The local and remote agent can have different algorithms for choosing the local preference value without impacting the synchronisation between the local and remote check list. >=20 >> Where G is the candidate provided by the controlling agent and D the >=20 > s/candidate/priority of the candidate/ >=20 tnx >> Do we ask for WG adoption, or do we need another MMUSIC session discussi= ng this? >=20 > Given this new approach, I think it's too early to ask for WG adoption. R= ather we need more discussion especially here on the list and possibly at t= he meeting. >=20 Ok.=20 Just a bit afraid of wasting cycles if this proves to not so useful.=20 > What I would find helpful for discussion is that if you could provide a s= tep-by-step example of how the candidate lists are formed and connectivity = checks done in cases where a) both support this with same promo algo b) bot= h support this but with different promo algo c) only one endpoint supports = this. >=20 As I do believe in running code, I wrote a simple implementation of the alg= orithm described below. It can be downloaded from: https://github.com/palerikm/HappyE-ICE-Test >From README: Compiling =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Run ./bootstrap to create the configure script. then do ./configure and =20 make Running =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There are two txt files with candidates. One with local candidates where pr= iorities needs to be calculated and a predefined remote candidate file. (Pl= ease Note parsing is crude so keep the files clean..) the program can be run as follows: src/icehetest 4 candidates.txt remoteCandidates.txt=20 4 indicates the number of concecutive candidates if same address type allow= ed. > Also maybe a recommended promo algo would make sense so that there is at = least a fair chance that both will use the same algo/values and get most ou= t of this. >=20 First shot an an algorithm: 5. Example Algorithm for Choosing the Local Preference The value space for the local preference is from 0 to 65535 inclusive. This value space can be divided up in chunks for each IP address family. An IPv6 and IPv4 start priority must be given. In this example IPv6 starts at 60000 and IPv4 at 59000. This leaves enough address space to further play with the values if pr interface priorities needs to be added. The highest value should be given to the address family that should be prioritized. IPv6 IPv4 Start Start 65535 60k 59k 58k 57k 56k 55k 0 +--------+------+------+------+------+------+---------------------+ | | IPv6 | IPv4 | IPv6 | IPv4 | IPv6 | | | | (1) | (1) | (2) | (2) | (3) | | +--------+------+------+------+------+------+---------------------+ <- N-> =20 The local preference can be calculated by the given formula: local_preference =3D N*2*(Cn/Cmax) Where N is the absolute value of IPv6_start-IPv4_start. This ensures a positive number even if IPv4 is the highest priority. Cn is the number of current candidates of a specific IP address type and candidate type (HOST, SRFLX, RELAY). Cmax is the number of allowed consecutive candidates of the same IP address type. .-. P=E5l-Erik >=20 > Cheers, > Ari >=20 From agensler@cisco.com Fri Jan 31 09:09:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115EE1A0416 for ; Fri, 31 Jan 2014 09:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clR3MHOmet4U for ; Fri, 31 Jan 2014 09:09:56 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB1D1A0367 for ; Fri, 31 Jan 2014 09:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4356; q=dns/txt; s=iport; t=1391188193; x=1392397793; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=M4fSxyXxVGqlo2lAK973Qdbq7GvXQysndh+l5iQSb+8=; b=jvJawa9Kj38ECAhREyMjRDWT3/tevoQpyJiQNpmsBAJ4/qQ/09d2IClU w+gChN42rl6AIkTS9oVh9XZrX5B8sdsTS87IluXqV+0kXaY6579MRCA2E 5kRDpBwN0fc+4vGJ7Qu4/bSaq625g7XguE1gWaa8+Ry9upC4lKyCTp22w U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEDY61KtJV2c/2dsb2JhbABZgww4V704gQwWdIIlAQEBAwE6PxACAQg2EDIlAgQBDQWHfQgNzHAXjwIHhDgElEKDaIEykG+DLYIq X-IronPort-AV: E=Sophos;i="4.95,758,1384300800"; d="scan'208";a="17036093" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 31 Jan 2014 17:09:52 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0VH9qJ2021523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jan 2014 17:09:52 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.32]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 11:09:52 -0600 From: "Adam Gensler (agensler)" To: Christer Holmberg , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: Review of draft-ietf-mmusic-udptl-dtls-03 Thread-Index: AQHPF6Z7X1rBlQF7JUm0AYYGqOYxvZqRgxMAgAn+m0CAA65LAA== Date: Fri, 31 Jan 2014 17:09:51 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D148F76@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D148F76@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.150.21.213] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 31 Jan 2014 09:21:53 -0800 Cc: mmusic Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jan 2014 17:11:38 -0000 Christer, Sorry for the delay, I've been offline for a few days. See inline with [adam]: On 1/29/14, 4:58 AM, "Christer Holmberg" wrote: >Hi Adam, > >Again, thanks for your review! See my comments inline. > >> After speaking with Gonzalo I've reviewed >>draft-ietf-mmusic-udptl-dtls-03. >> Overall this draft is excellent and appears to cover all the corner >> cases I could think of. I do have a few comments, see below: >>=20 >> 1. In section 3.1, secure channel establishment, there is the >> following text: >>=20 >> "If the endpoint supports, and is willing to use, a cipher suite with >> an associated certificate, it MUST include an SDP fingerprint >> attribute [RFC4572 ] in the SDP." >>=20 >> "If a cipher suite with an associated certificate is selected during >> the DTLS handshake, the certificate received during the DTLS handshake >> MUST match the fingerprint received in the SDP fingerprint attribute." >>=20 >> To me this seems to indicate the particular cipher suites are >> associated with a particular certificate. While it's true that the >> certificate plays a role in overall TLS negotiation, it does not >> provide a list of ciphers to use. > >The intention of the text is NOT to indicate that a particular cipher >suites are associated with a particular certificate. > >> I think what this is saying is that >> if the client wishes to use a certificate for DTLS it should provide a >> certificate fingerprint. Is that right? > >Only if the cipher suite has an associated certificate. > >But, e.g. a PSK based cipher suite (RFC4279) has no associated >certificate and thus there is no point of indicating certificate >fingerprint for PSK based cipher suite. > >> Given the overall complexity of PKI in general I think being extra >>clear here would help avoid any confusion. > >We did spend quite a bit of time on this part of the text, and I can't >see what modifications I should do in order to make it more clear. > >------------------------ [adam] Thanks for the clarification here. Given this extra context I agree and I'm not sure how to adjust this any further. > >> 2. Section 4.1 describes handling anonymous faxes with freshly >> generated self-signed certificates. It goes on to say: >>=20 >> "...and the content of the subjectAltName attribute inside the >> certificate MUST NOT contain information that either allows >> correlation or identification of the user making anonymous calls." >>=20 >> While the subjectAltName could potentially have identifiable data in >> it, it is not always present as a field within the certificate. Some >> certificates may have a subjectAltName, some may not. However, all >> certificates should have a commonName. I think that is the item that >> should be specifically called out as a place to avoid identifiable >> information. Or, perhaps, simply stipulating that no fields within the >> certificate should contain identifiable information. > >That's a good point. > >What about something like: > > "...and attributes inside the certificate SHALL NOT >contain information that either allows correlation or > identification of the user making anonymous calls. This >is particularly important for the subjectAltName > and commonName attributes" > >------------------------ [adam] This sounds good to me. > >> 3. Section 4.3 describes rekeying a connection that is established. >> The DTLS RFC describes how to handle this, but gives two options to an >> endpoint where out-of-order packets are received that have been >> encrypted with different keys; discard the packet, or, retain two sets >> of keying material for some recommended interval. DTLS is not specific >> as to what to do here. Section 4.3 says the receiver SHOULD maintain >> the keying material. Given the nature of T.38, I think it may be >> prudent to say the receiver MUST maintain the keying material. >> Dropping and/or discarding >> T.38 packets would never be my preference. > >We can change it to MUST. > >------------------------ [adam] Perfect, I think that will help avoid any confusion around this, should the situation occur. > >Regards, > >Christer > > From christer.holmberg@ericsson.com Fri Jan 31 09:47:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C89D1A1F5E for ; Fri, 31 Jan 2014 09:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA9JKYWzYV0s for ; Fri, 31 Jan 2014 09:47:01 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E0ADA1A0576 for ; Fri, 31 Jan 2014 09:47:00 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-77-52ebe1902c0e Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9E.6F.23809.091EBE25; Fri, 31 Jan 2014 18:46:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Fri, 31 Jan 2014 18:46:56 +0100 From: Christer Holmberg To: "Adam Gensler (agensler)" , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: Review of draft-ietf-mmusic-udptl-dtls-03 Thread-Index: AQHPF6Z7X1rBlQF7JUm0AYYGqOYxvZqRgxMAgAn+m0CAA65LAP//+ZdY Date: Fri, 31 Jan 2014 17:46:55 +0000 Message-ID: <0nxaoid4ra4weq5j5tqsgx8y.1391190411748@email.android.com> References: <7594FB04B1934943A5C02806D1A2204B1D148F76@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvje6Eh6+DDBYcULJY+v0Om8XcKX4W U5c/ZnFg9pjyeyOrx5IlP5kCmKK4bFJSczLLUov07RK4MpobzzEXvFWuWPzmL0sD4ymZLkZO DgkBE4lDba2MELaYxIV769m6GLk4hAQOMUqsmPyDGcJZzCjx/e4/oCoODjYBC4nuf9ogDSIC mRJTd65jBbGZBWQkZpxtZAKxhQXMJI52rGKDqDGXaJ56lxHCdpNYt/MLWD2LgKrE1NXXwGp4 geLf7zQxQew6wSixccoesEGcAvoS1z/sBitiBLru+6k1TBDLxCVuPZnPBHG1gMSSPeeZIWxR iZeP/0EdpCOxYPcnNghbW2LZwtfMEMsEJU7OfMIygVF0FpJRs5C0zELSMgtJywJGllWM7LmJ mTnp5UabGIFRcXDLb9UdjHfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDI8u+D/83984T/Tgx5KIc+2Pxo0fjBXOmrYk/EKd4fOvNsiZr/keLtu+fuPTk3WOtbint uvcYI1hLpOYc3mUexOHwviBjVqBugIGL92+tTEPvL3P7NSe+kV7x8NiKpqO6XMs+nM3o2RcR +ICxZ5qS721v4acfzyjMeDJlffTDxnSXaasjygJ+1yuxFGckGmoxFxUnAgD2/pR+WAIAAA== Cc: mmusic Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jan 2014 17:47:03 -0000 Hi Adam, Thanks for your reply! We'll submit a new version of the draft, with the changes implemented, asap= :) Regards, Christer Sent from my Sony Ericsson Xperia arc S "Adam Gensler (agensler)" wrote: Christer, Sorry for the delay, I've been offline for a few days. See inline with [adam]: On 1/29/14, 4:58 AM, "Christer Holmberg" wrote: >Hi Adam, > >Again, thanks for your review! See my comments inline. > >> After speaking with Gonzalo I've reviewed >>draft-ietf-mmusic-udptl-dtls-03. >> Overall this draft is excellent and appears to cover all the corner >> cases I could think of. I do have a few comments, see below: >> >> 1. In section 3.1, secure channel establishment, there is the >> following text: >> >> "If the endpoint supports, and is willing to use, a cipher suite with >> an associated certificate, it MUST include an SDP fingerprint >> attribute [RFC4572 ] in the SDP." >> >> "If a cipher suite with an associated certificate is selected during >> the DTLS handshake, the certificate received during the DTLS handshake >> MUST match the fingerprint received in the SDP fingerprint attribute." >> >> To me this seems to indicate the particular cipher suites are >> associated with a particular certificate. While it's true that the >> certificate plays a role in overall TLS negotiation, it does not >> provide a list of ciphers to use. > >The intention of the text is NOT to indicate that a particular cipher >suites are associated with a particular certificate. > >> I think what this is saying is that >> if the client wishes to use a certificate for DTLS it should provide a >> certificate fingerprint. Is that right? > >Only if the cipher suite has an associated certificate. > >But, e.g. a PSK based cipher suite (RFC4279) has no associated >certificate and thus there is no point of indicating certificate >fingerprint for PSK based cipher suite. > >> Given the overall complexity of PKI in general I think being extra >>clear here would help avoid any confusion. > >We did spend quite a bit of time on this part of the text, and I can't >see what modifications I should do in order to make it more clear. > >------------------------ [adam] Thanks for the clarification here. Given this extra context I agree and I'm not sure how to adjust this any further. > >> 2. Section 4.1 describes handling anonymous faxes with freshly >> generated self-signed certificates. It goes on to say: >> >> "...and the content of the subjectAltName attribute inside the >> certificate MUST NOT contain information that either allows >> correlation or identification of the user making anonymous calls." >> >> While the subjectAltName could potentially have identifiable data in >> it, it is not always present as a field within the certificate. Some >> certificates may have a subjectAltName, some may not. However, all >> certificates should have a commonName. I think that is the item that >> should be specifically called out as a place to avoid identifiable >> information. Or, perhaps, simply stipulating that no fields within the >> certificate should contain identifiable information. > >That's a good point. > >What about something like: > > "...and attributes inside the certificate SHALL NOT >contain information that either allows correlation or > identification of the user making anonymous calls. This >is particularly important for the subjectAltName > and commonName attributes" > >------------------------ [adam] This sounds good to me. > >> 3. Section 4.3 describes rekeying a connection that is established. >> The DTLS RFC describes how to handle this, but gives two options to an >> endpoint where out-of-order packets are received that have been >> encrypted with different keys; discard the packet, or, retain two sets >> of keying material for some recommended interval. DTLS is not specific >> as to what to do here. Section 4.3 says the receiver SHOULD maintain >> the keying material. Given the nature of T.38, I think it may be >> prudent to say the receiver MUST maintain the keying material. >> Dropping and/or discarding >> T.38 packets would never be my preference. > >We can change it to MUST. > >------------------------ [adam] Perfect, I think that will help avoid any confusion around this, should the situation occur. > >Regards, > >Christer > > From pkyzivat@alum.mit.edu Fri Jan 31 10:52:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3211A03CC for ; Fri, 31 Jan 2014 10:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHbBeGUg7sxb for ; Fri, 31 Jan 2014 10:52:56 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4B11A0286 for ; Fri, 31 Jan 2014 10:52:56 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id LdKK1n0030ldTLk54isspx; Fri, 31 Jan 2014 18:52:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id Liss1n00E3ZTu2S01isskT; Fri, 31 Jan 2014 18:52:52 +0000 Message-ID: <52EBF104.7000303@alum.mit.edu> Date: Fri, 31 Jan 2014 13:52:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391194372; bh=FkjQsGq0fG7agzUxm++MIYkEEGEKazWOqR5WpWqcGNs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UsnnEMOZlikySA7DhxB9hanlJ69EWDMpN3lYAza6FYPNx++X9AoZRUXjBj/ytJygT LD8hqntBJrExRHg9CmpxKdeFDa7eXY8Bh7NXohmC+f5FnEsWX49tjwu+KbMMDs0g6R h/SJ0+mE27Ep2JSoqxSPnjv5U0W+LVUUDghOLKkJ/hZhztkGwIfykGDi7RoShG8W0p 8l+Tp+hDSo2RGXaUu6hkKHHeEjix6Rlb+KzzWufbLZvAnNljNrFGZ4XYUL96oW5Vd6 eQgwLhIvL0ztUuU9iLXu6QXJhTzU0cgXXyoszKQZuzkEE6/jxV8phK7vJxgTbte0kS NAsQyrjgUi6tQ== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jan 2014 18:52:59 -0000 I just reviewed the new version. First I looked at just the diffs. But those raised some more general questions in my mind, so I re-reviewed more of the draft. I'm left with some considerable confusion about how this is intended to work in practice, especially with extern correlation, but even with the other forms. In particular, I am unclear of the sequencing of O/A processing, correlation processing, and signaling completion. (I realize this is an mmusic draft and theoretically independent of sip, but forgive me if I discuss this in the context of sip.) Normally, when first establishing a session with sip, the first O/A may occur before the signaling session is established. But early media may flow after the first O/A. Often it is expected that the user will be be aware and involved in this early media. Once a session is up, it can be changed with a reinvite containing a new O/A. If the O/A and the reinvite are successful, then the results of the new O/A replace the old one. If the reinvite fails, then the session is supposed to continue as it was before the reinvite. In the interim, from the sending of the reinvite until its success or failure, things are a little confusing - presumably both old and new media streams must be maintained, but which are connected to the user is unspecified. I see nothing in this draft that explains how the CS media, and correlation verification, fit into the above process. Consider a new call that offers CS media: - The first O/A must complete before the CS call can be attempted. - must the CS call complete and be correlated successfully before the INVITE gets a 200? If the invite is allowed to complete first, what happens if no CS call is established, or if it is but correlation fails? - when does CS media start to flow to the user as part of the SIP call? Is it before or after correlation? (E.g., does the user hear the DTMF exchange?) - if media flows to the user before correlation, then what if correlation fails? Will another call be accepted and correlation be attempted again? - what if multiple incoming calls arrive before correlation has been completed? (If correlation occurs before exposing the media to the user, then it isn't an issue.) - extern correlation complicates this. It isn't like the other correlation mechanisms - the user must be exposed to the media to decide if there is correlation. How would the user indicate "this is the wrong call" in a way that would allow correlation to be attempted on another call? Now consider a call that is initially established with one RTP media stream. Later, a reinvite is sent with an offer proposing to to replace that with a CS media stream: - again, there must be an answer before the CS call can be attempted. - are you assuming that the reinvite will complete before the CS call does? If so, then you are in a break-before-make situation - the RTP session is gone before the CS session takes its place. - all the issues above also apply here. ISTM that there is a bunch of missing explanation of how this is expected to work. I also have a nit in section 5.3.2: The fourth correlation mechanism declares support for cases where correlation is done by external means. Typically this means that the decision is left for the human user. This is the way how some current conferencing systems operate: ... "This is the way how some current conferencing systems operate" should be: "This is how some current conferencing systems operate" Thanks, Paul On 1/31/14 6:01 AM, Simo.Veikkolainen@nokia.com wrote: > Hello WG, > > We have submitted a new version of http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-22 > > To recap, there was discussion on the MMUSIC WG list on which correlation mechanisms should be mandatory to implement (see Gonzalo's email http://www.ietf.org/mail-archive/web/mmusic/current/msg12274.html ). As stated by Gonzalo, 3GPP is going to use this draft, more specifically the plan now is to use the caller id based correlation mechanism. This was the message I got from Andrew after a recent 3GPP CT1 meeting. > > We have now made the following changes to the draft: > - the endpoint may choose which correlation mechanisms to implement (before all three were MTI). > - we have introduced a fourth correlation type ("external") which indicates explicit support for cases where also some external means, typically the human user, can do the correlation. This can be as a fallback in cases where no other common correlation mechanism is found, or the negotiated correlation mechanisms fail due to being not supported in the PSTN network. This is much like current systems like Webex work. > > This was also the guidance from the IESG informal telechat in December where Gonzalo presented the draft. > > We would like to hear from the WG whether there are any concerns with these changes. > > On behalf of the authors, > Simo > > PS. I'll add the proposed change in http://www.ietf.org/mail-archive/web/mmusic/current/msg12792.html to next version, slipped my mind this time. > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org > Sent: 31 January, 2014 12:25 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) > Authors : Miguel A. Garcia-Martin > Simo Veikkolainen > Filename : draft-ietf-mmusic-sdp-cs-22.txt > Pages : 37 > Date : 2014-01-31 > > Abstract: > This memo describes use cases, requirements, and protocol extensions > for using the Session Description Protocol (SDP) Offer/Answer model > for establishing audio and video media streams over circuit-switched > bearers in the Public Switched Telephone Network (PSTN). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-22 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-cs-22 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >