From internet-drafts@ietf.org Sat Feb 1 06:29:49 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 791CE1AE44C; Sat, 1 Feb 2014 06:29:49 -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 UutzoZRHUvQ5; Sat, 1 Feb 2014 06:29:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4222C1AE3AE; Sat, 1 Feb 2014 06:29:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140201142933.17089.24640.idtracker@ietfa.amsl.com> Date: Sat, 01 Feb 2014 06:29:33 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-04.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: Sat, 01 Feb 2014 14:29:49 -0000 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 : UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) Authors : Christer Holmberg Ivo Sedlacek Gonzalo Salgueiro Filename : draft-ietf-mmusic-udptl-dtls-04.txt Pages : 21 Date : 2014-02-01 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-udptl-dtls-04 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 Sat Feb 1 06:31: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 7535F1AE415 for ; Sat, 1 Feb 2014 06:31:44 -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 kn3Qf4Pk4-rC for ; Sat, 1 Feb 2014 06:31:43 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id EBDE01AE3F8 for ; Sat, 1 Feb 2014 06:31:42 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-88-52ed054af308 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 73.97.04853.A450DE25; Sat, 1 Feb 2014 15:31:38 +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; Sat, 1 Feb 2014 15:31:37 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-udptl-dtls-04 Thread-Index: Ac8fWlB56/jKKzGxQfaztM+rXapv5g== Date: Sat, 1 Feb 2014 14:31:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1533E8@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvja4X69sggz8bpC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL2f9rIWTGKs+H3oJlsDY14XIyeHhICJxJrZ69ggbDGJC/fW A9lcHEICJxglPrWeZYZwFjFKfJ78ESjDwcEmYCHR/U8bpEFEQF3i694eZhBbWMBaomfaPHaI uIPE7JuToGw9iTXrD4MtYBFQkdg6qZUVxOYV8JX48KARLM4ItPj7qTVMIDazgLjErSfzmSAO EpBYsuc8M4QtKvHy8T9WkBMkBJQkpm1NgyjXkViw+xMbhK0tsWzha2aI8YISJ2c+YZnAKDwL ydRZSFpmIWmZhaRlASPLKkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8PL3i1E2MwDA/uOW30Q7G k3vsDzFKc7AoifNeZ60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCotoT7WmWJ+Ic58vxh z2vuMARvCvG2U5OavHn/4SmM0oZ5RjpPm9a39ZzYJOnCkvtqf6pfy9pPy5i8nf9M9I36aDTr XOTP+KKXy47z/mD34PrhaigVX+Sbdv+FfGeazcTZz7RWXbG/3yNatEIvnT/vr4LLh1jeBrvX Qd+4hIVvz17wS6C9xFKJpTgj0VCLuag4EQChexEgQQIAAA== Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-04 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, 01 Feb 2014 14:31:44 -0000 Hi, Based on the review comments by Adam G and Ari K, I've submitted a new vers= ion (-04) of the udptl-dtls draft. Regards, Christer= From palmarti@cisco.com Mon Feb 3 05:59: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 3655C1A021C for ; Mon, 3 Feb 2014 05:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.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 0bPaDtEYlwBc for ; Mon, 3 Feb 2014 05:59:33 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 07AD71A0478 for ; Mon, 3 Feb 2014 03:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2047; q=dns/txt; s=iport; t=1391427150; x=1392636750; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ORt8G6imzYf/rIrOIzWJ8JC5X/NlixKvIsJgyGv7+1M=; b=kvqcz2ow0jghPwC96+XSKs/jU6ssb7d4TG1WMaR0UTcy0ETqIdvPOSSM yBUiu7yG5J+l/ZOrSmnbPc3p9h17qb5TQNrSL1XTodPVYBJKKscdusQqV mFzaVIm2O3A5P7UJan6zpKnauEvY1m4x676+Ah/NjA317nl38peKaLHrs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAIZ971KtJXG+/2dsb2JhbABZgww4Swy+GYEGFnSCJQEBAQMBeQULAgEIRjIlAgQOBQmHdAgNzBkXjlYzB4MkgRQEiRGPGZIhgy2CKg X-IronPort-AV: E=Sophos;i="4.95,771,1384300800"; d="scan'208";a="301458439" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 03 Feb 2014 11:32:28 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s13BWSSh015334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Feb 2014 11:32:28 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.70]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 05:32:27 -0600 From: "Pal Martinsen (palmarti)" To: "Balint Menyhart (balmenyh)" Thread-Topic: Candidate priority in draft-reddy-mmusic-ice-happy-eyeballs-05 Thread-Index: AQHPHb9maivtLoCPl0W7O3A1vpEKqpqj0EyA Date: Mon, 3 Feb 2014 11:32:26 +0000 Message-ID: References: <52EA53E1.20701@cisco.com> In-Reply-To: <52EA53E1.20701@cisco.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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic \(E-mail\)" Subject: Re: [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: Mon, 03 Feb 2014 13:59:35 -0000 On 30 Jan 2014, at 14:30 pm, Balint Menyhart wrote: > Hi, >=20 > This is a comment related to http://www.ietf.org/id/draft-reddy-mmusic-ic= e-happy-eyeballs-05.txt. Section 4 states: >=20 > 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. >=20 > 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 > I believe the intention here was to reference the local preference, inste= ad of the type preference. Yes. You are absolutely right. This was a glitch from the authors. Thinking= to much about the IP addr type. > The former is meant to distinguish between network interfaces from which = the candidates have been gathered, while the later was intended to distingu= ish the type of the candidate obtained. It sounds to me, that IPv4 / IPv6 d= ifference falls therefore in the local preference category, and not the typ= e preference. >=20 > From a different perspective, applying the formula given above: >=20 > priority =3D (2^24)*(type preference) + > (2^8)*(local preference) + > (2^0)*(256 - component ID) >=20 > it also makes sense to "play" with the less significant bits, which are t= he 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. >=20 You make a good point. I will take this as hint that we are moving in the r= ight direction by playing with the _local preference_ bits. Thanks for taking the time to review. .-. P=E5l-Erik > Regards, >=20 > Balint From juberti@google.com Mon Feb 3 12:28: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 27F7D1A0162 for ; Mon, 3 Feb 2014 12:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.535, 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 jx_L3_mMYvcp for ; Mon, 3 Feb 2014 12:28:24 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 38B161A015A for ; Mon, 3 Feb 2014 12:28:24 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oz11so5220845veb.4 for ; Mon, 03 Feb 2014 12:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gY7dhRCqeeuxmz32DkOn8pNKGysfddcfXlHgGFzi198=; b=CaiMYuA8Xrn1iSiyUVZkqL4XTOh37QKSJmn/qoKO21gB3SYle+Vi7I/G5AqKX1drrZ +Q7fqu+5JQi1HzwaNVvFsScA4O03IlaZgqFkXfDD1kQX293d7zIBNhlHGyhQ9Gqd8QzE MZeqZE9ESqsYPAf3XRAVf97Zf1+0AxfPtwgkDJCG/UNlRptPsjbTgDZLkdu+1PJxUInW KcpcgsBoPtflD3AbqpT2Gu8zZm5bZWN4RyFJebTa3FJJ1N6oBmAzXAvXNvfdRDgwKFmd 2X2GyqerbTkp8v4ClIPzG3YPm2jwQyzlM4Jtt+GH84d1ulScAT8c8wCjNo51HorIfpok vj4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gY7dhRCqeeuxmz32DkOn8pNKGysfddcfXlHgGFzi198=; b=NwBjiyVJZv/TGwCBgZS2fmVhFQ1zOtdTAVJmZvAqt8NSwqFusT+/gPSIiAKHLlmm7a pn2tJXk5bQWz4XshScEs5JIFmhcFDUnC3zu55bCnI8Air0Ugr3sFmWlIzv6AMCXiEvsX gMmJoAkmGyiYMH96wiLVXgPkKN09M2kSpKzmeZJp8GTUzy1zyNmgQjjOtTlHTYksIq5n NqnAfPTHJoHBnE5XJzE0w7RwsT4x2jrNgx4/fgOEwuxikC/QT5TJr4b5cwusUpdq+gxu Wgzsj2e/151NsYZ8tMHaNx+hcq8YtC/eVgcHpIqM3K2G9nvv3HoySYsnmr8T3kIyWgd3 GmBg== X-Gm-Message-State: ALoCoQlVjDJ3dPOsVKodVBwFzjbGyaXd1bUUPdweGqPVGL3TvNuZeU9E40YiBkFobnMGm05zJVov0MvMwwkhDh8+kLPVZdH99O9WDsiN7FP3z/4RPx60UF4hqheVa8cD8zAr7hbBYItX7mB9vSvBRxm0K/AcvcAc/4apwkJtqQQ2QmStAm8oJZRblGRyrKcuNop17vCEwDNA X-Received: by 10.220.48.194 with SMTP id s2mr87223vcf.43.1391459303878; Mon, 03 Feb 2014 12:28:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 12:28:03 -0800 (PST) In-Reply-To: References: <52EFF9E0.40808@nostrum.com> From: Justin Uberti Date: Mon, 3 Feb 2014 12:28:03 -0800 Message-ID: To: Adam Roach , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1e7fc8718b604f1865d89 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 20:28:26 -0000 --001a11c1e7fc8718b604f1865d89 Content-Type: text/plain; charset=UTF-8 +mmusic (meant to include the first time around) On Mon, Feb 3, 2014 at 12:25 PM, Justin Uberti wrote: > > > > On Mon, Feb 3, 2014 at 12:19 PM, Adam Roach wrote: > >> On 2/3/14 13:27, Justin Uberti wrote: >> >> Therefore, I think we need some similar way for a receiver to do the same >> for a remote track. >> >> >> Yes. >> >> >> And fortunately, I think we have a surface that can be used for this, >> namely the "recv-appId" attribute that has been discussed in the context of >> unified-plan and explained in >> http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and >> unified-plan. If an endpoint doesn't want to receive a particular track on >> a m= line, it sets the m= line to a=sendonly and also removes any >> a=recv-appId. >> >> >> No. >> >> The problem is that you're defining semantics to a behavior that is >> indistinguishable from the behavior exhibited by something that does not >> support app-id: if the thing on the other end isn't using app-id, then an >> attempt to put a stream on hold will be misinterpreted as an attempt to >> reject or remove it. >> > > See my response to Martin. Putting a stream on hold will never result in > that being misinterpreted as a reject; on the contrary, without appid, > there is no way to 'fully' reject half of a stream, and, as a problem > confined to pre-unified-plan devices, I think that is probably OK. > >> >> I agree that we want an SDP operation that differentiates between "don't >> send me this now" and "don't send me this ever" [1] -- but it needs to be >> explicit. Something more like "a=i-am-rejecting-this-stream", but with a >> less cumbersome name. >> >> It's not clear to me that adding a new attribute would solve any problem > that appid doesn't solve; you still need to deal with the "other end not > using it" issue. > > >> ____ >> [1] Along with a Javascript control that allows us to do the same thing, >> but that's a W3C issue. >> > > Agree. But while we're on the subject, I am thinking that MST.stop() == > "not ever", and RtpReceiver.active = false causes "not now". > > --001a11c1e7fc8718b604f1865d89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+mmusic (meant to include the first time around)


On Mon, Feb 3, 20= 14 at 12:25 PM, Justin Uberti <juberti@google.com> wrote:



On Mon, Feb 3, 201= 4 at 12:19 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 2/3/14 13:27, Justin Uberti wrote:
Therefore, I think we need some similar way for a receiver to do the same for a remote track.

Yes.


And fortunately, I think we have a surface that can be used for this, namely the "recv-appId" attribute that has been dis= cussed in the context of unified-plan and explained in http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and unified-plan. If an endpoint doesn't want to receive a particular track on a m=3D line, it sets the m=3D line to a=3Dsendo= nly and also removes any a=3Drecv-appId.

No.

The problem is that you're defining semantics to a behavior that is indistinguishable from the behavior exhibited by something that does not support app-id: if the thing on the other end isn't using app-id, then an attempt to put a stream on hold will be misinterpreted as an attempt to reject or remove it.

See my response to Martin. Putting a stream o= n hold will never result in that being misinterpreted as a reject; on the c= ontrary, without appid, there is no way to 'fully' reject half of a= stream, and, as a problem confined to pre-unified-plan devices, I think th= at is probably OK.=C2=A0

I agree that we want an SDP operation that differentiates between "don't send me this now" and "don't send me this= ever" [1]=C2=A0 -- but it needs to be explicit. Something more like "a=3Di-am-rejecting-this-stream", but with a less cumbersome = name.

It's not clear to me that ad= ding a new attribute would solve any problem that appid doesn't solve; = you still need to deal with the "other end not using it" issue.
=C2=A0
____
[1] Along with a Javascript control that allows us to do the same thing, but that's a W3C issue.

Agree. But while we're on the subject, I am thinking that M= ST.stop() =3D=3D "not ever", and RtpReceiver.active =3D false cau= ses "not now".=C2=A0


--001a11c1e7fc8718b604f1865d89-- From juberti@google.com Mon Feb 3 13:03: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 E10791A0225 for ; Mon, 3 Feb 2014 13:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 jFZcrIauKATY for ; Mon, 3 Feb 2014 13:03:43 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A8AD01A01DA for ; Mon, 3 Feb 2014 13:03:43 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id oy12so5352511veb.14 for ; Mon, 03 Feb 2014 13:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gfnYGtb004uADYqh6wRLQqzGDvftjOdAliIrf+dAjsA=; b=Gv3Z7RsKTxJiXMezr3iSKQYAuj3aJxLeex5MF1h8YlJkMSa4fp9CtyX0NDwugxxjzG r58u9bhcnSjsU86qB1L1BExJ9s1Eg0MgUV9TPObApkSJd09s1CbZ4uSn/uWySDzRG5E/ Lv6K0GPVFSMgyPXQjjXVV8mmoLWlN8t8JPoNiqJnM9Tdrjj6XCK/pzG1bC+6NYl4npBF MAdxPBLAe3MZtAhd4iPpFPSjBUHDxaqYAmSnOPbM0pNvH8ad48rA4iwlq48WK0wnSeuN cXHMUrObQD1uUTT8yNn64Ze832F8BYUcDt4YlUlycQYSe1+vbuzMut/WVt/7Kt9SgOLO xFKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gfnYGtb004uADYqh6wRLQqzGDvftjOdAliIrf+dAjsA=; b=hIE5ZoZw82NKvLFPwwyp8rrk6q4evVSRoVzNFnAlsG5j8Y7+E9VaPWx3BGe4c25kYI N91LsFFpZmFAPtgovQSCGLCu68DzZ9XZPvKor3H8UyAkGCCX8R3AXYjovdXatSfzFxKC Tf5msgB/x5xmDVD7rSV0gsT72hTYbcccPfDvmW/AttbHjPayNmNb5dAgkSEYyDrhiLYL lLjzv8GCUg7g2wWfV5x+Gyirmu5jn1/jrUhIt/ZX3vhX9yvo4gZxnPF29d1arAy0ZTgN z29j2PhJgHlHUosZ9qtwWw9rId/cWiNwJ+C868akYn5C2OUk1vz6f/Ci0Q1+ggHQs+Kx IS2A== X-Gm-Message-State: ALoCoQmnNrHnSmzZVeQ+HnLXCWicAICrRlv1jADpR7jVVGkdZkFkVwcNgZUGEkGUBEninO5muQrWYrjQ/ff68A8SuKyZOHLBUh5hVjTkbTLGuvWPdf6d83hrsVz/AreP8A98mnqqGdac76sveCO/gmnFqBtF0Jv9w3cbz9zFe+6awmdsh6Bz1Zkz7fyinLZLwLcSxCZSUg3L X-Received: by 10.220.139.136 with SMTP id e8mr1363403vcu.34.1391461423130; Mon, 03 Feb 2014 13:03:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 13:03:22 -0800 (PST) In-Reply-To: <52EFFF3E.9080705@nostrum.com> References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> From: Justin Uberti Date: Mon, 3 Feb 2014 13:03:22 -0800 Message-ID: To: Adam Roach , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=047d7b343296d8404004f186db09 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 21:03:45 -0000 --047d7b343296d8404004f186db09 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach wrote: > On 2/3/14 14:25, Justin Uberti wrote: > >> It's not clear to me that adding a new attribute would solve any problem >> that appid doesn't solve; you still need to deal with the "other end not >> using it" issue. >> > > Regardless of whether you think there's a problem in the legacy interop > case, the big benefit here is that an explicit indicator by definition > makes the operation explicit, and that in-and-of-itself is a good thing. > > The core issue is that you're trying to make the operation implicit; your > proposal edges awfully close to the DWIM model of design, which we know > causes problems when we try to add further extensions. Good point, but since we are still defining exactly what appId does, I think we have the opportunity to make it explicit. --047d7b343296d8404004f186db09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:
On 2/3/14 14:25, Justin Ub= erti wrote:
It's not clear to me that adding a new attribute would solve any proble= m that appid doesn't solve; you still need to deal with the "other= end not using it" issue.

Regardless of whether you think there's a problem in the legacy interop= case, the big benefit here is that an explicit indicator by definition mak= es the operation explicit, and that in-and-of-itself is a good thing.

The core issue is that you're trying to make the operation implicit; yo= ur proposal edges awfully close to the DWIM model of design, which we know = causes problems when we try to add further extensions.

Good point, but since we are still defining exactly what app= Id does, I think we have the opportunity to make it explicit.=C2=A0

--047d7b343296d8404004f186db09-- From adam@nostrum.com Mon Feb 3 13:11:05 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 223021A0237; Mon, 3 Feb 2014 13:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=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 4NHfvP_FhSrm; Mon, 3 Feb 2014 13:11:04 -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 E32131A0225; Mon, 3 Feb 2014 13:11:03 -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 s13LAo5f042807 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 15:10:51 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52F005D5.1020702@nostrum.com> Date: Mon, 03 Feb 2014 15:10:45 -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: Justin Uberti , "mmusic@ietf.org" References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020506060903060308030504" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 21:11:05 -0000 This is a multi-part message in MIME format. --------------020506060903060308030504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/3/14 15:03, Justin Uberti wrote: > > On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach > wrote: > > On 2/3/14 14:25, Justin Uberti wrote: > > It's not clear to me that adding a new attribute would solve > any problem that appid doesn't solve; you still need to deal > with the "other end not using it" issue. > > > Regardless of whether you think there's a problem in the legacy > interop case, the big benefit here is that an explicit indicator > by definition makes the operation explicit, and that > in-and-of-itself is a good thing. > > The core issue is that you're trying to make the operation > implicit; your proposal edges awfully close to the DWIM model of > design, which we know causes problems when we try to add further > extensions. > > > Good point, but since we are still defining exactly what appId does, I > think we have the opportunity to make it explicit. > I think I agree, but this isn't congruent with the proposal you made before. Omitting app-id as a means of rejecting a stream is an implicit operation, regardless of how well it's documented. If you want to have something like "a=recv-appId:reject", that would be suitably explicit, but I really have a hard time imagining how something like that would be preferable to just having a new attribute. /a --------------020506060903060308030504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2/3/14 15:03, Justin Uberti wrote:

On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach <adam@nostrum.com> wrote:
On 2/3/14 14:25, Justin Uberti wrote:
It's not clear to me that adding a new attribute would solve any problem that appid doesn't solve; you still need to deal with the "other end not using it" issue.

Regardless of whether you think there's a problem in the legacy interop case, the big benefit here is that an explicit indicator by definition makes the operation explicit, and that in-and-of-itself is a good thing.

The core issue is that you're trying to make the operation implicit; your proposal edges awfully close to the DWIM model of design, which we know causes problems when we try to add further extensions.

Good point, but since we are still defining exactly what appId does, I think we have the opportunity to make it explicit. 


I think I agree, but this isn't congruent with the proposal you made before. Omitting app-id as a means of rejecting a stream is an implicit operation, regardless of how well it's documented.

If you want to have something like "a=recv-appId:reject", that would be suitably explicit, but I really have a hard time imagining how something like that would be preferable to just having a new attribute.

/a
--------------020506060903060308030504-- From juberti@google.com Mon Feb 3 13:22: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 DF6121A0254 for ; Mon, 3 Feb 2014 13:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable 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 b59blD8hKzcH for ; Mon, 3 Feb 2014 13:22:21 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 90E3B1A01FB for ; Mon, 3 Feb 2014 13:22:21 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so5282989veb.19 for ; Mon, 03 Feb 2014 13:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CT8HpjzuF3dDIPq1GNmETpLO6uN8fsES7N0mPgKKAAw=; b=oYOWbY+QnFRsZOly+J9xKGdelKg/C9yuGFA7FKy4CSSV6IcTxRjH632+923Ih2GBze JHEC3Q+Ah2zlhv7Pugh8uwHbPSHYgAV0bwk8S9Cmhsymf82PpkY5uDdOCSLaRb1/5IVs MvVlCI0Iby8CmzCY2Po8ug3JqsjcjonG06wCE1kdxhEF/lZRQGs21MGN3IvLXX3eg6hp 5eQ7wxVqa4PWY296YIm4XxSdaWh81sYwhDgfp9uibKUnsmy0XooaaUqW+YH74Ve+wIsZ jf7Rj4bmcJ4K9M2/YuzFnCRaZTk6kcs6JbiU/SaGQ4vkurgE7tjCFPi6shdNPokc3VJm hD0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CT8HpjzuF3dDIPq1GNmETpLO6uN8fsES7N0mPgKKAAw=; b=QlKfp4FlD6KVT5V4OhaBLTbH23orSDQXALfk7iS9iiUWx99Cjde3+uEZl4r7gAS174 +pzPJEC9D73hEARDeWLRUA02xhxOXxD4s+E7qdqTpzQ9qSdExxNhLKJXFlZwYuRSSCEx DQ4ZeVkSFwnbBbRfHlHhc/JF7F8DIM6mVymUsPzL4oGGJ8OnUs3hutnTWhSNvzZrpJ5a 8a+b30WzBRf7J8gcoZv8ckciHctFF3sh0eJ4brGYsxZx3BSMhu+DhUnn3/OaGzT/ujIJ z6ytMahIwIZFuTWa2x81rsE+UJxrIj1ABM/yPGQCy6BAjhap6labeAn0yzS31QsuQDra a6dg== X-Gm-Message-State: ALoCoQnRthacnM8b1qUSprKw8RX89ExxystdgWIIRM0SO+hJAdRbesN6fi+AYiIfQP4jaPBzHIoS799qoF2LtMG0+7qEHp8HEgUCheWkQNAXHy69ZICup6ZWQbpgdaYiRGUZdGyfak3lHMSUXPrqHIjdgp/sP8mg7h6vZ2j8Awp0kCGGBBe3APmoQWEDVSfiVfaJbPBy431P X-Received: by 10.52.95.233 with SMTP id dn9mr25200434vdb.3.1391462541077; Mon, 03 Feb 2014 13:22:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 13:22:00 -0800 (PST) In-Reply-To: <52F005D5.1020702@nostrum.com> References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> <52F005D5.1020702@nostrum.com> From: Justin Uberti Date: Mon, 3 Feb 2014 13:22:00 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a1136b6107ac4b404f1871e5f Cc: Cullen Jennings , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 21:22:25 -0000 --001a1136b6107ac4b404f1871e5f Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 1:10 PM, Adam Roach wrote: > On 2/3/14 15:03, Justin Uberti wrote: > > > On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach wrote: > >> On 2/3/14 14:25, Justin Uberti wrote: >> >>> It's not clear to me that adding a new attribute would solve any problem >>> that appid doesn't solve; you still need to deal with the "other end not >>> using it" issue. >>> >> >> Regardless of whether you think there's a problem in the legacy interop >> case, the big benefit here is that an explicit indicator by definition >> makes the operation explicit, and that in-and-of-itself is a good thing. >> >> The core issue is that you're trying to make the operation implicit; your >> proposal edges awfully close to the DWIM model of design, which we know >> causes problems when we try to add further extensions. > > > Good point, but since we are still defining exactly what appId does, I > think we have the opportunity to make it explicit. > > > I think I agree, but this isn't congruent with the proposal you made > before. Omitting app-id as a means of rejecting a stream is an implicit > operation, regardless of how well it's documented. > > If you want to have something like "a=recv-appId:reject", that would be > suitably explicit, but I really have a hard time imagining how something > like that would be preferable to just having a new attribute. > I was thinking a=recv-appId:0, which is both explicit, and has parallels with the zero port form of rejecting a m= line. --001a1136b6107ac4b404f1871e5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 1:10 PM, Adam Roach <adam@nostrum.com>= ; wrote:
=20 =20 =20
On 2/3/14 15:03, Justin Uberti wrote:

On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach <adam@nostrum.com> wrote:
On 2/3/14 14:25, Justin Uberti wrote:
It's not clear to me that adding a new attribute woul= d solve any problem that appid doesn't solve; you still need to deal with the "other end not using it" = issue.

Regardless of whether you think there's a problem in the legacy interop case, the big benefit here is that an explicit indicator by definition makes the operation explicit, and that in-and-of-itself is a good thing.

The core issue is that you're trying to make the operatio= n implicit; your proposal edges awfully close to the DWIM model of design, which we know causes problems when we try to add further extensions.

Good point, but since we are still defining exactly what appId does, I think we have the opportunity to make it explicit.=C2=A0


I think I agree, but this isn't congruent with the proposal you mad= e before. Omitting app-id as a means of rejecting a stream is an implicit operation, regardless of how well it's documented.

If you want to have something like "a=3Drecv-appId:reject", t= hat would be suitably explicit, but I really have a hard time imagining how something like that would be preferable to just having a new attribute.

I was thinking a=3Drec= v-appId:0, which is both explicit, and has parallels with the zero port for= m of rejecting a m=3D line.=C2=A0

--001a1136b6107ac4b404f1871e5f-- From adam@nostrum.com Mon Feb 3 14:10:37 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 2FC421A025F; Mon, 3 Feb 2014 14:10:37 -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 9Uyor261U6mH; Mon, 3 Feb 2014 14:10:36 -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 62C951A01EE; Mon, 3 Feb 2014 14:10:36 -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 s13MANLd045159 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 16:10:24 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52F013C9.1090609@nostrum.com> Date: Mon, 03 Feb 2014 16:10:17 -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: Justin Uberti References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> <52F005D5.1020702@nostrum.com> In-Reply-To: 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: Cullen Jennings , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 22:10:37 -0000 On 2/3/14 15:22, Justin Uberti wrote: > > I was thinking a=recv-appId:0, which is both explicit, and has > parallels with the zero port form of rejecting a m= line. > I have no objection to such an approach. /a From jonathan@vidyo.com Mon Feb 3 14:32: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 37AA11A01EE; Mon, 3 Feb 2014 14:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, 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 4crGNX-tLnbZ; Mon, 3 Feb 2014 14:32:21 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id CF7FA1A015D; Mon, 3 Feb 2014 14:32:20 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/3/2014 5:32:18 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-145/SG:5 2/3/2014 5:32:05 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.765737 p=-0.947836 Source White X-Signature-Violations: 0-0-0-6034-c X-Note-419: 0 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/3/2014 5:32:06 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 94746033; Mon, 03 Feb 2014 17:32:18 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Mon, 3 Feb 2014 16:32:17 -0600 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIS46pADKsTFIzECMWWmLIWbna5qkgc6A Date: Mon, 3 Feb 2014 22:32:17 +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: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_C433A27C348A402AB03607060746FADAvidyocom_" MIME-Version: 1.0 Cc: Cullen Jennings , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 22:32:22 -0000 --_000_C433A27C348A402AB03607060746FADAvidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 3, 2014, at 2:27 PM, Justin Uberti > wrote: Also, this essentially makes recv-appId the converse of MSID; for simplicit= y, I think we should consider unifying these concepts into a single documen= t. AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream. For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid. On the receive side, if you wanted to receive both a primary = encoded stream and a redundancy stream, you would have two recv-appid value= s. As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea. Perhaps we need a recv-msid, explicitly? --_000_C433A27C348A402AB03607060746FADAvidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <37105A42B50D274697715328E513CDD0@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com> wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid.  On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

--_000_C433A27C348A402AB03607060746FADAvidyocom_-- From juberti@google.com Mon Feb 3 15:00:47 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 DC75F1A0283 for ; Mon, 3 Feb 2014 15:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 vtGw9fWfAUrK for ; Mon, 3 Feb 2014 15:00:46 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 95A061A0282 for ; Mon, 3 Feb 2014 15:00:46 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id ik5so5429890vcb.9 for ; Mon, 03 Feb 2014 15:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yXDPcYNswZrdNXI7EV4hWR3viGWuz2NmMdn10nDDM9U=; b=ny/k+pogMdj3kZG4dEEyTkvH9K0Vh1tvnKB+HA2FX1X00pqscDyIO5PvBuRJ5PCqKc PcELvRRQWtbZ9NPfH640BgOg70dtdXk1tI5IMicy2ELRFk0tXWWlcmmBFyN3unSWX1fT UKZjCbOFOHkf9L22d4XbOzK+Ee6QTGjZcZJDefloq9ueqp+g9Lb5tVsdtuYMNkPA745g iKC2uQm2O3RWy2MyepHBf4I5pDTzciR7ZK1zH2g+iYS4nsY27P/1xBsETXtFLzf7Unvq 3VToi1ef3Cz8dYFFuNRDY5LNiGe7GmCl70OaPKRjF7Y4btIZQykq810qLVd1HNtW/eEw uhDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yXDPcYNswZrdNXI7EV4hWR3viGWuz2NmMdn10nDDM9U=; b=GX60BUNQlJAUWAEoGp7cVQtqnRZdZs4zzZul04CvDxwsYyk+wJadadl1+TV7EMmP3I AmPmDWZsRZP9Xck0fMu/k91TGRBaPwmd/zxPxH2pXNNwP69RWwjTs7mjL4O3aYndki7J NVS281nlOaX6KWZAOO+FiFYofp/zQ6aeXPGgGAwbHTB4fmYpicMcskRj2IR2rnW3fDHZ lIhN+Y950WaP0Qw9487bQP3rV1KwwwEUk+mOvufOgzWyi9Zw2KePYnikB+yq1NUmr06u u6nu4CCrj5OrBi9l4T1u7PTO6D9i+foSPKqLIYm6SVsAeA9pF0ER2fe8tVXdg04M4HnI GFkw== X-Gm-Message-State: ALoCoQnMXWvWO4zqfsRKwMcRF5QfJ7mbVfNeKtZO42NLsZ5Bz5JvqJI/ZKgUtiT8ZyxBfb0oeKH/9HlbXh9m7KrouRWJMKQbtFuEok8fWzI0NML2NP6b4JEyKXomz2GIDU5hzBlbpgEP708HVjqM+WvVPWIUO8tXIozNQWidUXlryRvvLjpRNKmxrRyq8/MOzhc7n6CFhM/j X-Received: by 10.58.168.142 with SMTP id zw14mr45602veb.33.1391468446135; Mon, 03 Feb 2014 15:00:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 15:00:26 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Mon, 3 Feb 2014 15:00:26 -0800 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=047d7b6da02872d46104f1887ec4 Cc: Cullen Jennings , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 23:00:48 -0000 --047d7b6da02872d46104f1887ec4 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox wrote: > On Feb 3, 2014, at 2:27 PM, Justin Uberti wrote: > > Also, this essentially makes recv-appId the converse of MSID; for > simplicity, I think we should consider unifying these concepts into a > single document. > > > AppID (as I envision it, as the author) and MSID (as I understand it) > have rather different scopes, which are visible once sources are sent using > more than one packet stream. > > For example, an m-line which has both a primary encoded stream (of > media) and a redundancy stream (of rtx packets) would have two appid > values, but only one msid. On the receive side, if you wanted to receive > both a primary encoded stream and a redundancy stream, you would have two > recv-appid values. > > As such, appid and msid are solving different (though related) problems, > and I don't think unifying them is a good idea. > > Perhaps we need a recv-msid, explicitly? > That would be fine by me - it would allow a single invention (msid + recv-msid) to focus on solving the three identified problems with MSTs in unified-plan: - correlation of a MediaStreamTrack to m= line in signaling (msid) - correlation of packets from a MST to m= line ahead of signaling (recv-msid) - rejection of an individual MST (recv-msid) Based on your description, appid seems to go one or two levels down from a MST to an individual RTP flow, but we can let that develop on its own, separate from the timetable of webrtc 1.0 and unified plan. --047d7b6da02872d46104f1887ec4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox &= lt;jonathan@vidyo.c= om> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com>=C2=A0wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid. =C2=A0On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?
<= div>
That would be fine by me - it would allow a single inven= tion (msid + recv-msid) to focus on solving the three identified problems w= ith MSTs in unified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signalin= g (recv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two leve= ls down from a MST to an individual RTP flow, but we can let that develop o= n its own, separate from the timetable of webrtc 1.0 and unified plan.


--047d7b6da02872d46104f1887ec4-- From juberti@google.com Mon Feb 3 15:03: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 F0E391A0282 for ; Mon, 3 Feb 2014 15:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JNcENell7CLJ for ; Mon, 3 Feb 2014 15:03:57 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7845C1A027B for ; Mon, 3 Feb 2014 15:03:57 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id lh14so5335226vcb.10 for ; Mon, 03 Feb 2014 15:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NmpAjSQu2E+olFt1dvp1OY1A/cy+m+SUFeTgwNNdL5Q=; b=obyp2mdq5j3S15Drjdzo7waV4y2o+zftiRSJfP8aN4ppPCNrCmgZs8OSTzoo27T2X8 OHT0iolbgbgmySnre5/ZpxtTF2W2un2T199xPQWmZ/h+hqouEGDkTabzDBbIh2WpX3v/ zXcofJJBV85DL5rdt4JScnHnvb23BLbYdDKjS+CjhlnLaa42gbBXeX/JlH7rNuunMhs4 tIXH322L8ucw0H++ltzUxLZ8V4bO8biAbJiULHV1BkLNU3oOkjciHlzzmeqnS9WKrQ/L hg0G4CEqIMfVQmTr2VUpCxi2eNyKpS3DitBCLzHFZo8vxMq58TJn2P3IMfqBS39p85tm Ze8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NmpAjSQu2E+olFt1dvp1OY1A/cy+m+SUFeTgwNNdL5Q=; b=RUrWOvcqw45MY8gCLLTL3cJkpM1MmhLVTozKRcMFgcvYdhCvF3/73lMgGErMpoMMgX rO13u1zvpWH72ktZF0nrCjntQ3zK2Nebjof3ywVoi530F0jh+U5IITkXemx1jLiTrR7d dgAYU/4GaHOidmJeys3LhnYLKDitTtq8mHTyQHl8DOCWzRNpVv80O2G9FiEx08ArZkpp gjEvbks5BIN8cLpoP3Q42xi4w0t2DE7QOiaOJx2q+p1LqHdpp4rn6iRamPUE79lUSSVC UxCFFyIGR2hwj4PhlFt4qhiBTI4y/JRZuY/0cQ1ueJHSdq1bhxcB+ZdVTzG/QeTusLuP D+zA== X-Gm-Message-State: ALoCoQlh0iPllgKuPC1kr1axS8RvGJUjFGNJRgVBmamtVVIIHJs6uw/D15XCKDgCXzbxhMlgBRuocRJc+ZX+Dx+jCsSs7uaagg0xifD9bfDitDcWjUk0LQTroOG9u5dsJl0KgRPGSXbxVRK917W2V98JtXjsrZDfv8PonPOnpOpn2F3a5qjxsRO6kEl9lnGJ4PkgKBRadpQ5 X-Received: by 10.58.48.133 with SMTP id l5mr54756ven.36.1391468637130; Mon, 03 Feb 2014 15:03:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 15:03:36 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Mon, 3 Feb 2014 15:03:36 -0800 Message-ID: To: Jonathan Lennox , Harald Alvestrand Content-Type: multipart/alternative; boundary=089e011844dad5304004f1888911 Cc: Cullen Jennings , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 23:03:59 -0000 --089e011844dad5304004f1888911 Content-Type: text/plain; charset=UTF-8 +Harald as this affects the MSID doc On Mon, Feb 3, 2014 at 3:00 PM, Justin Uberti wrote: > > > > On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox wrote: > >> On Feb 3, 2014, at 2:27 PM, Justin Uberti wrote: >> >> Also, this essentially makes recv-appId the converse of MSID; for >> simplicity, I think we should consider unifying these concepts into a >> single document. >> >> >> AppID (as I envision it, as the author) and MSID (as I understand it) >> have rather different scopes, which are visible once sources are sent using >> more than one packet stream. >> >> For example, an m-line which has both a primary encoded stream (of >> media) and a redundancy stream (of rtx packets) would have two appid >> values, but only one msid. On the receive side, if you wanted to receive >> both a primary encoded stream and a redundancy stream, you would have two >> recv-appid values. >> >> As such, appid and msid are solving different (though related) >> problems, and I don't think unifying them is a good idea. >> >> Perhaps we need a recv-msid, explicitly? >> > > That would be fine by me - it would allow a single invention (msid + > recv-msid) to focus on solving the three identified problems with MSTs in > unified-plan: > - correlation of a MediaStreamTrack to m= line in signaling (msid) > - correlation of packets from a MST to m= line ahead of signaling > (recv-msid) > - rejection of an individual MST (recv-msid) > > Based on your description, appid seems to go one or two levels down from a > MST to an individual RTP flow, but we can let that develop on its own, > separate from the timetable of webrtc 1.0 and unified plan. > > > --089e011844dad5304004f1888911 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+Harald as this affects the MSID doc


On Mon, Feb 3, 2014 at 3:00 P= M, Justin Uberti <juberti@google.com> wrote:



On Mon, Feb 3= , 2014 at 2:32 PM, Jonathan Lennox <jonathan@vidyo.com> wro= te:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com>=C2=A0wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid. =C2=A0On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?
<= div>
That would be fine by me - it would allow a = single invention (msid + recv-msid) to focus on solving the three identifie= d problems with MSTs in unified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signalin= g (recv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two leve= ls down from a MST to an individual RTP flow, but we can let that develop o= n its own, separate from the timetable of webrtc 1.0 and unified plan.



--089e011844dad5304004f1888911-- From fluffy@cisco.com Mon Feb 3 15:04: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 E22311A0282; Mon, 3 Feb 2014 15:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.036 X-Spam-Level: X-Spam-Status: No, score=-110.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, USER_IN_WHITELIST=-100] 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 GIWZ1aKynrC6; Mon, 3 Feb 2014 15:04:19 -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 A7C6B1A0267; Mon, 3 Feb 2014 15:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=556; q=dns/txt; s=iport; t=1391468659; x=1392678259; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zcCQH4Ox3RkF50xRpCJr9xU69MD1zSzBudpf2Xhhbrg=; b=IHuKhNGv5QUQ11YhAS1T1FKvx8UjsCBKpDp5V8DToW3TwlLKhgQi+ioB El6TIMB8MYGHl2X4yzg/wybufAa2W+o0a2L8HCx2DfWSSha4AIwBK7eQp 9V9l4wDc+I1En5FM+PwLlgj028ig4CnG+UQdXOWRY9GDyItjKBPi2f1gl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFACwg8FKtJXHA/2dsb2JhbABZgwyBD74SgQ4WdIIlAQEBAwF5BQsCAQgYLjIlAgQOBYd9CM4fF4Jci3kzB4MkgRQBA5gqkiGDLYIq X-IronPort-AV: E=Sophos;i="4.95,775,1384300800"; d="scan'208";a="17648626" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-4.cisco.com with ESMTP; 03 Feb 2014 23:04:08 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s13N48Ip015958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 23:04:08 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 17:04:08 -0600 From: "Cullen Jennings (fluffy)" To: Adam Roach Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIRX6Qu4MP4jRr0y9W7+nB8aK2pqkXPYAgAABqwCAAAS7AIAABcsAgAACEICAAAMlAIAADX2AgAAPCQA= Date: Mon, 3 Feb 2014 23:04:07 +0000 Message-ID: References: <52EFF9E0.40808@nostrum.com> <52EFFF3E.9080705@nostrum.com> <52F005D5.1020702@nostrum.com> <52F013C9.1090609@nostrum.com> In-Reply-To: <52F013C9.1090609@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 23:04:22 -0000 On Feb 3, 2014, at 3:10 PM, Adam Roach wrote: > On 2/3/14 15:22, Justin Uberti wrote: >>=20 >> I was thinking a=3Drecv-appId:0, which is both explicit, and has paralle= ls with the zero port form of rejecting a m=3D line. >>=20 >=20 > I have no objection to such an approach. >=20 > /a +1 with Adam on we need something explicitly somewhere.=20 If we do it with some combination msid / app-id - I just want to make sure = the behavior is still reasonable with things that don=92t low how to signal= ssrc.=20 = From jonathan@vidyo.com Mon Feb 3 15:11:52 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 962881A027B; Mon, 3 Feb 2014 15:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, 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 eP9ZrWI8L8oD; Mon, 3 Feb 2014 15:11:51 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id B53FE1A0268; Mon, 3 Feb 2014 15:11:50 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/3/2014 6:11:48 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-150/SG:5 2/3/2014 6:11:07 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.768449 p=-0.949192 Source White X-Signature-Violations: 0-0-0-12057-c X-Note-419: 15.6005 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/3/2014 6:11:30 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 94759713; Mon, 03 Feb 2014 18:11:48 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Mon, 3 Feb 2014 17:11:47 -0600 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIS46pADKsTFIzECMWWmLIWbna5qkgc6AgAAH3gCAAAMqAA== Date: Mon, 3 Feb 2014 23:11:46 +0000 Message-ID: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_9E51C939CCFE4EA683BF9B871D64CDA0vidyocom_" MIME-Version: 1.0 Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 03 Feb 2014 23:11:52 -0000 --_000_9E51C939CCFE4EA683BF9B871D64CDA0vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 3, 2014, at 6:00 PM, Justin Uberti > wrote: On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 2:27 PM, Justin Uberti > wrote: Also, this essentially makes recv-appId the converse of MSID; for simplicit= y, I think we should consider unifying these concepts into a single documen= t. AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream. For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid. On the receive side, if you wanted to receive both a primary = encoded stream and a redundancy stream, you would have two recv-appid value= s. As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea. Perhaps we need a recv-msid, explicitly? That would be fine by me - it would allow a single invention (msid + recv-m= sid) to focus on solving the three identified problems with MSTs in unified= -plan: - correlation of a MediaStreamTrack to m=3D line in signaling (msid) - correlation of packets from a MST to m=3D line ahead of signaling (recv-m= sid) - rejection of an individual MST (recv-msid) Based on your description, appid seems to go one or two levels down from a = MST to an individual RTP flow, but we can let that develop on its own, sepa= rate from the timetable of webrtc 1.0 and unified plan. Points 1 and 3 make sense to me, and are I think what msid is for; but I do= n't think point 2 will work. I don't think a single, m-line-wide, identifier will work for the correlati= on-ahead-of-signaling problem, once you have multiple RTP flows in the m-li= ne. That's why we've designed appid the way we have. I think appid is the right solution to point 2. More specifically, the pro= blem appid is solving is better expressed as the correlation of packets fro= m an RTP flow to an m-line; the correlation from the m-line to a MST is a s= eparate step, and is msid's job. --_000_9E51C939CCFE4EA683BF9B871D64CDA0vidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7C716CFFAF8E1542879164DEF9D50ECF@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Feb 3, 2014, at 6:00 PM, Justin Uberti <juberti@google.com>
 wrote:

On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com> wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid.  On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

That would be fine by me - it would allow a single invention (msid = 3; recv-msid) to focus on solving the three identified problems with MSTs i= n unified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signaling (r= ecv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two levels down fr= om a MST to an individual RTP flow, but we can let that develop on its own,= separate from the timetable of webrtc 1.0 and unified plan.

Points 1 and 3 make sense to me, and are I think what msid is for; but= I don't think point 2 will work.

I don't think a single, m-line-wide, identifier will work for the corr= elation-ahead-of-signaling problem, once you have multiple RTP flows i= n the m-line.  That's why we've designed appid the way we have.

I think appid is the right solution to point 2.  More specificall= y, the problem appid is solving is better expressed as the correlation of p= ackets from an RTP flow to an m-line; the correlation from the m-line to a = MST is a separate step, and is msid's job.


--_000_9E51C939CCFE4EA683BF9B871D64CDA0vidyocom_-- From juberti@google.com Mon Feb 3 16:05: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 B0EB21A02B5 for ; Mon, 3 Feb 2014 16:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.535, 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 DhCyANJqWXJv for ; Mon, 3 Feb 2014 16:05:37 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B46A91A029F for ; Mon, 3 Feb 2014 16:05:36 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so5376073vcb.3 for ; Mon, 03 Feb 2014 16:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7T/G6xCNG5X0+ybGVe9syqSR6QssH3tLZ7VPCIXII0Q=; b=mE7oCMucOTZl2CDcWx/RHTiFQKFoon9IrL3dyOAHZfHXZO7N0o7sdmSUokZMLPD+i5 bt4LVo4p17RsGj+4E8zfLgUHcB7MHDiM8J1zQDpeVoY2qRwIR13O5PZ4kHXoMGl1WqhJ Gat82KKN/ZY8noy7ZnqYK5k9NQT9eBlVN0hcOL8HKkK7A17rYIOGNF/DeSCctRF5S6WZ wJkVpndUOAKuhawlSu8YYyha+4reB842NEixQWNiLEnUyIAYtsf1d/ZJHw/6A4OgS1s2 QwoKDu1xiy/K8Hi21/jyqzkcmy0vIsNYclTATnTMte7cXS7lkLheFH1lpJU+bvY4D5ZJ iWLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7T/G6xCNG5X0+ybGVe9syqSR6QssH3tLZ7VPCIXII0Q=; b=mPzp6/wvVNmEiqi/c0iFuWP6muzq6403Ez/+9PP0FAyo94odB84Nv45nWTBh4/GE4e HX7fvnZLjhCFPO047a+TEaf51Neekpax24dqD486doPaG9ZHj19gVT1xPVMsk4BKBjzO q/0D0IxrjTex0SX131fonxNESiujsuvUfYwai3QJvvDJ42t0ewbY40qRchS2kP/c9BMo QZ3aVtrxtHhHx+PoiTKO2b9TAMryqEPpRcdNHAhoVpR71sk2larEtSVADPAletIrP9K1 d2/uyKz4xDky9zcmRJyQemMQ5MedxnMI/XtDkStUiHDClGqGgvVD3Tbirp0h5Z5aDEXo oQLw== X-Gm-Message-State: ALoCoQk8XTdZeB3qJrml7bZ9mhtCAJQL49l58e2PAkkDrXqyMnXxP6dU45stTBXKxRMkZKMyMXv6RSQt1ndXjALZqqhEQdWT9Hkwuz9C7I7b/LZYqPQ4Q1Ta5jPqAX00qTv93nDmAnOU13pRWu8NPmpeIZMJN7Znq4KN/dILC5sTtgVd4Y1xaLxEdXvbHpF+oyE/2Pfb1ygY X-Received: by 10.53.1.231 with SMTP id bj7mr611vdd.55.1391472336273; Mon, 03 Feb 2014 16:05:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 16:05:15 -0800 (PST) In-Reply-To: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> From: Justin Uberti Date: Mon, 3 Feb 2014 16:05:15 -0800 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a1133ed3a51b0a304f1896696 Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 04 Feb 2014 00:05:40 -0000 --001a1133ed3a51b0a304f1896696 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox wrote: > > On Feb 3, 2014, at 6:00 PM, Justin Uberti > wrote: > > On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox wrote: > >> On Feb 3, 2014, at 2:27 PM, Justin Uberti wrote: >> >> Also, this essentially makes recv-appId the converse of MSID; for >> simplicity, I think we should consider unifying these concepts into a >> single document. >> >> >> AppID (as I envision it, as the author) and MSID (as I understand it) >> have rather different scopes, which are visible once sources are sent using >> more than one packet stream. >> >> For example, an m-line which has both a primary encoded stream (of >> media) and a redundancy stream (of rtx packets) would have two appid >> values, but only one msid. On the receive side, if you wanted to receive >> both a primary encoded stream and a redundancy stream, you would have two >> recv-appid values. >> >> As such, appid and msid are solving different (though related) >> problems, and I don't think unifying them is a good idea. >> >> Perhaps we need a recv-msid, explicitly? >> > > That would be fine by me - it would allow a single invention (msid + > recv-msid) to focus on solving the three identified problems with MSTs in > unified-plan: > - correlation of a MediaStreamTrack to m= line in signaling (msid) > - correlation of packets from a MST to m= line ahead of signaling > (recv-msid) > - rejection of an individual MST (recv-msid) > > Based on your description, appid seems to go one or two levels down from > a MST to an individual RTP flow, but we can let that develop on its own, > separate from the timetable of webrtc 1.0 and unified plan. > > > Points 1 and 3 make sense to me, and are I think what msid is for; but I > don't think point 2 will work. > > I don't think a single, m-line-wide, identifier will work for the > correlation-ahead-of-signaling problem, once you have multiple RTP flows in > the m-line. That's why we've designed appid the way we have. > > I think appid is the right solution to point 2. More specifically, the > problem appid is solving is better expressed as the correlation of packets > from an RTP flow to an m-line; the correlation from the m-line to a MST is > a separate step, and is msid's job. > Agree that msid should map m-line to MST, but it would seem recv-msid could map RTP flow to m=line as well as indicate whether the receiver is in fact interested in receiving the MST associated with said m= line. Note that recv-msid doesn't specify an actual MSID; its purpose is to indicate that the receiver wants to receive data from the remote side's MST, and provide a mechanism for the sender to mark the data accordingly. (Which ends up seeming a lot like appid.) Generally, I am hesitant to depend on 3 things if we think we could get by with only 2. --001a1133ed3a51b0a304f1896696 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox &= lt;jonathan@vidyo.c= om> wrote:

On Feb 3, 2014, at 6:00 PM, Justin Uberti <juberti@google.com>
=C2=A0wrote:

On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com>=C2=A0wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid. =C2=A0On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

That would be fine by me - it would allow a single invention (msid + r= ecv-msid) to focus on solving the three identified problems with MSTs in un= ified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signaling (r= ecv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two levels down fr= om a MST to an individual RTP flow, but we can let that develop on its own,= separate from the timetable of webrtc 1.0 and unified plan.

Points 1 and 3 make sense to me, and are I think what msid is for; but= I don't think point 2 will work.

I don't think a single, m-line-wide, identifier will work for the = correlation-ahead-of-signaling=C2=A0problem, once you have multiple RTP flo= ws in the m-line. =C2=A0That's why we've designed appid the way we = have.

I think appid is the right solution to point 2. =C2=A0More specificall= y, the problem appid is solving is better expressed as the correlation of p= ackets from an RTP flow to an m-line; the correlation from the m-line to a = MST is a separate step, and is msid's job.

Agree that msid should ma= p m-line to MST, but it would seem recv-msid could map RTP flow to m=3Dline= as well as indicate whether the receiver is in fact interested in receivin= g the MST associated with said m=3D line. Note that recv-msid doesn't s= pecify an actual MSID; its purpose is to indicate that the receiver wants t= o receive data from the remote side's MST, and provide a mechanism for = the sender to mark the data accordingly. (Which ends up seeming a lot like = appid.)

Generally, I am hesitant to depend on 3 things if we th= ink we could get by with only 2.

--001a1133ed3a51b0a304f1896696-- From Simo.Veikkolainen@nokia.com Mon Feb 3 23:19: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 58D161A0382 for ; Mon, 3 Feb 2014 23:19:07 -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 HHFEKJdiHYCB for ; Mon, 3 Feb 2014 23:19:03 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A90071A0381 for ; Mon, 3 Feb 2014 23:19:03 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.58]) by mgw-da01.nokia.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s147IQQW022599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 4 Feb 2014 09:18:27 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.28]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.03.0158.002; Tue, 4 Feb 2014 07:18:25 +0000 From: To: , Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt Thread-Index: AQHPHm620e/80jfD1UW9be2tq4vEmZqeqHFwgACF+wCABX36kA== Date: Tue, 4 Feb 2014 07:18:25 +0000 Message-ID: References: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> <52EBF104.7000303@alum.mit.edu> In-Reply-To: <52EBF104.7000303@alum.mit.edu> 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 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: Tue, 04 Feb 2014 07:19:07 -0000 -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Paul Kyzivat Sent: 31 January, 2014 20:53 To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt I just reviewed the new version. First I looked at just the diffs. But thos= e raised some more general questions in my mind, so I re-reviewed more of t= he draft. I'm left with some considerable confusion about how this is inten= ded 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, correlatio= n processing, and signaling completion. (I realize this is an mmusic draft = and theoretically independent of sip, but forgive me if I discuss this in t= he context of sip.) Normally, when first establishing a session with sip, the first O/A may occ= ur before the signaling session is established. But early media may flow af= ter 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 suppose= d to continue as it was before the reinvite. In the interim, from the sendi= ng of the reinvite until its success or failure, things are a little confus= ing - presumably both old and new media streams must be maintained, but whi= ch 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? [SV] I assume you mean the 200 carries the Answer. It may happen that the C= S call arrives before the Answer, but in this case no correlation can be do= ne. See Section 5.6.3. If the invite (I assume you mean O/A) completes firs= t, but no CS call ever arrives, or correlation - including the "external" m= echanism fails, the endpoint should treat the CS call as unrelated; this is= described in Section 5.3.3. - 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?) [SV] CS media starts to flow after the call has been accepted, as in a norm= al CS call. Correlation may be possible before accepting the call (for "cal= lerid", "uuie", and "external" mechanisms), and for "dtmf" case only after = the call has been accepted. - if media flows to the user before correlation, then what if correlation fails? Will another call be accepted and correlation be attempted again? [SV] I don' think we have explicitly defined this situation. If a call is a= ccepted and *after* that correlation fails, it means that the DTMF mechanis= m was used (for other correlation mechanisms, we know before accepting the = call whether the correlation was successful). If the DTMF pattern is not re= ceived correctly, as we cannot know whether it is related to the session or= not. Now, this raises a possible case of including both "dtmf" and "extern= al" mechanisms in the O/A. If DTMF is successfully negotiated but it fails,= we can't really use the "external" mechanism since the call is already acc= epted. Implementations could in this case release the CS call and try a new= O/A without the DTMF. - 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.) [SV] This would be an issue for the DTMF case, as there correlation can be = only only after accepting the CS call. An unlikely case, but still possible= . In this case, one of the CS calls could be related to the session, while = other(s) would be normal CS calls. As only one CS call can be handled at a = time, others would either wait or be terminated, depending on the callee's = supplementary services settings.=20 - 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? [SV] The external correlation mechanism does not assume the media flows bef= ore "correlation" is made - if the user decides to accept the incoming call= , it is considered as "correlated".=20 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. [SV] For being able to perform correlation, yes, the Answer needs to be rec= eived. - 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. [SV] The O/A needs to be completed before correlation can be done, but CS c= all may arrive before Answer. In this case the endpoint should wait until t= he Answer is received. If the CS call does not succeed, or correlation is u= nsuccessful, then yes there is no media as the RTP stream has been dropped.= But, this could also happen when re-negotiating RTP media types (endpoints= are not able to load correct codecs, new IP addr/port does not work etc.) = so the situation not be specific to the CS media type. - all the issues above also apply here. ISTM that there is a bunch of missing explanation of how this is expected t= o work. [SV] Could you check the above whether my comments clarify the situation. W= e can address them in more details in the draft as well once we know where = more explanation is needed. 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" [SV] Fill fix. Thanks, Simo Thanks, Paul On 1/31/14 6:01 AM, Simo.Veikkolainen@nokia.com wrote: > Hello WG, > > We have submitted a new version of=20 > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-22 > > To recap, there was discussion on the MMUSIC WG list on which correlatio= n mechanisms should be mandatory to implement (see Gonzalo's email http://w= ww.ietf.org/mail-archive/web/mmusic/current/msg12274.html ). As stated by G= onzalo, 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 go= t 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 (befo= re all three were MTI). > - we have introduced a fourth correlation type ("external") which indicat= es 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 whe= re no other common correlation mechanism is found, or the negotiated correl= ation 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 wh= ere Gonzalo presented the draft. > > We would like to hear from the WG whether there are any concerns with the= se 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=20 > 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 direct= ories. > This draft is a work item of the Multiparty Multimedia Session Control = Working Group of the IETF. > > Title : Session Description Protocol (SDP) Extension F= or Setting Audio and Video Media Streams Over Circuit-Switched Bearers In T= he 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 submiss= ion 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 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Tue Feb 4 06:13:41 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 586B11A00E9; Tue, 4 Feb 2014 06:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 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_14=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 HyCz_GhlXBrh; Tue, 4 Feb 2014 06:13:39 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 087FD1A00DB; Tue, 4 Feb 2014 06:13:37 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-dd-52f0f5901be8 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 6B.1F.04853.095F0F25; Tue, 4 Feb 2014 15:13:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Tue, 4 Feb 2014 15:13:36 +0100 From: Christer Holmberg To: Justin Uberti , Jonathan Lennox Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIRX+Di2Spk3Lw0GdFyTxI3EbsJqkDKaAgAAH3QCAAAMrAIAADvGAgAD9W7A= Date: Tue, 4 Feb 2014 14:13:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15868E@ESESSMB209.ericsson.se> References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> 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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D15868EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3RnfC1w9BBgsumFh0TGazOHHjNLPF /sXnmS22ThWymLr8MYvF2n/t7A5sHlN+b2T1WLCp1GPJkp9MHm3P7rAHsERx2aSk5mSWpRbp 2yVwZVz4NJ+9YEknY8XO/bOYGhjPtDJ2MXJySAiYSMz//4INwhaTuHBvPZgtJHCCUWLxbaUu Ri4gexGjxM5dJ9i7GDk42AQsJLr/aYOYIgI+Em82CYKUMAt0M0pcPNQDNlNYwFLiTsN9doga K4mV19NBwiICfhLfvl9gAbFZBFQkJm6aBmbzCvhKtD++ywKx6giTxPE/R9lBEpwCgRLTV3Uy gdiMQLd9P7UGzGYWEJe49WQ+E8TNAhJL9pxnhrBFJV4+/scKYStKtD9tYAS5gVkgX+LtKR2I XYISJ2c+YZnAKDoLyaRZCFWzkFRBhDUl1u/Sh6hWlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypGyeLU 4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMBIPbjlt9EOxpN77A8xSnOwKInzXmetCRISSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXAmBl8OYO5yLhWdu3NiwaTy06on5JecXTdeY7iIs6+byw9 m66aVi7w9OPf1bDlkfriWEWvTqkd87atnljZk2kj0+P1dvanSk9lwazly9P9JxlWq67O/pvs zMjBwHtJM1JWyq6peHPRq425/yarTHlp0vrg8LQTCU5m7O8V/rMe0TJcuPun3hM/JZbijERD Leai4kQAZrZ5g6ICAAA= Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 04 Feb 2014 14:13:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D15868EESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkp1c3QgZm9yIG15IGNsYXJpZmljYXRpb246IG5vbmUgb2YgdGhpcyB3b3VsZCBoYXZl IGFueSBpbXBhY3Qgb24gdHJhbnNwb3J0IGxldmVsIGZlYXR1cmVzIHJlbGF0ZWQgdG8gUlRDUCwg U1RVTiwgZXRjPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFp bHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0K U2VudDogNC4gaGVsbWlrdXV0YSAyMDE0IDI6MDUNClRvOiBKb25hdGhhbiBMZW5ub3gNCkNjOiBD dWxsZW4gSmVubmluZ3M7IEhhcmFsZCBBbHZlc3RyYW5kOyBydGN3ZWJAaWV0Zi5vcmc7IG1tdXNp Yw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFJlamVjdGluZyBNZWRpYVN0cmVhbVRyYWNrcyBpbiBK U0VQDQoNCg0KDQpPbiBNb24sIEZlYiAzLCAyMDE0IGF0IDM6MTEgUE0sIEpvbmF0aGFuIExlbm5v eCA8am9uYXRoYW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PiB3cm90ZToN Cg0KT24gRmViIDMsIDIwMTQsIGF0IDY6MDAgUE0sIEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29v Z2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4NCiB3cm90ZToNCg0KDQpPbiBNb24s IEZlYiAzLCAyMDE0IGF0IDI6MzIgUE0sIEpvbmF0aGFuIExlbm5veCA8am9uYXRoYW5AdmlkeW8u Y29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PiB3cm90ZToNCk9uIEZlYiAzLCAyMDE0LCBh dCAyOjI3IFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVy dGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQoNCkFsc28sIHRoaXMgZXNzZW50aWFsbHkgbWFrZXMg cmVjdi1hcHBJZCB0aGUgY29udmVyc2Ugb2YgTVNJRDsgZm9yIHNpbXBsaWNpdHksIEkgdGhpbmsg d2Ugc2hvdWxkIGNvbnNpZGVyIHVuaWZ5aW5nIHRoZXNlIGNvbmNlcHRzIGludG8gYSBzaW5nbGUg ZG9jdW1lbnQuDQoNCkFwcElEIChhcyBJIGVudmlzaW9uIGl0LCBhcyB0aGUgYXV0aG9yKSBhbmQg TVNJRCAoYXMgSSB1bmRlcnN0YW5kIGl0KSBoYXZlIHJhdGhlciBkaWZmZXJlbnQgc2NvcGVzLCB3 aGljaCBhcmUgdmlzaWJsZSBvbmNlIHNvdXJjZXMgYXJlIHNlbnQgdXNpbmcgbW9yZSB0aGFuIG9u ZSBwYWNrZXQgc3RyZWFtLg0KDQpGb3IgZXhhbXBsZSwgYW4gbS1saW5lIHdoaWNoIGhhcyBib3Ro IGEgcHJpbWFyeSBlbmNvZGVkIHN0cmVhbSAob2YgbWVkaWEpIGFuZCBhIHJlZHVuZGFuY3kgc3Ry ZWFtIChvZiBydHggcGFja2V0cykgd291bGQgaGF2ZSB0d28gYXBwaWQgdmFsdWVzLCBidXQgb25s eSBvbmUgbXNpZC4gIE9uIHRoZSByZWNlaXZlIHNpZGUsIGlmIHlvdSB3YW50ZWQgdG8gcmVjZWl2 ZSBib3RoIGEgcHJpbWFyeSBlbmNvZGVkIHN0cmVhbSBhbmQgYSByZWR1bmRhbmN5IHN0cmVhbSwg eW91IHdvdWxkIGhhdmUgdHdvIHJlY3YtYXBwaWQgdmFsdWVzLg0KDQpBcyBzdWNoLCBhcHBpZCBh bmQgbXNpZCBhcmUgc29sdmluZyBkaWZmZXJlbnQgKHRob3VnaCByZWxhdGVkKSBwcm9ibGVtcywg YW5kIEkgZG9uJ3QgdGhpbmsgdW5pZnlpbmcgdGhlbSBpcyBhIGdvb2QgaWRlYS4NCg0KUGVyaGFw cyB3ZSBuZWVkIGEgcmVjdi1tc2lkLCBleHBsaWNpdGx5Pw0KDQpUaGF0IHdvdWxkIGJlIGZpbmUg YnkgbWUgLSBpdCB3b3VsZCBhbGxvdyBhIHNpbmdsZSBpbnZlbnRpb24gKG1zaWQgKyByZWN2LW1z aWQpIHRvIGZvY3VzIG9uIHNvbHZpbmcgdGhlIHRocmVlIGlkZW50aWZpZWQgcHJvYmxlbXMgd2l0 aCBNU1RzIGluIHVuaWZpZWQtcGxhbjoNCi0gY29ycmVsYXRpb24gb2YgYSBNZWRpYVN0cmVhbVRy YWNrIHRvIG09IGxpbmUgaW4gc2lnbmFsaW5nIChtc2lkKQ0KLSBjb3JyZWxhdGlvbiBvZiBwYWNr ZXRzIGZyb20gYSBNU1QgdG8gbT0gbGluZSBhaGVhZCBvZiBzaWduYWxpbmcgKHJlY3YtbXNpZCkN Ci0gcmVqZWN0aW9uIG9mIGFuIGluZGl2aWR1YWwgTVNUIChyZWN2LW1zaWQpDQoNCkJhc2VkIG9u IHlvdXIgZGVzY3JpcHRpb24sIGFwcGlkIHNlZW1zIHRvIGdvIG9uZSBvciB0d28gbGV2ZWxzIGRv d24gZnJvbSBhIE1TVCB0byBhbiBpbmRpdmlkdWFsIFJUUCBmbG93LCBidXQgd2UgY2FuIGxldCB0 aGF0IGRldmVsb3Agb24gaXRzIG93biwgc2VwYXJhdGUgZnJvbSB0aGUgdGltZXRhYmxlIG9mIHdl YnJ0YyAxLjAgYW5kIHVuaWZpZWQgcGxhbi4NCg0KUG9pbnRzIDEgYW5kIDMgbWFrZSBzZW5zZSB0 byBtZSwgYW5kIGFyZSBJIHRoaW5rIHdoYXQgbXNpZCBpcyBmb3I7IGJ1dCBJIGRvbid0IHRoaW5r IHBvaW50IDIgd2lsbCB3b3JrLg0KDQpJIGRvbid0IHRoaW5rIGEgc2luZ2xlLCBtLWxpbmUtd2lk ZSwgaWRlbnRpZmllciB3aWxsIHdvcmsgZm9yIHRoZSBjb3JyZWxhdGlvbi1haGVhZC1vZi1zaWdu YWxpbmcgcHJvYmxlbSwgb25jZSB5b3UgaGF2ZSBtdWx0aXBsZSBSVFAgZmxvd3MgaW4gdGhlIG0t bGluZS4gIFRoYXQncyB3aHkgd2UndmUgZGVzaWduZWQgYXBwaWQgdGhlIHdheSB3ZSBoYXZlLg0K DQpJIHRoaW5rIGFwcGlkIGlzIHRoZSByaWdodCBzb2x1dGlvbiB0byBwb2ludCAyLiAgTW9yZSBz cGVjaWZpY2FsbHksIHRoZSBwcm9ibGVtIGFwcGlkIGlzIHNvbHZpbmcgaXMgYmV0dGVyIGV4cHJl c3NlZCBhcyB0aGUgY29ycmVsYXRpb24gb2YgcGFja2V0cyBmcm9tIGFuIFJUUCBmbG93IHRvIGFu IG0tbGluZTsgdGhlIGNvcnJlbGF0aW9uIGZyb20gdGhlIG0tbGluZSB0byBhIE1TVCBpcyBhIHNl cGFyYXRlIHN0ZXAsIGFuZCBpcyBtc2lkJ3Mgam9iLg0KDQpBZ3JlZSB0aGF0IG1zaWQgc2hvdWxk IG1hcCBtLWxpbmUgdG8gTVNULCBidXQgaXQgd291bGQgc2VlbSByZWN2LW1zaWQgY291bGQgbWFw IFJUUCBmbG93IHRvIG09bGluZSBhcyB3ZWxsIGFzIGluZGljYXRlIHdoZXRoZXIgdGhlIHJlY2Vp dmVyIGlzIGluIGZhY3QgaW50ZXJlc3RlZCBpbiByZWNlaXZpbmcgdGhlIE1TVCBhc3NvY2lhdGVk IHdpdGggc2FpZCBtPSBsaW5lLiBOb3RlIHRoYXQgcmVjdi1tc2lkIGRvZXNuJ3Qgc3BlY2lmeSBh biBhY3R1YWwgTVNJRDsgaXRzIHB1cnBvc2UgaXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgcmVjZWl2 ZXIgd2FudHMgdG8gcmVjZWl2ZSBkYXRhIGZyb20gdGhlIHJlbW90ZSBzaWRlJ3MgTVNULCBhbmQg cHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgdGhlIHNlbmRlciB0byBtYXJrIHRoZSBkYXRhIGFjY29y ZGluZ2x5LiAoV2hpY2ggZW5kcyB1cCBzZWVtaW5nIGEgbG90IGxpa2UgYXBwaWQuKQ0KDQpHZW5l cmFsbHksIEkgYW0gaGVzaXRhbnQgdG8gZGVwZW5kIG9uIDMgdGhpbmdzIGlmIHdlIHRoaW5rIHdl IGNvdWxkIGdldCBieSB3aXRoIG9ubHkgMi4NCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D15868EESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SnVzdCBmb3IgbXkgY2xhcmlmaWNhdGlvbjogbm9uZSBvZiB0aGlzIHdvdWxkIGhhdmUg YW55IGltcGFjdCBvbiB0cmFuc3BvcnQgbGV2ZWwgZmVhdHVyZXMgcmVsYXRlZCB0byBSVENQLCBT VFVOLCBldGM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiA0LiBoZWxt aWt1dXRhIDIwMTQgMjowNTxicj4NCjxiPlRvOjwvYj4gSm9uYXRoYW4gTGVubm94PGJyPg0KPGI+ Q2M6PC9iPiBDdWxsZW4gSmVubmluZ3M7IEhhcmFsZCBBbHZlc3RyYW5kOyBydGN3ZWJAaWV0Zi5v cmc7IG1tdXNpYzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUmVqZWN0aW5nIE1l ZGlhU3RyZWFtVHJhY2tzIGluIEpTRVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRmViIDMsIDIwMTQgYXQgMzoxMSBQTSwgSm9u YXRoYW4gTGVubm94ICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIiB0YXJn ZXQ9Il9ibGFuayI+am9uYXRoYW5AdmlkeW8uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAzLCAyMDE0LCBhdCA2OjAw IFBNLCBKdXN0aW4gVWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBNb24sIEZlYiAzLCAyMDE0IGF0IDI6MzIgUE0sIEpvbmF0aGFuIExlbm5veCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvbmF0 aGFuQHZpZHlvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAzLCAyMDE0 LCBhdCAyOjI3IFBNLCBKdXN0aW4gVWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDsmbmJz cDt3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWxzbywgdGhpcyBl c3NlbnRpYWxseSBtYWtlcyByZWN2LWFwcElkIHRoZSBjb252ZXJzZSBvZiBNU0lEOyBmb3Igc2lt cGxpY2l0eSwgSSB0aGluayB3ZSBzaG91bGQgY29uc2lkZXIgdW5pZnlpbmcgdGhlc2UgY29uY2Vw dHMgaW50byBhIHNpbmdsZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXBwSUQgKGFz IEkgZW52aXNpb24gaXQsIGFzIHRoZSBhdXRob3IpIGFuZCBNU0lEIChhcyBJIHVuZGVyc3RhbmQg aXQpIGhhdmUgcmF0aGVyIGRpZmZlcmVudCBzY29wZXMsIHdoaWNoIGFyZSB2aXNpYmxlIG9uY2Ug c291cmNlcyBhcmUgc2VudCB1c2luZyBtb3JlIHRoYW4gb25lIHBhY2tldCBzdHJlYW0uDQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlLCBh biBtLWxpbmUgd2hpY2ggaGFzIGJvdGggYSBwcmltYXJ5IGVuY29kZWQgc3RyZWFtIChvZiBtZWRp YSkgYW5kIGEgcmVkdW5kYW5jeSBzdHJlYW0gKG9mIHJ0eCBwYWNrZXRzKSB3b3VsZCBoYXZlIHR3 byBhcHBpZCB2YWx1ZXMsIGJ1dCBvbmx5IG9uZSBtc2lkLiAmbmJzcDtPbiB0aGUgcmVjZWl2ZSBz aWRlLCBpZiB5b3Ugd2FudGVkIHRvIHJlY2VpdmUgYm90aCBhIHByaW1hcnkgZW5jb2RlZCBzdHJl YW0NCiBhbmQgYSByZWR1bmRhbmN5IHN0cmVhbSwgeW91IHdvdWxkIGhhdmUgdHdvIHJlY3YtYXBw aWQgdmFsdWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BcyBzdWNoLCBhcHBpZCBhbmQgbXNpZCBhcmUgc29sdmluZyBkaWZmZXJlbnQgKHRo b3VnaCByZWxhdGVkKSBwcm9ibGVtcywgYW5kIEkgZG9uJ3QgdGhpbmsgdW5pZnlpbmcgdGhlbSBp cyBhIGdvb2QgaWRlYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UGVyaGFwcyB3ZSBuZWVkIGEgcmVjdi1tc2lkLCBleHBsaWNpdGx5PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYXQgd291bGQgYmUgZmluZSBieSBtZSAtIGl0IHdvdWxkIGFsbG93 IGEgc2luZ2xlIGludmVudGlvbiAobXNpZCAmIzQzOyByZWN2LW1zaWQpIHRvIGZvY3VzIG9uIHNv bHZpbmcgdGhlIHRocmVlIGlkZW50aWZpZWQgcHJvYmxlbXMgd2l0aCBNU1RzIGluIHVuaWZpZWQt cGxhbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0gY29ycmVsYXRpb24gb2YgYSBNZWRpYVN0cmVhbVRyYWNrIHRvIG09IGxpbmUgaW4gc2lnbmFs aW5nIChtc2lkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LSBjb3JyZWxhdGlvbiBvZiBwYWNrZXRzIGZyb20gYSBNU1QgdG8gbT0gbGluZSBhaGVh ZCBvZiBzaWduYWxpbmcgKHJlY3YtbXNpZCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gcmVqZWN0aW9uIG9mIGFuIGluZGl2aWR1YWwgTVNUIChy ZWN2LW1zaWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJhc2VkIG9uIHlvdXIgZGVzY3JpcHRpb24sIGFwcGlkIHNlZW1zIHRvIGdvIG9uZSBv ciB0d28gbGV2ZWxzIGRvd24gZnJvbSBhIE1TVCB0byBhbiBpbmRpdmlkdWFsIFJUUCBmbG93LCBi dXQgd2UgY2FuIGxldCB0aGF0IGRldmVsb3Agb24gaXRzIG93biwgc2VwYXJhdGUgZnJvbSB0aGUg dGltZXRhYmxlIG9mIHdlYnJ0YyAxLjAgYW5kIHVuaWZpZWQgcGxhbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UG9pbnRzIDEgYW5kIDMgbWFrZSBzZW5zZSB0byBtZSwgYW5kIGFyZSBJ IHRoaW5rIHdoYXQgbXNpZCBpcyBmb3I7IGJ1dCBJIGRvbid0IHRoaW5rIHBvaW50IDIgd2lsbCB3 b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGRvbid0IHRoaW5rIGEgc2luZ2xlLCBtLWxpbmUtd2lkZSwgaWRlbnRpZmllciB3aWxsIHdv cmsgZm9yIHRoZSBjb3JyZWxhdGlvbi1haGVhZC1vZi1zaWduYWxpbmcmbmJzcDtwcm9ibGVtLCBv bmNlIHlvdSBoYXZlIG11bHRpcGxlIFJUUCBmbG93cyBpbiB0aGUgbS1saW5lLiAmbmJzcDtUaGF0 J3Mgd2h5IHdlJ3ZlIGRlc2lnbmVkIGFwcGlkIHRoZSB3YXkgd2UgaGF2ZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdGhpbmsgYXBwaWQgaXMgdGhlIHJpZ2h0IHNvbHV0aW9uIHRvIHBvaW50 IDIuICZuYnNwO01vcmUgc3BlY2lmaWNhbGx5LCB0aGUgcHJvYmxlbSBhcHBpZCBpcyBzb2x2aW5n IGlzIGJldHRlciBleHByZXNzZWQgYXMgdGhlIGNvcnJlbGF0aW9uIG9mIHBhY2tldHMgZnJvbSBh biBSVFAgZmxvdyB0byBhbiBtLWxpbmU7IHRoZSBjb3JyZWxhdGlvbiBmcm9tIHRoZSBtLWxpbmUg dG8gYSBNU1QgaXMgYSBzZXBhcmF0ZSBzdGVwLA0KIGFuZCBpcyBtc2lkJ3Mgam9iLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFncmVlIHRoYXQgbXNpZCBzaG91bGQgbWFwIG0tbGluZSB0byBNU1QsIGJ1 dCBpdCB3b3VsZCBzZWVtIHJlY3YtbXNpZCBjb3VsZCBtYXAgUlRQIGZsb3cgdG8gbT1saW5lIGFz IHdlbGwgYXMgaW5kaWNhdGUgd2hldGhlciB0aGUgcmVjZWl2ZXIgaXMgaW4gZmFjdCBpbnRlcmVz dGVkIGluIHJlY2VpdmluZyB0aGUgTVNUIGFzc29jaWF0ZWQgd2l0aCBzYWlkIG09IGxpbmUuIE5v dGUgdGhhdCByZWN2LW1zaWQgZG9lc24ndA0KIHNwZWNpZnkgYW4gYWN0dWFsIE1TSUQ7IGl0cyBw dXJwb3NlIGlzIHRvIGluZGljYXRlIHRoYXQgdGhlIHJlY2VpdmVyIHdhbnRzIHRvIHJlY2VpdmUg ZGF0YSBmcm9tIHRoZSByZW1vdGUgc2lkZSdzIE1TVCwgYW5kIHByb3ZpZGUgYSBtZWNoYW5pc20g Zm9yIHRoZSBzZW5kZXIgdG8gbWFyayB0aGUgZGF0YSBhY2NvcmRpbmdseS4gKFdoaWNoIGVuZHMg dXAgc2VlbWluZyBhIGxvdCBsaWtlIGFwcGlkLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2VuZXJhbGx5LCBJIGFtIGhlc2l0YW50IHRvIGRl cGVuZCBvbiAzIHRoaW5ncyBpZiB3ZSB0aGluayB3ZSBjb3VsZCBnZXQgYnkgd2l0aCBvbmx5IDIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D15868EESESSMB209erics_-- From jonathan@vidyo.com Tue Feb 4 08:13: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 C60121A013B; Tue, 4 Feb 2014 08:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_SORBS_WEB=0.77, 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 65G6kVnehdtX; Tue, 4 Feb 2014 08:13:10 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1F81A0130; Tue, 4 Feb 2014 08:13:10 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/4/2014 11:13:08 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-340/SG:5 2/4/2014 11:12:32 AM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.737366 p=-0.935988 Source White X-Signature-Violations: 0-0-0-17513-c X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/4/2014 11:12:55 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 69264762; Tue, 04 Feb 2014 11:13:07 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Tue, 4 Feb 2014 10:13:06 -0600 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIS46pADKsTFIzECMWWmLIWbna5qkgc6AgAAH3gCAAAMqAIAADvKAgAEOagA= Date: Tue, 4 Feb 2014 16:13:06 +0000 Message-ID: <2DF6D660-78B3-4F53-AF39-B3651E9BBB46@vidyo.com> References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_2DF6D66078B34F53AF39B3651E9BBB46vidyocom_" MIME-Version: 1.0 Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 04 Feb 2014 16:13:12 -0000 --_000_2DF6D66078B34F53AF39B3651E9BBB46vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 3, 2014, at 7:05 PM, Justin Uberti > wrote: On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 6:00 PM, Justin Uberti > wrote: On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 2:27 PM, Justin Uberti > wrote: Also, this essentially makes recv-appId the converse of MSID; for simplicit= y, I think we should consider unifying these concepts into a single documen= t. AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream. For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid. On the receive side, if you wanted to receive both a primary = encoded stream and a redundancy stream, you would have two recv-appid value= s. As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea. Perhaps we need a recv-msid, explicitly? That would be fine by me - it would allow a single invention (msid + recv-m= sid) to focus on solving the three identified problems with MSTs in unified= -plan: - correlation of a MediaStreamTrack to m=3D line in signaling (msid) - correlation of packets from a MST to m=3D line ahead of signaling (recv-m= sid) - rejection of an individual MST (recv-msid) Based on your description, appid seems to go one or two levels down from a = MST to an individual RTP flow, but we can let that develop on its own, sepa= rate from the timetable of webrtc 1.0 and unified plan. Points 1 and 3 make sense to me, and are I think what msid is for; but I do= n't think point 2 will work. I don't think a single, m-line-wide, identifier will work for the correlati= on-ahead-of-signaling problem, once you have multiple RTP flows in the m-li= ne. That's why we've designed appid the way we have. I think appid is the right solution to point 2. More specifically, the pro= blem appid is solving is better expressed as the correlation of packets fro= m an RTP flow to an m-line; the correlation from the m-line to a MST is a s= eparate step, and is msid's job. Agree that msid should map m-line to MST, but it would seem recv-msid could= map RTP flow to m=3Dline as well as indicate whether the receiver is in fa= ct interested in receiving the MST associated with said m=3D line. Note tha= t recv-msid doesn't specify an actual MSID; its purpose is to indicate that= the receiver wants to receive data from the remote side's MST, and provide= a mechanism for the sender to mark the data accordingly. (Which ends up se= eming a lot like appid.) Generally, I am hesitant to depend on 3 things if we think we could get by = with only 2. I understand that, but I'm also hesitant to have one mechanism do two (it s= eems to me) fairly unrelated things, especially where the scenarios in whic= h the problems it's solving are applicable vary fairly widely. As far as I can tell, the only use case anyone's identified for MSID is Web= RTC, whereas the disambiguation problem occurs (and thus appid and recv-app= id are applicable) for anything using Bundle with Unified-like semantics. --_000_2DF6D66078B34F53AF39B3651E9BBB46vidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 3, 2014, at 7:05 PM, Justin Uberti <juberti@google.com>
 wrote:

On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:

On Feb 3, 2014, at 6:00 PM, Justin Uberti <juberti@google.com>
 wrote:

On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com> wrote:

Also, this essen= tially makes recv-appId the converse of MSID; for simplicity, I think we sh= ould consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.

For example, an m-line which has both a primary encoded stream (of med= ia) and a redundancy stream (of rtx packets) would have two appid values, b= ut only one msid.  On the receive side, if you wanted to receive both = a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problem= s, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

That would be fine by me - it would allow a single invention (msid = 3; recv-msid) to focus on solving the three identified problems with MSTs i= n unified-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signaling (r= ecv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two levels down fr= om a MST to an individual RTP flow, but we can let that develop on its own,= separate from the timetable of webrtc 1.0 and unified plan.

Points 1 and 3 make sense to me, and are I think what msid is for; but= I don't think point 2 will work.

I don't think a single, m-line-wide, identifier will work for the corr= elation-ahead-of-signaling problem, once you have multiple RTP flows i= n the m-line.  That's why we've designed appid the way we have.

I think appid is the right solution to point 2.  More specificall= y, the problem appid is solving is better expressed as the correlation of p= ackets from an RTP flow to an m-line; the correlation from the m-line to a = MST is a separate step, and is msid's job.

Agree that msid should map m-line to MST, but it would seem recv-msid = could map RTP flow to m=3Dline as well as indicate whether the receiver is = in fact interested in receiving the MST associated with said m=3D line. Not= e that recv-msid doesn't specify an actual MSID; its purpose is to indicate that the receiver wants to receive= data from the remote side's MST, and provide a mechanism for the sender to= mark the data accordingly. (Which ends up seeming a lot like appid.)

Generally, I am hesitant to depend on 3 things if we think we could ge= t by with only 2.

I understand that, but I'm also hesitant to have one mechanism do two (it s= eems to me) fairly unrelated things, especially where the scenarios in whic= h the problems it's solving are applicable vary fairly widely.

As far as I can tell, the only use case anyone's identified for MSID i= s WebRTC, whereas the disambiguation problem occurs (and thus appid and rec= v-appid are applicable) for anything using Bundle with Unified-like semanti= cs.

--_000_2DF6D66078B34F53AF39B3651E9BBB46vidyocom_-- From jonathan@vidyo.com Tue Feb 4 08:13:49 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 B8CDA1A01D1; Tue, 4 Feb 2014 08:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_SORBS_WEB=0.77, 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 FRJzJCejfRfc; Tue, 4 Feb 2014 08:13:47 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id CE44C1A01C1; Tue, 4 Feb 2014 08:13:46 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/4/2014 11:13:44 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-335/SG:5 2/4/2014 11:13:29 AM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.737767 p=-0.951788 Source White X-Signature-Violations: 0-0-0-25457-c X-Note-419: 15.6005 ms. Fail:1 Chk:1345 of 1345 total X-Note: SCH-CT/SI:1-1345/SG:1 2/4/2014 11:13:34 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 94921056; Tue, 04 Feb 2014 11:13:44 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Tue, 4 Feb 2014 10:13:43 -0600 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP Thread-Index: AQHPIS46pADKsTFIzECMWWmLIWbna5qkgc6AgAAH3gCAAAMqAIAADvKAgADtBYCAACGQAA== Date: Tue, 4 Feb 2014 16:13:42 +0000 Message-ID: References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D15868E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15868E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_B9399713DDEF4680B5E4E9C817372133vidyocom_" MIME-Version: 1.0 Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 04 Feb 2014 16:13:49 -0000 --_000_B9399713DDEF4680B5E4E9C817372133vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MSID doesn't affect the transport level. Appid, however, defines an RTCP S= DES item, and an RTP header extension. On Feb 4, 2014, at 9:13 AM, Christer Holmberg > wrote: Hi, Just for my clarification: none of this would have any impact on transport = level features related to RTCP, STUN, etc? Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On B= ehalf Of Justin Uberti Sent: 4. helmikuuta 2014 2:05 To: Jonathan Lennox Cc: Cullen Jennings; Harald Alvestrand; rtcweb@ietf.org; mmusic Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 6:00 PM, Justin Uberti > wrote: On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox > wrote: On Feb 3, 2014, at 2:27 PM, Justin Uberti > wrote: Also, this essentially makes recv-appId the converse of MSID; for simplicit= y, I think we should consider unifying these concepts into a single documen= t. AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream. For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid. On the receive side, if you wanted to receive both a primary = encoded stream and a redundancy stream, you would have two recv-appid value= s. As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea. Perhaps we need a recv-msid, explicitly? That would be fine by me - it would allow a single invention (msid + recv-m= sid) to focus on solving the three identified problems with MSTs in unified= -plan: - correlation of a MediaStreamTrack to m=3D line in signaling (msid) - correlation of packets from a MST to m=3D line ahead of signaling (recv-m= sid) - rejection of an individual MST (recv-msid) Based on your description, appid seems to go one or two levels down from a = MST to an individual RTP flow, but we can let that develop on its own, sepa= rate from the timetable of webrtc 1.0 and unified plan. Points 1 and 3 make sense to me, and are I think what msid is for; but I do= n't think point 2 will work. I don't think a single, m-line-wide, identifier will work for the correlati= on-ahead-of-signaling problem, once you have multiple RTP flows in the m-li= ne. That's why we've designed appid the way we have. I think appid is the right solution to point 2. More specifically, the pro= blem appid is solving is better expressed as the correlation of packets fro= m an RTP flow to an m-line; the correlation from the m-line to a MST is a s= eparate step, and is msid's job. Agree that msid should map m-line to MST, but it would seem recv-msid could= map RTP flow to m=3Dline as well as indicate whether the receiver is in fa= ct interested in receiving the MST associated with said m=3D line. Note tha= t recv-msid doesn't specify an actual MSID; its purpose is to indicate that= the receiver wants to receive data from the remote side's MST, and provide= a mechanism for the sender to mark the data accordingly. (Which ends up se= eming a lot like appid.) Generally, I am hesitant to depend on 3 things if we think we could get by = with only 2. --_000_B9399713DDEF4680B5E4E9C817372133vidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
MSID doesn't affect the transport level.  Appid, however, defines= an RTCP SDES item, and an RTP header extension.

On Feb 4, 2014, at 9:13 AM, Christer Holmberg <christer.holmberg@ericsson.com>
 wrote:

Hi,
 
Just for my clarification: none of this would have any im= pact on transport level features related to RTCP, STUN, etc?
 
Regards,
 
Christer
 
 
From:=  rtcweb [mailto:rtcweb= -bounces@ietf.org]=  On Behalf Of Justin Ube= rti
Sent: 4. helmikuut= a 2014 2:05
To: Jonathan Lenno= x
Cc: Cullen Jenning= s; Harald Alvestrand; rtcweb@ietf.org; mmusic
Subject: Re: [rtcw= eb] Rejecting MediaStreamTracks in JSEP
 
 

 

On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
 
On Feb 3, 2014, at 6:00 PM, Justin Uberti <juberti@google.com>
 wrote:


On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com> wrote:


Also, thi= s essentially makes recv-appId the converse of MSID; for simplicity, I thin= k we should consider unifying these concepts into a single document.
 
AppID (as I envision it, as the author) and MSID (as I understand it) have = rather different scopes, which are visible once sources are sent using more= than one packet stream.
 
For example, an m-line which has both a primary encoded stream (of media) a= nd a redundancy stream (of rtx packets) would have two appid values, but on= ly one msid.  On the receive side, if you wanted to receive both a pri= mary encoded stream and a redundancy stream, you would have two recv-appid values.
 
As such, appid and msid are solving different (though related) problems, an= d I don't think unifying them is a good idea.
 
Perhaps we need a recv-msid, explicitly?
 
That would be fine by me - it would allow a single invention (msid + re= cv-msid) to focus on solving the three identified problems with MSTs in uni= fied-plan:
- correlation of a MediaStreamTrack to m=3D line in signaling (msid)
- correlation of packets from a MST to m=3D line ahead of signaling (recv-m= sid)
- rejection of an individual MST (recv-msid)
 
Based on your description, appid seems to go one or two levels down from a = MST to an individual RTP flow, but we can let that develop on its own, sepa= rate from the timetable of webrtc 1.0 and unified plan.
 
Points 1 and 3 make sense to me, and are I think what msid is for; but I do= n't think point 2 will work.
 
I don't think a single, m-line-wide, identifier will work for the correlati= on-ahead-of-signaling problem, once you have multiple RTP flows in the= m-line.  That's why we've designed appid the way we have.<= /div>
 
I think appid is the right solution to point 2.  More specifically, th= e problem appid is solving is better expressed as the correlation of packet= s from an RTP flow to an m-line; the correlation from the m-line to a MST i= s a separate step, and is msid's job.
 
Agree that msid should map m-line to MST, but it would seem recv-msid could= map RTP flow to m=3Dline as well as indicate whether the receiver is in fa= ct interested in receiving the MST associated with said m=3D line. Note tha= t recv-msid doesn't specify an actual MSID; its purpose is to indicate that the receiver wants to receive data f= rom the remote side's MST, and provide a mechanism for the sender to mark t= he data accordingly. (Which ends up seeming a lot like appid.)
 
Generally, I am hesitant to depend on 3 things if we think we could get by = with only 2.
 

--_000_B9399713DDEF4680B5E4E9C817372133vidyocom_-- From pkyzivat@alum.mit.edu Tue Feb 4 08:59: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 66AA61A0135 for ; Tue, 4 Feb 2014 08:59:32 -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 jrM6z5sk_n2R for ; Tue, 4 Feb 2014 08:59:30 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 91C5A1A01D2 for ; Tue, 4 Feb 2014 08:59:30 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id NDBh1n0011ZXKqc59GzWVk; Tue, 04 Feb 2014 16:59:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id NGzV1n00o3ZTu2S3hGzWUY; Tue, 04 Feb 2014 16:59:30 +0000 Message-ID: <52F11C71.7020103@alum.mit.edu> Date: Tue, 04 Feb 2014 11:59:29 -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: IETF MMUSIC WG References: <526D51D1.3090106@alum.mit.edu> <03FBA798AC24E3498B74F47FD082A92F3D86D026@US70UWXCHMBA04.zam.alcatel-lucent.com> <526E8BF5.7080206@alum.mit.edu> In-Reply-To: <526E8BF5.7080206@alum.mit.edu> 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=1391533170; bh=sDtjxlbnjAk8zEz372qIMdyjVLhPTefLn0yWEFBQPBw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rlO4wtP6JVRBMkxCjIie778EZk818UGTMcLtEAqT/3W+E6EpqstzDK8pELOXgrtGf kg1wQ7FjYSdTJsF624rGi7JfLWHQY3ullyd8yRTbr7DgMCXUJP+FWpBtF0tsJnCBj7 ztTgzD9l0RvaFC4XPi2S5E98aHSdHEGLUf8RaPKVV2tIZmRnoiW2UHZSQmsJ5HWatk uhm9y5SLJPNgyR0fdxX3tezL33EHVae6izGHo4zxbZDO9IevWp7wsV3J2m+6/8YAer 0DHIyv2Z0fGqE/EirBCvp/fgo7VeFPk3dAlt33/7eZhEIWbYFt4CiaQ1Lxjd422Ivh Svaedf/pHB3sg== Subject: [MMUSIC] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-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: Tue, 04 Feb 2014 16:59:32 -0000 (Trying yet again, this time on the proper list) Richard, What is the status of this work? Are you planning on a new version? (I guess a new one is needed just to bind it to mmusic rather than dispatch.) Also, these naming issues extend to draft-ietf-mmusic-sctp-sdp-05. Can I get your support in lobbying for naming changes there too? Thanks, Paul On 10/28/13 12:08 PM, Paul Kyzivat wrote: > On 10/28/13 11:07 AM, Ejzak, Richard P (Richard) wrote: >> Thanks, Paul. >> >> I agree that the WebRTC specific aspects need to be clearly separated >> from the core protocol aspects. I'll do that in the next version. > > Thanks! > >> I also agree that "WebRTC" is not needed in either name. Are you ok >> with just "DataChannel" and "dcsa" instead of "WebRTC-DataChannel" and >> "wdcsa"? I'm not really picky about the names and am open to any >> reasonable alternative... > > Its just an esthetic issue, so I'm not too picky. > > DataChannel is better than WebRTC-DataChannel. > But IMO CamelCase identifiers aren't in stylistic agreement with SDP. > So perhaps data-channel? > > "dcsa" seems reasonable. > > Thanks, > Paul > >> BR, Richard >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Sunday, October 27, 2013 12:48 PM >>> To: dispatch@ietf.org >>> Subject: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data- >>> channel-sdpneg-00 >>> >>> In general I think this document is looking pretty good. It is going in >>> the right direction from my perspective. And I think its starting to >>> become clear how to have this be an optional mechanism for webrtc. I'm >>> starting to see how it could be used for CLUE, with and without webrtc. >>> >>> One thing bothers me: this is an ietf document, defining signaling. But >>> it talks quite a lot about the webrtc API. It is certainly possible to >>> use this specification in contexts where there are no browsers and no >>> use of webrtc. ISTM it would be better to segregate all the webrtc >>> stuff into an annex. Or maybe two documents are needed: one for SDP >>> negotiation of sctp data channels, and one for webrtc external >>> negotiation of data channels via the SDP mechanism. >>> >>> Esthetically I find the names "webrtc-DataChannel" and "wdcsa" quite >>> unappealing. In particular, these data channels are usable (and will be >>> used) in non-webrtc applications, so why do we need "webrtc" in the >>> name? >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From tireddy@cisco.com Wed Feb 5 06:17: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 881EE1A015B; Wed, 5 Feb 2014 06:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.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 lgyZSYfDFy4S; Wed, 5 Feb 2014 06:17:25 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A386C1A0147; Wed, 5 Feb 2014 06:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1391609845; x=1392819445; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qKvb/D/yZz6WZRt1fkrmfPUq6YS5Ycs6oMr/TW5UQ9s=; b=ilNBFdEDaN6Dl1fUn5Axj5r62LLbZWb3146P8/LyssGQZbkjxK8b4DMw TowkRrNqn6iqaFj4dqClIUo/efjkzep8B3RNqEM6IciJ32PmjolZUN3kF 6sqQzHr5WSlghwf9wg5/Q8gRK/bR/20Hjk0pfgLotgPn1F9KbI/LTpJbK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFACFH8lKtJV2Z/2dsb2JhbABZgww4UQaDAbtCGHYWdIIlAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBAESCAGHfAgFrgqhNBeBKY0bOAaCaTWBFASZXZBvgy2CKg X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="scan'208";a="302106590" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 05 Feb 2014 14:17:24 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s15EHOw4017957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 14:17:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 08:17:24 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" , "tram@ietf.org" Thread-Topic: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt Thread-Index: AQHPInx7P3A1nrdpgEm2Fo8Aj02afpqmtGsQ Date: Wed, 5 Feb 2014 14:17:23 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242A8397@xmb-rcd-x10.cisco.com> References: <20140205141338.9649.12791.idtracker@ietfa.amsl.com> In-Reply-To: <20140205141338.9649.12791.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.61.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.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, 05 Feb 2014 14:17:27 -0000 UmV2aXNlZCBkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDYgaGFzIGJlZW4gcHVibGlz aGVkLiBJdCBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZvciBNb2JpbGl0eSB1c2lu ZyBUVVJOIGFuZCBhIG5ldyBzZWN0aW9uIHdpdGggaW1wbGVtZW50YXRpb24gZGV0YWlscy4gRnVy dGhlciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNClRoYW5rcyBhbmQg UmVnYXJkcywNCi1BdXRob3JzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNzo0NCBQTQ0KVG86IFByYXNo YW50aCBQYXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBQcmFz aGFudGggUGF0aWwgKHByYXNwYXRpKTsgRGFuIFdpbmcgKGR3aW5nKTsgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpOyBEYW4gV2luZyAoZHdpbmcp OyBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5LTA2LnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDYudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC13aW5nLW1tdXNp Yy1pY2UtbW9iaWxpdHkNClJldmlzaW9uOgkwNg0KVGl0bGU6CQlNb2JpbGl0eSB3aXRoIElDRSAo TUlDRSkNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDItMDUNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTIxDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5LTA2LnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdpbmct bW11c2ljLWljZS1tb2JpbGl0eS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDYNCkRpZmY6ICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13aW5nLW1tdXNpYy1pY2Ut bW9iaWxpdHktMDYNCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVz IGhvdyBlbmRwb2ludCBtb2JpbGl0eSBjYW4gYmUgYWNoaWV2ZWQNCiAgIHVzaW5nIElDRS4gIFR3 byBtZWNoYW5pc21zIGFyZSBzaG93biwgb25lIHdoZXJlIGJvdGggZW5kcG9pbnRzDQogICBzdXBw b3J0IE1JQ0UgYW5kIGFub3RoZXIgd2hlcmUgb25seSBvbmUgZW5kcG9pbnQgc3VwcG9ydHMgTUlD RS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From petithug@acm.org Wed Feb 5 09:47:47 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 806D71A01BB for ; Wed, 5 Feb 2014 09:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 FUX9UCF0dZjD for ; Wed, 5 Feb 2014 09:47:46 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 08BA61A0132 for ; Wed, 5 Feb 2014 09:47:46 -0800 (PST) Received: from [IPv6:2001:5c0:1101:2d00:b5f7:e61d:b2ca:fd24] (unknown [IPv6:2001:5c0:1101:2d00:b5f7:e61d:b2ca:fd24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E2B102084B for ; Wed, 5 Feb 2014 18:47:44 +0100 (CET) Message-ID: <52F2793E.30905@acm.org> Date: Wed, 05 Feb 2014 10:47:42 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: "mmusic@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] fmtp specific configuration vs parameters 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, 05 Feb 2014 17:47:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 RFC 3264 section 6.1: "The interpretation of fmtp parameters in an offer depends on the parameters. In many cases, those parameters describe specific configurations of the media format, and should therefore be processed as the media format value itself would be. This means that the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the answer. Other fmtp parameters are more like parameters, for which it is perfectly acceptable for each agent to use different values. In that case, the answer MAY contain fmtp parameters, and those MAY have the same values as those in the offer, or they MAY be different. SDP extensions that define new parameters SHOULD specify the proper interpretation in offer/answer." I am not sure I understand this paragraph. It seems to say that there is fmtp parameters that must be the same in the Offer and in the Answer, and some that can be different. But I went through the definition of 50 or so codecs, and cannot find one fmtp parameter that is be required to be identical on both SDPs. Can someone tell me if my understanding is correct, and if it is the case, give me an example of parameter that must be identical on both sides? Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJS8nk8AAoJECnERZXWan7ECQIP/2eypHdSJSqW+beWM4FTO1wn wIedcL9PRXS5hl7hcnKDO6AwAMV6izg1Q2BuUhPUuinTHgmsvwvFgHgqOhoQ3HuQ 5wjt2tDGf9NfbDqGt74L5mDz55r9qfuFI8ARaRT5teg1HdZq0BHbBC+H3wyTQuRy zGAIrVwikTV1li0+W6EcuUoSQxVsXJqtgv1a6Or348wuFsnksInls+lYGe/9OMKx UA+lnxItBJeJYqcyBDxnvugfOl/Z7gFM+NKSvh/bcew1iTIpO9mLhIConyhyQfFo au+yqMbwg9kLzrood7wm/ewLTcO+3d1vh6eFNVNDHQp4+be4PRCOrCsg8xUFigh7 5JmBDY4+YyYx2+qycMKBQYLd4reinLj/I9DH51jqO+xRiOwWx3mGIu8owmCP5k7j NDjtA8kcxyOtZclwRlT2OGXsr1C3Rm7ciTeLJxewEOQsH1kBQz7z+tcLW1eLoiCT dlpDgZb94pb4XLQuj2cFZnIfxNr+7Ke4DxlH3K23qxC67YdxlEZq8NoPVc91x88W PTBMDigho7g8S6KUxfaS8qguzQ1JOUEUIep5Hs6eiCzxSmqrAUZ45IUrGaOU+CcF tks7EUBottOjGrt+uvpsSo4bqpqOegFGg52XkqSdfIco3ir4WmD9Ud53OTANmVeC IEIgrGJjB7F/klb2XgVI =oTbO -----END PGP SIGNATURE----- From pkyzivat@alum.mit.edu Wed Feb 5 11:11: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 6E23E1A00FA for ; Wed, 5 Feb 2014 11:11:34 -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 4gyPmGEi0XoJ for ; Wed, 5 Feb 2014 11:11:31 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 086021A00EB for ; Wed, 5 Feb 2014 11:11:30 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta07.westchester.pa.mail.comcast.net with comcast id NgFh1n00F0mv7h057jBWJc; Wed, 05 Feb 2014 19:11:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id NjBV1n00c3ZTu2S3XjBVwg; Wed, 05 Feb 2014 19:11:30 +0000 Message-ID: <52F28CE1.2070808@alum.mit.edu> Date: Wed, 05 Feb 2014 14:11:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com, mmusic@ietf.org References: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> <52EBF104.7000303@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=1391627490; bh=XuxbShZ1rkIm+8Q0Iu4ZHKoZIxcw+itNkOoyEMBzbiU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MxZqsPIDJu5j+IyMhs5MvpLaK/YM/K5SqEdhR66GNjW0c/ia5bLWIKRHtA0+XuqLW KwObxf+piDJdw57xRhFVRC0y9WQYGutk+s8XvPdw2TfIczY/hF/j4yriABZvPgWSvJ VMi5MY0NEpt08Rh5xa2dP8hHlDU+voLnCBXhl/VUYvG5pDpBSRMWxOieuWz2Xde/HP AnCTcePKt1hJKOa0vFWGohn040MIqm4qYJS+1Bpe3YwpmQvLORijPIdkpJdFHnjPoy C2ncsFkIabTLDISavDV6uB7J9nc1YMcXCpQFZiBi+tNL1lRN8ARn5FTJPeTnTFX8CI /rxUwIwGGPw/w== 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: Wed, 05 Feb 2014 19:11:34 -0000 On 2/4/14 2:18 AM, Simo.Veikkolainen@nokia.com wrote: > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Paul Kyzivat > Sent: 31 January, 2014 20:53 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > 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? > > [SV] I assume you mean the 200 carries the Answer. Not necessarily. I was just trying to sort out the expectations for the timing of the events. The answer could be *before* the 200, but it must be before the call is established. > It may happen that the CS call arrives before the Answer, but in this case no correlation can be done. See Section 5.6.3. If the invite (I assume you mean O/A) completes first, but no CS call ever arrives, or correlation - including the "external" mechanism fails, the endpoint should treat the CS call as unrelated; this is described in Section 5.3.3. Sure, but my question is whether correlation is expected to occur before or after the INVITE completes. > - 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?) > > [SV] CS media starts to flow after the call has been accepted, as in a normal CS call. Correlation may be possible before accepting the call (for "callerid", "uuie", and "external" mechanisms), and for "dtmf" case only after the call has been accepted. I should have been clearer. For DTMF and external correlation media clearly needs to flow on the CS call. My question pertains to whether this is considered part of the SIP session prior to correlation. > - if media flows to the user before correlation, then what if > correlation fails? Will another call be accepted and correlation > be attempted again? > > [SV] I don' think we have explicitly defined this situation. If a call is accepted and *after* that correlation fails, it means that the DTMF mechanism was used (for other correlation mechanisms, we know before accepting the call whether the correlation was successful). external correlation via also has this problem, and more. > If the DTMF pattern is not received correctly, as we cannot know whether it is related to the session or not. Now, this raises a possible case of including both "dtmf" and "external" mechanisms in the O/A. If DTMF is successfully negotiated but it fails, we can't really use the "external" mechanism since the call is already accepted. Implementations could in this case release the CS call and try a new O/A without the DTMF. I'm finding external correlation to be underspecified. One one I could conceive of it working is that the incoming CS call is treated something like a call waiting situation. The existing (sip) call is "suspended" and the user is connected to the CS call, and asked to confirm if it is the intended one. If the user signals confirmation, then the sip call is resumed, with the CS audio stream in it. If the external correlation fails, then the sip call is resumed without the CS media. A problem with this is that the O/A completes prior to the CS call establishment and correlation. If this happens mid-call (because of a desire to switch from RTP to CS media) then the RTP media will be abandoned once the O/A succeeds, before correlation. So while waiting for a CS call to arrive and be correlated you have no RTP media. :-( > - 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.) > > [SV] This would be an issue for the DTMF case, as there correlation can be only only after accepting the CS call. An unlikely case, but still possible. In this case, one of the CS calls could be related to the session, while other(s) would be normal CS calls. As only one CS call can be handled at a time, others would either wait or be terminated, depending on the callee's supplementary services settings. For DTMF, the correlation could be done *before* relating the CS call to the session. Only bind it to the session after correlation is complete. But that doesn't work as well for external correlation. > - 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? > > [SV] The external correlation mechanism does not assume the media flows before "correlation" is made - if the user decides to accept the incoming call, it is considered as "correlated". The user has to receive (hear) the media (and maybe send some too) before he can decide on correlation. Has the CS call be "related to the session" then, or not? What happens if the user decides the CS call *isn't* correlated? > 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. > > > [SV] For being able to perform correlation, yes, the Answer needs to be received. > > - 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. > > [SV] The O/A needs to be completed before correlation can be done, but CS call may arrive before Answer. In this case the endpoint should wait until the Answer is received. If the CS call does not succeed, or correlation is unsuccessful, then yes there is no media as the RTP stream has been dropped. But, this could also happen when re-negotiating RTP media types (endpoints are not able to load correct codecs, new IP addr/port does not work etc.) so the situation not be specific to the CS media type. Yes, it is not entirely unique, but usually updated O/As are done with an option in common to the prior one so that failure is unlikely. The failure modes are quite different when transitioning from RTP to CS. (And also when transitioning from CS to RTP.) > - all the issues above also apply here. > > ISTM that there is a bunch of missing explanation of how this is expected to work. > > [SV] Could you check the above whether my comments clarify the situation. We can address them in more details in the draft as well once we know where more explanation is needed. Upon rereading section 5.6.2 I realize that it does say that the answer must be received before the CS call is placed and correlated, so it implies a break-before-make approach on reINVITE. What I still think is missing is: * explanation of how things work when changing media mid call - from RTP to CS, CS to RTP, or even CS to different CS. Point out that this is break-before-make, and when the user will again perceive to have media. * much about external correlation. Is this really a mechanism in the sense that the others are, that serves as a screen on CS calls until the one is found that correlates? Or does it really mean that any incoming CS call is taking as the right one, included in the sip session, with the user left to take independent action (such as hanging up) if he decides it isn't the right one? * For DTMF correlation, does the user see media in the call before the correlation is successfully completed. * potentially (but maybe not in this draft) a discussion of how to achieve make-before-break semantics. (E.g., Using multiple m-lines.) Thanks, Paul > 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" > > [SV] Fill fix. > > Thanks, > Simo > > 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 >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From mom040267@gmail.com Thu Feb 6 09:13: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 4BB4E1A01A8; Thu, 6 Feb 2014 09:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 5WSnxOtWrs52; Thu, 6 Feb 2014 09:13:22 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 16B531A01FD; Thu, 6 Feb 2014 09:13:22 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fa1so1949635pad.28 for ; Thu, 06 Feb 2014 09:13:21 -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=e2zBpe2dEaRPGHVYtmqLP67SVo1z7kx51irVUvJXKi4=; b=tkdlnsATRW2J7CZWMMSGlF4JhCqEV9dboE5XjCe1COSQaRUDAKEAGWX9+416sp6in9 pOHgmJwvo1qpFj4uPGW6FVm38mDglE+2ALIv7wQ2Z5qepaeKloCIL937SgOYbj2ADwdn ffTG0ODGVmGzbrMx+KSKDJ1//R5U/cIhY2NGsDx0OpZzY9CBKWyUu82YbnaOLAJCocWe c+ZancRl14aceAw/UmHeoS60Yqzp9fcSTdXgI+Nr/RXDvyHvkZSsC343mqNlNheOarm2 ad1PEIe/NLpulImAgMjQaL4mr7yJtQDUjOmjtHDB+ZRnNkDGHP4SGG3eBrCuXlHUVGbc tE7g== MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr1821095pad.115.1391706800717; Thu, 06 Feb 2014 09:13:20 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 6 Feb 2014 09:13:20 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A242A8397@xmb-rcd-x10.cisco.com> References: <20140205141338.9649.12791.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A242A8397@xmb-rcd-x10.cisco.com> Date: Thu, 6 Feb 2014 09:13:20 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a113453ec7d03ca04f1bffd76 Cc: "mmusic@ietf.org" , "tram@ietf.org" Subject: Re: [MMUSIC] [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.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, 06 Feb 2014 17:13:24 -0000 --001a113453ec7d03ca04f1bffd76 Content-Type: text/plain; charset=ISO-8859-1 I have comments regarding the new Error Code "Mobility Forbidden". 1) Section 5.1.4: Comment: remove two TBDs, if the error code has been already determined. 2) Section 7: and to add a new STUN error code "Mobility Forbidden" with the value 501 to the STUN Error Codes registry [iana-stun]. Comment: I am not sure that 501 is the right code to be used. In SIP and HTTP, 5xx errors are usually about a server code problem of some sort; 501 means "not implemented". That may be not exactly accurate. A mobility-aware TURN server may reject the request simply because the administrator does not allow it., and the server did not encounter an error. The reason why the server reject the request is rather "not allowed" (which is the error code 405). May be be, the right approach would be to introduce two separate error codes here: 405 "not allowed" (the server implements mobility but the administrator forbade it) or 501 "not implemented" (the server knows about mobility but it has no implementation for that). If the server truly is not aware about mobility at all, the server will send no MOBILITY-TICKET in the server response. Those are three distinct use cases: 405, 501 and an "ignorant" server. Thanks Oleg On Wed, Feb 5, 2014 at 6:17 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Revised draft-wing-mmusic-ice-mobility-06 has been published. It addresses > the comments received for Mobility using TURN and a new section with > implementation details. Further comments and suggestions are welcome. > > Thanks and Regards, > -Authors. > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, February 05, 2014 7:44 PM > To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth > Patil (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal > Martinsen (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti) > Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt > > > A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name: draft-wing-mmusic-ice-mobility > Revision: 06 > Title: Mobility with ICE (MICE) > Document date: 2014-02-05 > Group: Individual Submission > Pages: 21 > URL: > http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt > Status: > https://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility/ > Htmlized: > http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-06 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-wing-mmusic-ice-mobility-06 > > Abstract: > This specification describes how endpoint mobility can be achieved > using ICE. Two mechanisms are shown, one where both endpoints > support MICE and another where only one endpoint supports MICE. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113453ec7d03ca04f1bffd76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have comments regarding the new Erro= r Code "Mobility Forbidden".

1) Section 5.1.4:
<= br>Comment: remove two TBDs, if the error code has been already determined.=

2) Section 7:

and to add a new STUN error code "=
Mobility Forbidden" with the value
501 to the STUN Error Codes registry [iana-stun].

Comment: I= am not sure that 501 is the right code to be used. In SIP and HTTP, 5xx er= rors are usually about a server code problem of some sort; 501 means "= not implemented". That may be not exactly accurate. A mobility-aware T= URN server may reject the request simply because the administrator does not= allow it., and the server did not encounter an error. The reason why the s= erver reject the request is rather "not allowed" (which is the er= ror code 405).

May be be, the right approach would be to introduce two separate = error codes here: 405 "not allowed" (the server implements mobili= ty but the administrator forbade it) or 501 "not implemented" (th= e server knows about mobility but it has no implementation for that). If th= e server truly is not aware about mobility at all, the server will send no = MOBILITY-TICKET in the server response. Those are three distinct use cases:= 405, 501 and an "ignorant" server.

Thanks
Oleg



On Wed, Feb 5, 2014 at 6:17 AM, Ti= rumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
Revised draft-wing-mmusic-ice-mobility-06 ha= s been published. It addresses the comments received for Mobility using TUR= N and a new section with implementation details. Further comments and sugge= stions are welcome.

Thanks and Regards,
-Authors.

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Wednesday, February 05, 2014 7:44 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Pat= il (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal Martinse= n (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt=


A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-wing-mmusic-ice-mobility
Revision: =A0 =A0 =A0 06
Title: =A0 =A0 =A0 =A0 =A0Mobility with ICE (MICE)
Document date: =A02014-02-05
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A021
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.or= g/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/do= c/draft-wing-mmusic-ice-mobility/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-wing= -mmusic-ice-mobility-06
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdi= ff?url2=3Ddraft-wing-mmusic-ice-mobility-06

Abstract:
=A0 =A0This specification describes how endpoint mobility can be achieved =A0 =A0using ICE. =A0Two mechanisms are shown, one where both endpoints
=A0 =A0support MICE and another where only one endpoint supports MICE.




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.

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a113453ec7d03ca04f1bffd76-- From mom040267@gmail.com Thu Feb 6 14:05:47 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 773181A03C4; Thu, 6 Feb 2014 14:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 gNG9LrOGWw3h; Thu, 6 Feb 2014 14:05:45 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A266D1A0101; Thu, 6 Feb 2014 14:05:45 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so2269049pde.34 for ; Thu, 06 Feb 2014 14:05:44 -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=ZzO2hJGLfS9xAXl/YczAxVYLpZxy7iTMLvRQ33sq6l8=; b=p0KneycM465hZH1mPrx1WxUxthOjulNIfyWKjLeWx6uwX/0uAiqxkm3Ml0UD69MN31 6gzHLpxNBe8qRkNbYkOJNt6DXqOkrTKzGfc8PogJM0xelztkaH+g/MRY4ZFNG/sCT87N 3J6KsGEgfZ/UQj00QTx3WPfFTbymBmcuSVk5aMb7ZzR3ZSkvFtb2MT00cMwpG2s6yI81 NO9WcOlaA7ZOZB2KA18u74lrQOS5k57d1+nJiTxnf5bS8octNfAwqFjEGh42olCSXd91 c3owJMLe2KJED2dWQP4l8pdoadnI/naKGl4BlZ3Yi03wI99vnZuh6QUjDoeax7cipefp 0EbQ== MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr3241176pad.115.1391724344586; Thu, 06 Feb 2014 14:05:44 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 6 Feb 2014 14:05:44 -0800 (PST) In-Reply-To: References: <20140205141338.9649.12791.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A242A8397@xmb-rcd-x10.cisco.com> Date: Thu, 6 Feb 2014 14:05:44 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a113453ec2f366704f1c413e5 Cc: "mmusic@ietf.org" , "tram@ietf.org" Subject: Re: [MMUSIC] [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.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, 06 Feb 2014 22:05:47 -0000 --001a113453ec2f366704f1c413e5 Content-Type: text/plain; charset=ISO-8859-1 ... and another reason why we may want two different error codes for "not allowed" or "not implemented" use cases is that we now have an "origin" TURN draft, and the TURN server may reject or allow Mobility using the "origin" field (according to a server policy). Then probably "not implemented" error would be an incorrect error code if the "mobile allocate" request was rejected because of the origin attribute. But at the same time I am not sure that the "origin" field was really designed as an input for "hard" security decisions (like allowing or disallowing a piece of functionality). This is a grey area between different drafts, and may be the authors or both "origin" draft and "mobility" draft would like to clarify that, for future implementations. Thanks Oleg On Thu, Feb 6, 2014 at 9:13 AM, Oleg Moskalenko wrote: > I have comments regarding the new Error Code "Mobility Forbidden". > > 1) Section 5.1.4: > > Comment: remove two TBDs, if the error code has been already determined. > > 2) Section 7: > > and to add a new STUN error code "Mobility Forbidden" with the value > 501 to the STUN Error Codes registry [iana-stun]. > > > Comment: I am not sure that 501 is the right code to be used. In SIP and > HTTP, 5xx errors are usually about a server code problem of some sort; 501 > means "not implemented". That may be not exactly accurate. A mobility-aware > TURN server may reject the request simply because the administrator does > not allow it., and the server did not encounter an error. The reason why > the server reject the request is rather "not allowed" (which is the error > code 405). > > May be be, the right approach would be to introduce two separate error > codes here: 405 "not allowed" (the server implements mobility but the > administrator forbade it) or 501 "not implemented" (the server knows about > mobility but it has no implementation for that). If the server truly is not > aware about mobility at all, the server will send no MOBILITY-TICKET in the > server response. Those are three distinct use cases: 405, 501 and an > "ignorant" server. > > Thanks > Oleg > > > > On Wed, Feb 5, 2014 at 6:17 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > >> Revised draft-wing-mmusic-ice-mobility-06 has been published. It >> addresses the comments received for Mobility using TURN and a new section >> with implementation details. Further comments and suggestions are welcome. >> >> Thanks and Regards, >> -Authors. >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, February 05, 2014 7:44 PM >> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth >> Patil (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal >> Martinsen (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti) >> Subject: New Version Notification for >> draft-wing-mmusic-ice-mobility-06.txt >> >> >> A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt >> has been successfully submitted by Tirumaleswar Reddy and posted to the >> IETF repository. >> >> Name: draft-wing-mmusic-ice-mobility >> Revision: 06 >> Title: Mobility with ICE (MICE) >> Document date: 2014-02-05 >> Group: Individual Submission >> Pages: 21 >> URL: >> http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility/ >> Htmlized: >> http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-06 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-wing-mmusic-ice-mobility-06 >> >> Abstract: >> This specification describes how endpoint mobility can be achieved >> using ICE. Two mechanisms are shown, one where both endpoints >> support MICE and another where only one endpoint supports MICE. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > --001a113453ec2f366704f1c413e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
... and another reason why we may want two different = error codes for "not allowed" or "not implemented" use = cases is that we now have an "origin" TURN draft, and the TURN se= rver may reject or allow Mobility using the "origin" field (accor= ding to a server policy). Then probably "not implemented" error w= ould be an incorrect error code if the "mobile allocate" request = was rejected because of the origin attribute.

But at the same time I am not sure that the "origin&quo= t; field was really designed as an input for "hard" security deci= sions (like allowing or disallowing a piece of functionality). This is a gr= ey area between different drafts, and may be the authors or both "orig= in" draft and "mobility" draft would like to clarify that, f= or future implementations.

Thanks
Oleg



On Thu, Feb 6, 20= 14 at 9:13 AM, Oleg Moskalenko <mom040267@gmail.com> wrote= :
I have = comments regarding the new Error Code "Mobility Forbidden".
1) Section 5.1.4:

Comment: remove two TBDs, if the error code= has been already determined.

2) Section 7:

and to add a new STUN error code "=
Mobility Forbidden" with the value
501 to the STUN Error Codes registry [iana-stun].

Comment: I= am not sure that 501 is the right code to be used. In SIP and HTTP, 5xx er= rors are usually about a server code problem of some sort; 501 means "= not implemented". That may be not exactly accurate. A mobility-aware T= URN server may reject the request simply because the administrator does not= allow it., and the server did not encounter an error. The reason why the s= erver reject the request is rather "not allowed" (which is the er= ror code 405).

May be be, the right approach would be to introduce two separate = error codes here: 405 "not allowed" (the server implements mobili= ty but the administrator forbade it) or 501 "not implemented" (th= e server knows about mobility but it has no implementation for that). If th= e server truly is not aware about mobility at all, the server will send no = MOBILITY-TICKET in the server response. Those are three distinct use cases:= 405, 501 and an "ignorant" server.

Thanks
Oleg=



=
On Wed, Feb 5, 2014 at 6:17 AM= , Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
Revised draft-w= ing-mmusic-ice-mobility-06 has been published. It addresses the comments re= ceived for Mobility using TURN and a new section with implementation detail= s. Further comments and suggestions are welcome.

Thanks and Regards,
-Authors.

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, February 05, 2014 7:44 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Pat= il (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal Martinse= n (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt=


A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-wing-mmusic-ice-mobility
Revision: =A0 =A0 =A0 06
Title: =A0 =A0 =A0 =A0 =A0Mobility with ICE (MICE)
Document date: =A02014-02-05
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A021
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.or= g/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/do= c/draft-wing-mmusic-ice-mobility/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-wing= -mmusic-ice-mobility-06
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdi= ff?url2=3Ddraft-wing-mmusic-ice-mobility-06

Abstract:
=A0 =A0This specification describes how endpoint mobility can be achieved =A0 =A0using ICE. =A0Two mechanisms are shown, one where both endpoints
=A0 =A0support MICE and another where only one endpoint supports MICE.




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.

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--001a113453ec2f366704f1c413e5-- From Simo.Veikkolainen@nokia.com Fri Feb 7 00: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 5EEDC1A05E1 for ; Fri, 7 Feb 2014 00:39:40 -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 X0SP6CjeBOpX for ; Fri, 7 Feb 2014 00:39:35 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 00E691A05CF for ; Fri, 7 Feb 2014 00:39:34 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s178bWeN029783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 7 Feb 2014 10:37:34 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.28]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.03.0158.002; Fri, 7 Feb 2014 08:37:32 +0000 From: To: , Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt Thread-Index: AQHPHm620e/80jfD1UW9be2tq4vEmZqeqHFwgACF+wCABX36kIACYuGAgAE485A= Date: Fri, 7 Feb 2014 08:37:32 +0000 Message-ID: References: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> <52EBF104.7000303@alum.mit.edu> <52F28CE1.2070808@alum.mit.edu> In-Reply-To: <52F28CE1.2070808@alum.mit.edu> 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.219] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean 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, 07 Feb 2014 08:39:40 -0000 See below [SV] -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 05 February, 2014 21:11 To: Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt On 2/4/14 2:18 AM, Simo.Veikkolainen@nokia.com wrote: > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Paul=20 > Kyzivat > Sent: 31 January, 2014 20:53 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > I just reviewed the new version. First I looked at just the diffs. But th= ose 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 int= ended to work in practice, especially with extern correlation, but even wit= h the other forms. > > In particular, I am unclear of the sequencing of O/A processing,=20 > correlation processing, and signaling completion. (I realize this is=20 > an mmusic draft and theoretically independent of sip, but forgive me=20 > if I discuss this in the context of sip.) > > Normally, when first establishing a session with sip, the first O/A may o= ccur 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 an= d 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 ne= w O/A replace the old one. If the reinvite fails, then the session is suppo= sed to continue as it was before the reinvite. In the interim, from the sen= ding of the reinvite until its success or failure, things are a little conf= using - presumably both old and new media streams must be maintained, but w= hich are connected to the user is unspecified. > > I see nothing in this draft that explains how the CS media, and correlati= on 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? > > [SV] I assume you mean the 200 carries the Answer. Not necessarily. I was just trying to sort out the expectations for the tim= ing of the events. The answer could be *before* the 200, but it must be bef= ore the call is established. > It may happen that the CS call arrives before the Answer, but in this cas= e no correlation can be done. See Section 5.6.3. If the invite (I assume yo= u mean O/A) completes first, but no CS call ever arrives, or correlation - = including the "external" mechanism fails, the endpoint should treat the CS = call as unrelated; this is described in Section 5.3.3. Sure, but my question is whether correlation is expected to occur before or= after the INVITE completes. [SV] Correlation can only occur after the correlation information has been = exchanged, and the CS call is received. I'm not sure what you mean by INVIT= E being completed, but I would say correlation can be done already before t= he last request (ACK) has been sent, or after the whole INVITE related requ= est-response exchange has been completed (in case the CS call is received l= ate). > - 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?) > > [SV] CS media starts to flow after the call has been accepted, as in a no= rmal CS call. Correlation may be possible before accepting the call (for "c= allerid", "uuie", and "external" mechanisms), and for "dtmf" case only afte= r the call has been accepted. I should have been clearer. For DTMF and external correlation media clearly= needs to flow on the CS call. My question pertains to whether this is cons= idered part of the SIP session prior to correlation. [SV] Again, I'm not sure I'm able to follow your thought but correlation is= needed before the CS media is considered as part of the session. > - if media flows to the user before correlation, then what if > correlation fails? Will another call be accepted and correlation > be attempted again? > > [SV] I don' think we have explicitly defined this situation. If a call is= accepted and *after* that correlation fails, it means that the DTMF mechan= ism was used (for other correlation mechanisms, we know before accepting th= e call whether the correlation was successful). external correlation via also has this problem, and more. > If the DTMF pattern is not received correctly, as we cannot know whether = it is related to the session or not. Now, this raises a possible case of in= cluding both "dtmf" and "external" mechanisms in the O/A. If DTMF is succes= sfully negotiated but it fails, we can't really use the "external" mechanis= m since the call is already accepted. Implementations could in this case re= lease the CS call and try a new O/A without the DTMF. I'm finding external correlation to be underspecified. One one I could conceive of it working is that the incoming CS call is trea= ted something like a call waiting situation. The existing (sip) call is "su= spended" and the user is connected to the CS call, and asked to confirm if = it is the intended one. If the user signals confirmation, then the sip call= is resumed, with the CS audio stream in it. If the external correlation fails, then the sip call is resumed without the= CS media. A problem with this is that the O/A completes prior to the CS call establis= hment and correlation. If this happens mid-call (because of a desire to swi= tch from RTP to CS media) then the RTP media will be abandoned once the O/A= succeeds, before correlation. So while waiting for a CS call to arrive and= be correlated you have no RTP media. :-( [SV] Ok now I think I see your point. The O/A needs to be completed before = correlation can take place. If this happens mid-call, it can indeed happen = that the correlation fails and there is no media. On the other hand, there = are a number of reasons why the same could happen to RTP based media as wel= l. So, it can either be considered as an call failure case, or the other po= ssibility would be to first add the CS media, and if it succeeds, do anothe= r O/A to remove the RTP based media. The drawback in this case is that the = endpoints would receive two media streams for a short while. > - 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.) > > [SV] This would be an issue for the DTMF case, as there correlation can b= e only only after accepting the CS call. An unlikely case, but still possib= le. In this case, one of the CS calls could be related to the session, whil= e other(s) would be normal CS calls. As only one CS call can be handled at = a time, others would either wait or be terminated, depending on the callee'= s supplementary services settings. For DTMF, the correlation could be done *before* relating the CS call to th= e session. Only bind it to the session after correlation is complete. But that doesn't work as well for external correlation. [SV] For both DTMF and external, the CS call needs to be accepted first, bu= t when using DTMF it is possible (and advisable) to not play back the media= to the user until correlation has been done. For external case, the media = would need to be played back . > - 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? > > [SV] The external correlation mechanism does not assume the media flows b= efore "correlation" is made - if the user decides to accept the incoming ca= ll, it is considered as "correlated". The user has to receive (hear) the media (and maybe send some too) before h= e can decide on correlation. Has the CS call be "related to the session" th= en, or not? [SV] From a protocol point of view, I would say the call is considered as r= elated to the session if the user accepts the call. But, you're right that = the user cannot be really sure before some words are exchanged on the CS ca= ll. What happens if the user decides the CS call *isn't* correlated? [SV] The user would likely hang up. > Now consider a call that is initially established with one RTP media stre= am. Later, a reinvite is sent with an offer proposing to to replace that wi= th a CS media stream: > > - again, there must be an answer before the CS call can be attempted. > > > [SV] For being able to perform correlation, yes, the Answer needs to be r= eceived. > > - 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. > > [SV] The O/A needs to be completed before correlation can be done, but CS= call may arrive before Answer. In this case the endpoint should wait until= the Answer is received. If the CS call does not succeed, or correlation is= unsuccessful, then yes there is no media as the RTP stream has been droppe= d. But, this could also happen when re-negotiating RTP media types (endpoin= ts are not able to load correct codecs, new IP addr/port does not work etc.= ) so the situation not be specific to the CS media type. Yes, it is not entirely unique, but usually updated O/As are done with an o= ption in common to the prior one so that failure is unlikely. The failure m= odes are quite different when transitioning from RTP to CS.=20 (And also when transitioning from CS to RTP.) [SV] Agreed, adding a CS call introduces an additional level of uncertainty= . > - all the issues above also apply here. > > ISTM that there is a bunch of missing explanation of how this is expected= to work. > > [SV] Could you check the above whether my comments clarify the situation.= We can address them in more details in the draft as well once we know wher= e more explanation is needed. Upon rereading section 5.6.2 I realize that it does say that the answer mus= t be received before the CS call is placed and correlated, so it implies a = break-before-make approach on reINVITE. What I still think is missing is: * explanation of how things work when changing media mid call - from RTP to= CS, CS to RTP, or even CS to different CS. Point out that this is break-be= fore-make, and when the user will again perceive to have media. * much about external correlation. Is this really a mechanism in the sense = that the others are, that serves as a screen on CS calls until the one is f= ound that correlates? Or does it really mean that any incoming CS call is t= aking as the right one, included in the sip session, with the user left to = take independent action (such as hanging up) if he decides it isn't the rig= ht one? * For DTMF correlation, does the user see media in the call before the corr= elation is successfully completed. * potentially (but maybe not in this draft) a discussion of how to achieve = make-before-break semantics. (E.g., Using multiple m-lines.) [SV] I need to go through these with more thought with my co-author. We'll = get back to this. Thanks Simo Thanks, Paul > 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 th= e > 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" > > [SV] Fill fix. > > Thanks, > Simo > > 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 correlati= on 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 g= ot 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 (bef= ore all three were MTI). >> - we have introduced a fourth correlation type ("external") which indica= tes explicit support for cases where also some external means, typically th= e human user, can do the correlation. This can be as a fallback in cases wh= ere no other common correlation mechanism is found, or the negotiated corre= lation 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 w= here Gonzalo presented the draft. >> >> We would like to hear from the WG whether there are any concerns with th= ese 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=20 >> 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 direc= tories. >> This draft is a work item of the Multiparty Multimedia Session Contro= l 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 extension= s >> for using the Session Description Protocol (SDP) Offer/Answer model >> for establishing audio and video media streams over circuit-switche= d >> bearers in the Public Switched Telephone Network (PSTN). >> >> >> 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 submis= sion 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 >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From ari.keranen@ericsson.com Fri Feb 7 02:43: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 93FFC1A0200 for ; Fri, 7 Feb 2014 02:43:58 -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 4SDcawlgeFWn for ; Fri, 7 Feb 2014 02:43:57 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E13271A0033 for ; Fri, 7 Feb 2014 02:43:56 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-1a-52f4b8e94ea1 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 5C.A1.04853.9E8B4F25; Fri, 7 Feb 2014 11:43:54 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.347.0; Fri, 7 Feb 2014 11:43:53 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8346D110463; Fri, 7 Feb 2014 12:43:53 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3A640568CB; Fri, 7 Feb 2014 12:43:49 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E520D55E34; Fri, 7 Feb 2014 12:43:48 +0200 (EET) Message-ID: <52F4B8E8.6080803@ericsson.com> Date: Fri, 7 Feb 2014 12:43:52 +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.3.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvje6rHV+CDGbsYrV4f0HXYuryxywO TB5Tfm9k9Viy5CdTAFMUl01Kak5mWWqRvl0CV8b+WyeZCw5zVOzYdpetgfEuWxcjJ4eEgInE joPf2SFsMYkL99YDxbk4hAROMEosfHOYCcJZzyix79F8FghnD6PEwd0boDJrGSVud19nh3CW M0osPtnICjKMV0BbomvBfiYQm0VAReLsgc9gS9gE7CVuTrgOZosKJEt8WtTJCFEvKHFy5hMW EFtEQEZi76bNzCA2M9Cc2XdmAc3h4BAGstdNVoMI20pcmHOdBcKWl9j+dg4zxA9qElfPbQKz hQRUJa7+e8U4gVF4FpINs5C0z0LSvoCReRWjZHFqcXFuupGBXm56bolealFmcnFxfp5eceom RmCoH9zy22gH48k99ocYpTlYlMR5r7PWBAkJpCeWpGanphakFsUXleakFh9iZOLglGpgNN2f JtWQWpjdM9vOr/Ki+CSRALk9QbF/XJfcKnCcdcH2lfsLx4y/0nU1wfuSn09Juqj9kvX5l9K7 gdOOGAlM9X/E6y1WrnTq8dTjped4JnHWlx/Ys//V2/z8th/VVzay5z/Vc6vKWPuttizKXLSR dYlE9rWm5S/Lv1znqHz7rW2W/OFZf2tdlViKMxINtZiLihMBg1yr40MCAAA= Cc: Flemming Andreasen Subject: [MMUSIC] MMUSIC Agenda Requests for IETF 89 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, 07 Feb 2014 10:43:58 -0000 Hi all, MMUSIC has two 2,5 hour sessions tentatively scheduled for the IETF 89 meeting at London: http://tools.ietf.org/agenda/89/ If you want to request a time slot to discuss a draft, please send an e-mail to the chairs as soon as possible, but latest by the end of Wednesday 12th. As usual, we want to ensure we take advantage of our meeting time in a productive manner that leads to forward progress. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback already. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following: - name of the draft and the presenter - how much time would you need - outline of major open issues; what needs to be discussed at the meeting - dependencies to your draft (if any) Thanks, Ari & Flemming From internet-drafts@ietf.org Fri Feb 7 13:23: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 D7A6C1AD66B; Fri, 7 Feb 2014 13:23: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 g8dHGAu5L7PL; Fri, 7 Feb 2014 13:23:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 096A41A0459; Fri, 7 Feb 2014 13:23:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207212300.14140.79395.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 13:23:00 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-trickle-ice-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, 07 Feb 2014 21:23:03 -0000 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 : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Authors : Emil Ivov Eric Rescorla Justin Uberti Filename : draft-ietf-mmusic-trickle-ice-01.txt Pages : 25 Date : 2014-02-07 Abstract: This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The above mechanism is also referred to as "trickle ICE". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-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 emcho@sip-communicator.org Fri Feb 7 13:27: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 E7E241A0459 for ; Fri, 7 Feb 2014 13:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 3yK1rfAujxeD for ; Fri, 7 Feb 2014 13:27:54 -0800 (PST) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 82B891A0428 for ; Fri, 7 Feb 2014 13:27:54 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id cz12so3305071veb.29 for ; Fri, 07 Feb 2014 13:27:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=h2cK+PCYtK8wXy/A9xH33YGX8IicRC7TMraY3N+tm/8=; b=NWPMbRu7BRr0hhPArAu1ImUic/wgh1YvU6vTyGpikQ2ToRJFbab+TD2hd045vVsZ5b tiEvv42gu6mAeDyhaVwDHM5SVGvNSPyETpBghpU87V5oGDhoWdDvBLG4Su+L7j+ki6kd aPkjcUG5ZFMoLp8b/Ghs0/tgW0RkXPi8E3EqLQq+/ff7koInNqBpUS0GZ2qccBUaQ5M5 RWWj14wH0TDzH98rm7RZITGbN15EbP1Q6uNgMDBTEPNM0LPTXr8l0GW0KYpbKxBhzaRd flirgRhoCkqvYyDHkHylN1p9tWfNO5HFj4/fBrphimf7t9kAaiJRmXYQYkBKM9CjfDTD RTnw== X-Gm-Message-State: ALoCoQlYH49JXnFuz+IOA7WCDbjoAS1RtMCfBK/hsc701AYjTfx87yrak8KcvS2dRQDQhqacLkcZ X-Received: by 10.52.61.133 with SMTP id p5mr6547139vdr.4.1391808473976; Fri, 07 Feb 2014 13:27:53 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx.google.com with ESMTPSA id kf16sm15425904vdb.5.2014.02.07.13.27.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 13:27:53 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id im17so3109470vcb.33 for ; Fri, 07 Feb 2014 13:27:53 -0800 (PST) X-Received: by 10.58.132.203 with SMTP id ow11mr12346551veb.1.1391808473567; Fri, 07 Feb 2014 13:27:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.191.130 with HTTP; Fri, 7 Feb 2014 13:27:33 -0800 (PST) In-Reply-To: <20140207212301.14140.58730.idtracker@ietfa.amsl.com> References: <20140207212301.14140.58730.idtracker@ietfa.amsl.com> From: Emil Ivov Date: Fri, 7 Feb 2014 22:27:33 +0100 Message-ID: To: mmusic Content-Type: text/plain; charset=ISO-8859-1 Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-trickle-ice-01.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, 07 Feb 2014 21:27:57 -0000 Hey all, This version incorporates most of the comments we have received here and closes the open issues (which are still in the text for completeness). A summary of the changes is available here: http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#appendix-B.1 The authors would hence like to ask the working group for feedback on whether there is anything else left, that is not currently in the draft. Cheers, Emil P.S. An update of the SIP usage should follow in the next days. ---------- Forwarded message ---------- From: Date: Fri, Feb 7, 2014 at 10:23 PM Subject: New Version Notification for draft-ietf-mmusic-trickle-ice-01.txt To: Eric Rescorla , Emil Ivov , Justin Uberti A new version of I-D, draft-ietf-mmusic-trickle-ice-01.txt has been successfully submitted by Emil Ivov and posted to the IETF repository. Name: draft-ietf-mmusic-trickle-ice Revision: 01 Title: Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Document date: 2014-02-07 Group: mmusic Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice/ Htmlized: http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-01 Abstract: This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The above mechanism is also referred to as "trickle ICE". 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. The IETF Secretariat -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 https://jitsi.org FAX: +33.1.77.62.47.31 From Simo.Veikkolainen@nokia.com Mon Feb 10 02:45: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 CFBEC1A06CA for ; Mon, 10 Feb 2014 02:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 avtlCZ35SzSD for ; Mon, 10 Feb 2014 02:45:41 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 743911A06D3 for ; Mon, 10 Feb 2014 02:45:40 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.26]) by mgw-sa01.nokia.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s1AAiM9V005048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 10 Feb 2014 12:44:23 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.28]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.03.0158.002; Mon, 10 Feb 2014 10:44:22 +0000 From: To: , Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt Thread-Index: AQHPHm620e/80jfD1UW9be2tq4vEmZqeqHFwgACF+wCABX36kIACYuGAgAE485CABhMQMA== Date: Mon, 10 Feb 2014 10:44:21 +0000 Message-ID: References: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> <52EBF104.7000303@alum.mit.edu> <52F28CE1.2070808@alum.mit.edu> In-Reply-To: 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: [213.243.168.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean 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: Mon, 10 Feb 2014 10:45:47 -0000 Hello Paul, all, I've copied the bullets from your email below, and propose the following te= xt to address your concerns: * explanation of how things work when changing media mid call - from RTP to= CS, CS to RTP, or even CS to different CS. Point out that this is break-be= fore-make, and when the user will again perceive to have media. -> Add in 5.6.4. Modifying the session If either party would like to remove existing RTP based media from the sess= ion and replace that with a circuit-switched bearer, it would create a new = Offer to add the circuit-switched media as described in Section 5.6.1. abov= e, and remove the RTP based media by setting the port number to zero. Once = the Offer/Answer exchange is done, but the circuit-switched bearer is not y= et established, there may be a period of time when no media is available. A= lso, it may happen that correlating the circuit-switched call fails for rea= sons discussed in Section 5.3.3. In this case, even if the Offer/Answer exc= hange was successful, endpoints are not able to receive or send media. It i= s up to the implementation to decide the behavior in this case; if nothing = else is done, the user most likely hangs up after a while if there was no o= ther media in the session. Note that this may also happen when switching fr= om RTP media to another RTP media (for example when firewall blocks the new= media stream). If either party would like to remove existing circuit-switched media from t= he session and replace that with RTP based media, it would create a new Off= er and set the circuit-switched port number to zero, and add a description = for RTP based media. The endpoint MUST then terminate the circuit-switched = bearer using whatever mechanism is appropriate for the technology in questi= on. * much about external correlation. Is this really a mechanism in the sense = that the others are, that serves as a screen on CS calls until the one is f= ound that correlates? Or does it really mean that any incoming CS call is t= aking as the right one, included in the sip session, with the user left to = take independent action (such as hanging up) if he decides it isn't the rig= ht one? -> add in 5.2.3.5. The External correlation mechanism The external correlation mechanism relies on the human user to do the decis= ion on whether the call is related to the ongoing session or not. After the= user accepts the call, that bearer is considered as related to the session= . There is a small chance that the user receives at the same time another c= ircuit-switched call which is not related to the ongoing session. The user = may reject this call if he is able to determine (e.g. based on the calling = line identification) that the call is not related to the session, and conti= nue waiting for another call attempt. If the user accepts the incoming circ= uit-switched call, but it turns out to be not related to the session, the e= ndpoints need to rely on the human user to take appropriate action (typical= ly, they would hang up). * For DTMF correlation, does the user see media in the call before the corr= elation is successfully completed. I think this is an implementation specific matter. We could add a recommend= ation of some sorts, but really it is up to the implementation to decide. * potentially (but maybe not in this draft) a discussion of how to achieve = make-before-break semantics. (E.g., Using multiple m-lines.) This seems to be a larger issue which is not specific to circuit-switched m= edia alone, to probably it would be best to address it in a standalone docu= ment. Regards, Simo -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Veikkolainen Sim= o (Nokia-CTO/Espoo) Sent: 07 February, 2014 10:38 To: pkyzivat@alum.mit.edu; mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt See below [SV] -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 05 February, 2014 21:11 To: Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt On 2/4/14 2:18 AM, Simo.Veikkolainen@nokia.com wrote: > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Paul=20 > Kyzivat > Sent: 31 January, 2014 20:53 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > I just reviewed the new version. First I looked at just the diffs. But th= ose 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 int= ended to work in practice, especially with extern correlation, but even wit= h the other forms. > > In particular, I am unclear of the sequencing of O/A processing,=20 > correlation processing, and signaling completion. (I realize this is=20 > an mmusic draft and theoretically independent of sip, but forgive me=20 > if I discuss this in the context of sip.) > > Normally, when first establishing a session with sip, the first O/A may o= ccur 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 an= d 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 ne= w O/A replace the old one. If the reinvite fails, then the session is suppo= sed to continue as it was before the reinvite. In the interim, from the sen= ding of the reinvite until its success or failure, things are a little conf= using - presumably both old and new media streams must be maintained, but w= hich are connected to the user is unspecified. > > I see nothing in this draft that explains how the CS media, and correlati= on 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? > > [SV] I assume you mean the 200 carries the Answer. Not necessarily. I was just trying to sort out the expectations for the tim= ing of the events. The answer could be *before* the 200, but it must be bef= ore the call is established. > It may happen that the CS call arrives before the Answer, but in this cas= e no correlation can be done. See Section 5.6.3. If the invite (I assume yo= u mean O/A) completes first, but no CS call ever arrives, or correlation - = including the "external" mechanism fails, the endpoint should treat the CS = call as unrelated; this is described in Section 5.3.3. Sure, but my question is whether correlation is expected to occur before or= after the INVITE completes. [SV] Correlation can only occur after the correlation information has been = exchanged, and the CS call is received. I'm not sure what you mean by INVIT= E being completed, but I would say correlation can be done already before t= he last request (ACK) has been sent, or after the whole INVITE related requ= est-response exchange has been completed (in case the CS call is received l= ate). > - 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?) > > [SV] CS media starts to flow after the call has been accepted, as in a no= rmal CS call. Correlation may be possible before accepting the call (for "c= allerid", "uuie", and "external" mechanisms), and for "dtmf" case only afte= r the call has been accepted. I should have been clearer. For DTMF and external correlation media clearly= needs to flow on the CS call. My question pertains to whether this is cons= idered part of the SIP session prior to correlation. [SV] Again, I'm not sure I'm able to follow your thought but correlation is= needed before the CS media is considered as part of the session. > - if media flows to the user before correlation, then what if > correlation fails? Will another call be accepted and correlation > be attempted again? > > [SV] I don' think we have explicitly defined this situation. If a call is= accepted and *after* that correlation fails, it means that the DTMF mechan= ism was used (for other correlation mechanisms, we know before accepting th= e call whether the correlation was successful). external correlation via also has this problem, and more. > If the DTMF pattern is not received correctly, as we cannot know whether = it is related to the session or not. Now, this raises a possible case of in= cluding both "dtmf" and "external" mechanisms in the O/A. If DTMF is succes= sfully negotiated but it fails, we can't really use the "external" mechanis= m since the call is already accepted. Implementations could in this case re= lease the CS call and try a new O/A without the DTMF. I'm finding external correlation to be underspecified. One one I could conceive of it working is that the incoming CS call is trea= ted something like a call waiting situation. The existing (sip) call is "su= spended" and the user is connected to the CS call, and asked to confirm if = it is the intended one. If the user signals confirmation, then the sip call= is resumed, with the CS audio stream in it. If the external correlation fails, then the sip call is resumed without the= CS media. A problem with this is that the O/A completes prior to the CS call establis= hment and correlation. If this happens mid-call (because of a desire to swi= tch from RTP to CS media) then the RTP media will be abandoned once the O/A= succeeds, before correlation. So while waiting for a CS call to arrive and= be correlated you have no RTP media. :-( [SV] Ok now I think I see your point. The O/A needs to be completed before = correlation can take place. If this happens mid-call, it can indeed happen = that the correlation fails and there is no media. On the other hand, there = are a number of reasons why the same could happen to RTP based media as wel= l. So, it can either be considered as an call failure case, or the other po= ssibility would be to first add the CS media, and if it succeeds, do anothe= r O/A to remove the RTP based media. The drawback in this case is that the = endpoints would receive two media streams for a short while. > - 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.) > > [SV] This would be an issue for the DTMF case, as there correlation can b= e only only after accepting the CS call. An unlikely case, but still possib= le. In this case, one of the CS calls could be related to the session, whil= e other(s) would be normal CS calls. As only one CS call can be handled at = a time, others would either wait or be terminated, depending on the callee'= s supplementary services settings. For DTMF, the correlation could be done *before* relating the CS call to th= e session. Only bind it to the session after correlation is complete. But that doesn't work as well for external correlation. [SV] For both DTMF and external, the CS call needs to be accepted first, bu= t when using DTMF it is possible (and advisable) to not play back the media= to the user until correlation has been done. For external case, the media = would need to be played back . > - 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? > > [SV] The external correlation mechanism does not assume the media flows b= efore "correlation" is made - if the user decides to accept the incoming ca= ll, it is considered as "correlated". The user has to receive (hear) the media (and maybe send some too) before h= e can decide on correlation. Has the CS call be "related to the session" th= en, or not? [SV] From a protocol point of view, I would say the call is considered as r= elated to the session if the user accepts the call. But, you're right that = the user cannot be really sure before some words are exchanged on the CS ca= ll. What happens if the user decides the CS call *isn't* correlated? [SV] The user would likely hang up. > Now consider a call that is initially established with one RTP media stre= am. Later, a reinvite is sent with an offer proposing to to replace that wi= th a CS media stream: > > - again, there must be an answer before the CS call can be attempted. > > > [SV] For being able to perform correlation, yes, the Answer needs to be r= eceived. > > - 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. > > [SV] The O/A needs to be completed before correlation can be done, but CS= call may arrive before Answer. In this case the endpoint should wait until= the Answer is received. If the CS call does not succeed, or correlation is= unsuccessful, then yes there is no media as the RTP stream has been droppe= d. But, this could also happen when re-negotiating RTP media types (endpoin= ts are not able to load correct codecs, new IP addr/port does not work etc.= ) so the situation not be specific to the CS media type. Yes, it is not entirely unique, but usually updated O/As are done with an o= ption in common to the prior one so that failure is unlikely. The failure m= odes are quite different when transitioning from RTP to CS.=20 (And also when transitioning from CS to RTP.) [SV] Agreed, adding a CS call introduces an additional level of uncertainty= . > - all the issues above also apply here. > > ISTM that there is a bunch of missing explanation of how this is expected= to work. > > [SV] Could you check the above whether my comments clarify the situation.= We can address them in more details in the draft as well once we know wher= e more explanation is needed. Upon rereading section 5.6.2 I realize that it does say that the answer mus= t be received before the CS call is placed and correlated, so it implies a = break-before-make approach on reINVITE. What I still think is missing is: * explanation of how things work when changing media mid call - from RTP to= CS, CS to RTP, or even CS to different CS. Point out that this is break-be= fore-make, and when the user will again perceive to have media. * much about external correlation. Is this really a mechanism in the sense = that the others are, that serves as a screen on CS calls until the one is f= ound that correlates? Or does it really mean that any incoming CS call is t= aking as the right one, included in the sip session, with the user left to = take independent action (such as hanging up) if he decides it isn't the rig= ht one? * For DTMF correlation, does the user see media in the call before the corr= elation is successfully completed. * potentially (but maybe not in this draft) a discussion of how to achieve = make-before-break semantics. (E.g., Using multiple m-lines.) [SV] I need to go through these with more thought with my co-author. We'll = get back to this. Thanks Simo Thanks, Paul > 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 th= e > 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" > > [SV] Fill fix. > > Thanks, > Simo > > 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 correlati= on 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 g= ot 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 (bef= ore all three were MTI). >> - we have introduced a fourth correlation type ("external") which indica= tes explicit support for cases where also some external means, typically th= e human user, can do the correlation. This can be as a fallback in cases wh= ere no other common correlation mechanism is found, or the negotiated corre= lation 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 w= here Gonzalo presented the draft. >> >> We would like to hear from the WG whether there are any concerns with th= ese 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=20 >> 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 direc= tories. >> This draft is a work item of the Multiparty Multimedia Session Contro= l 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 extension= s >> for using the Session Description Protocol (SDP) Offer/Answer model >> for establishing audio and video media streams over circuit-switche= d >> bearers in the Public Switched Telephone Network (PSTN). >> >> >> 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 submis= sion 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 >> > > _______________________________________________ > 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 tireddy@cisco.com Mon Feb 10 04:09: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 5F07B1A05EC; Mon, 10 Feb 2014 04:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 jQoJ3cdb6tpK; Mon, 10 Feb 2014 04:09:40 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8531A1A05E0; Mon, 10 Feb 2014 04:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15848; q=dns/txt; s=iport; t=1392034181; x=1393243781; h=from:to:cc:subject:date:message-id:mime-version; bh=3lBB0HPG+uBx7YJqACUmbZ3vZ170xRjB+EsUktuZ+pg=; b=nIwinLBNIYMBX/CICnbhcwOPAgKAnhkzUECwGR3qJBBxRXuQD4WXdh7j GwnXx9K+FdKnlmLLbZexL9NqlDj3BRI83E8xG11LO3fsYzPO/kkAfD0l2 NCUGzA5Gsxyz3z8oLjK0Mz0hDXwtwYYTlukvpf/4WCKCnN3vBW921m1zu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwGAN7A+FKtJXG9/2dsb2JhbABZgkhEOFEGtmmIVIEQFnSCJQEBAQQBAQEqQQkCDAYBCA4DBAEBCx0oBgsUCAEJAQQOBQgBh2gDEQgFwDsNiEYXjGaBUhQtBAYHA4MbgRQElj+DHosshUOBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,817,1384300800"; d="scan'208,217";a="302998123" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 10 Feb 2014 12:09:37 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1AC9bk9028535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 12:09:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 06:09:37 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt Thread-Index: Ac8mWNViMg/7N+Z1Q/WK9XyLWsNjfA== Date: Mon, 10 Feb 2014 12:09:36 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AB165@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.13] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242AB165xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" , "tram@ietf.org" Subject: Re: [MMUSIC] [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.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, 10 Feb 2014 12:09:44 -0000 --_000_913383AAA69FF945B8F946018B75898A242AB165xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oleg, Inline [TR] From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Thursday, February 06, 2014 10:43 PM To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org; tram@ietf.org Subject: Re: [tram] FW: New Version Notification for draft-wing-mmusic-ice-= mobility-06.txt I have comments regarding the new Error Code "Mobility Forbidden". 1) Section 5.1.4: Comment: remove two TBDs, if the error code has been already determined. [TR] Removed 2) Section 7: and to add a new STUN error code "Mobility Forbidden" with the value 501 to the STUN Error Codes registry [iana-stun]. Comment: I am not sure that 501 is the right code to be used. In SIP and HT= TP, 5xx errors are usually about a server code problem of some sort; 501 me= ans "not implemented". That may be not exactly accurate. A mobility-aware T= URN server may reject the request simply because the administrator does not= allow it., and the server did not encounter an error. The reason why the s= erver reject the request is rather "not allowed" (which is the error code 4= 05). [TR] we can replace 501 error code with 403 May be be, the right approach would be to introduce two separate error code= s here: 405 "not allowed" (the server implements mobility but the administr= ator forbade it) or 501 "not implemented" (the server knows about mobility = but it has no implementation for that). [TR] Not sure if "not implemented" error will be of any help. TURN server i= f it knows about mobility but has not implemented the functionality then it= can continue to ignore MOBILITY-TICKET in the request and not send MOBILIT= Y-TICKET in the response. -Tiru. If the server truly is not aware about mobility at all, the server will sen= d no MOBILITY-TICKET in the server response. Those are three distinct use c= ases: 405, 501 and an "ignorant" server. Thanks Oleg On Wed, Feb 5, 2014 at 6:17 AM, Tirumaleswar Reddy (tireddy) > wrote: Revised draft-wing-mmusic-ice-mobility-06 has been published. It addresses = the comments received for Mobility using TURN and a new section with implem= entation details. Further comments and suggestions are welcome. Thanks and Regards, -Authors. -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Wednesday, February 05, 2014 7:44 PM To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Pat= il (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal Martinse= n (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti) Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository. Name: draft-wing-mmusic-ice-mobility Revision: 06 Title: Mobility with ICE (MICE) Document date: 2014-02-05 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-m= obility-06.txt Status: https://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobi= lity/ Htmlized: http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-0= 6 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic-ice-mo= bility-06 Abstract: This specification describes how endpoint mobility can be achieved using ICE. Two mechanisms are shown, one where both endpoints support MICE and another where only one endpoint supports MICE. 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. The IETF Secretariat _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_913383AAA69FF945B8F946018B75898A242AB165xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Oleg,

 <= /p>

Inline [TR]

 <= /p>

From: Oleg Mos= kalenko [mailto:m= om040267@gmail.com]
Sent: Thursday, February 06, 2014 10:43 PM
To: Tirumaleswar Reddy (tireddy)
Cc: mmusic@iet= f.org; tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-wing-mmus= ic-ice-mobility-06.txt

 

I have comments regar= ding the new Error Code "Mobility Forbidden".

1) Section 5.1.4:
Comment: remove two TBDs, if the error code has been already determined.

[TR] Removed

2) Section 7:

and to add a new STUN error code "Mobility Forbidden" with t=
he value
501 to the STUN Error Codes registry [iana-stun].

 

Comment: I am not sur= e that 501 is the right code to be used. In SIP and HTTP, 5xx errors are us= ually about a server code problem of some sort; 501 means "not impleme= nted". That may be not exactly accurate. A mobility-aware TURN server may reject the request simply because the adm= inistrator does not allow it., and the server did not encounter an error. T= he reason why the server reject the request is rather "not allowed&quo= t; (which is the error code 405).

[TR] we can replace 501 error code with 403

May be be, the right = approach would be to introduce two separate error codes here: 405 "not= allowed" (the server implements mobility but the administrator forbad= e it) or 501 "not implemented" (the server knows about mobility but it has no implementation for that).

[TR] Not sure if “not implemented” error will be of any h= elp. TURN server if it knows about mobility but has not implemented the functionality then it can continue to ignore MOBILITY-TICKET in the reques= t and not send MOBILITY-TICKET in the response.

-Tiru.

If the server truly i= s not aware about mobility at all, the server will send no MOBILITY-TICKET = in the server response. Those are three distinct use cases: 405, 501 and an= "ignorant" server.

Thanks
Oleg

 

On Wed, Feb 5, 2014 at 6:17 AM, Tirumaleswar Reddy (= tireddy) <tireddy= @cisco.com> wrote:

Revised draft-wing-mmusic-ice-mobility-06 has been p= ublished. It addresses the comments received for Mobility using TURN and a = new section with implementation details. Further comments and suggestions a= re welcome.

Thanks and Regards,
-Authors.

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Wednesday, February 05, 2014 7:44 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Pat= il (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal Martinse= n (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt=


A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name:           draft-wing-mmusic-ice-mobility
Revision:       06
Title:          Mobility with ICE (MICE)
Document date:  2014-02-05
Group:          Individual Submission
Pages:          21
URL:            = http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt
Status:         https://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility/
Htmlized:       http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-06
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic-ice-mobility-06
Abstract:
   This specification describes how endpoint mobility can be achi= eved
   using ICE.  Two mechanisms are shown, one where both endp= oints
   support MICE and another where only one endpoint supports MICE= .




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.

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

 

--_000_913383AAA69FF945B8F946018B75898A242AB165xmbrcdx10ciscoc_-- From internet-drafts@ietf.org Mon Feb 10 05:52: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 792551A0841; Mon, 10 Feb 2014 05:52:26 -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 BLrRCttdG7T9; Mon, 10 Feb 2014 05:52:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A881A02A9; Mon, 10 Feb 2014 05:52:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210135223.1132.59820.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 05:52:23 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-20.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, 10 Feb 2014 13:52:26 -0000 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-20.txt Pages : 32 Date : 2014-02-10 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-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-20 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 Mon Feb 10 05:53: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 04D3C1A0843; Mon, 10 Feb 2014 05:53:06 -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 90Ul1ZBROB-C; Mon, 10 Feb 2014 05:53:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BFA1A0835; Mon, 10 Feb 2014 05:53:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210135303.1871.14655.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 05:53:03 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-13.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, 10 Feb 2014 13:53:06 -0000 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-13.txt Pages : 40 Date : 2014-02-10 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-13 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 Mon Feb 10 05:57: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 824411A02C9 for ; Mon, 10 Feb 2014 05:57:21 -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 NHG2CsfDNCLp for ; Mon, 10 Feb 2014 05:57:20 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id C9D121A02C3 for ; Mon, 10 Feb 2014 05:57:19 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-90-52f8dabe8dd7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id C1.2F.04853.EBAD8F25; Mon, 10 Feb 2014 14:57:19 +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; Mon, 10 Feb 2014 14:57:18 +0100 Message-ID: <52F8DABE.2090108@ericsson.com> Date: Mon, 10 Feb 2014 14:57:18 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20140210135223.1132.59820.idtracker@ietfa.amsl.com> In-Reply-To: <20140210135223.1132.59820.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+NgFupiluLIzCtJLcpLzFFi42KZGfG3Rnf/rR9BBsen8lpMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGdPenGYveC9S8aRrN3sD4z6BLkZODgkBE4ltEzrZIWwxiQv3 1rN1MXJxCAmcYJRYfXoxK4SznFHiz40/LCBVvALaEud3nGIGsVkEVCXO/m1nBLHZBCwkbv5o ZAOxRQWCJXYe+M0IUS8ocXLmE7BeEQF1idbNfUBDOTiEBawkHk51BgkLCThIrJz8iB0kzCng KHFxmziIKSEgLtHTGARSwSygJzHlagsjhC0v0bx1NjNEp7ZEQ1MH6wRGwVlIds1C0jILScsC RuZVjJLFqcXFuelGBnq56bkleqlFmcnFxfl5esWpmxiB4Xlwy2+jHYwn99gfYpTmYFES573O WhMkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTFv29VpXa2uJpcWJZ48NsvUuWzrHKtbSQ9u 1KqUpV67zJB3Un7LBRYR26cbTlqWqOj0ciq/X5TSLCzFv+IbU5mdw1qThv+NX7Z3tDT+ifGc YvFbPciWd2tH4qnECf9DHCrXnjLs6u+pDT24LebljvN3bV4kfTzxJzjs3b5knkYup/k7w96E NymxFGckGmoxFxUnAgA2qnI1HQIAAA== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-20.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, 10 Feb 2014 13:57:21 -0000 WG, I received some additional editorial feedback from Flemming. These have now been addressed. I expect the publication request on this and the draft-ietf-mmusic-rtsp-nat-evaluation-13 to be submitted shortly. Cheers Magnus On 2014-02-10 14:52, 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-20.txt > Pages : 32 > Date : 2014-02-10 > > 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-20 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-20 > > > 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 Mon Feb 10 07:25: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 D938E1A086D; Mon, 10 Feb 2014 07:25:09 -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 M-ZHvDo24UuY; Mon, 10 Feb 2014 07:25:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA0E1A032C; Mon, 10 Feb 2014 07:25:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210152506.17258.70147.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 07:25:06 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-40.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, 10 Feb 2014 15:25:10 -0000 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-40.txt Pages : 309 Date : 2014-02-10 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-40 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc2326bis-40 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 Feb 10 07:49: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 BC9001A0846 for ; Mon, 10 Feb 2014 07:49:17 -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 R1bQm_iq-dcb for ; Mon, 10 Feb 2014 07:49:13 -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 71A091A0874 for ; Mon, 10 Feb 2014 07:49:13 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta02.westchester.pa.mail.comcast.net with comcast id Qcoe1n00227AodY51fpD4s; Mon, 10 Feb 2014 15:49:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id QfpC1n01N3ZTu2S3ffpDpq; Mon, 10 Feb 2014 15:49:13 +0000 Message-ID: <52F8F4F8.90002@alum.mit.edu> Date: Mon, 10 Feb 2014 10:49:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com, mmusic@ietf.org References: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> <52EBF104.7000303@alum.mit.edu> <52F28CE1.2070808@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=1392047353; bh=eQamu5wIL++OKL4Mf2F436UdAnAOhNAatC91QLWT2iU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Arb7OczMKXRp0ag/pdTSczzYliYGB7w2/pVThhA6X8kjdwM/BsPyHsx72fWKMWfY/ +jm8UKPOpQ9j5z/jE9t5vg/b9XPYRsmqiq8TcVgTscpIBbbVEdSK4si81atJKXbwKh FuVZsgR+IRJfVM9BCqdjX+fX2nVJfWAXuHRjKxLoqd6PuMoYeogmnftZgplNtn+yj3 ht6K2TG3pjTyLoDnS2SEgl9dd085lZscM+8vD7yVrWYgagGfOBUMMAql25sdtiPu11 9FnmaXMuzGpbWfLMimdZ8r06zkl8Gv8RyZTendQ+TRPAL9OH2iSzQtYHVb/429vDpS 9rGfRe3D9XoVw== 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: Mon, 10 Feb 2014 15:49:17 -0000 Simo, What you describe below is enough to get me to shut up. :-) On 2/10/14 5:44 AM, Simo.Veikkolainen@nokia.com wrote: > Hello Paul, all, > > I've copied the bullets from your email below, and propose the following text to address your concerns: > > * explanation of how things work when changing media mid call - from RTP to CS, CS to RTP, or even CS to different CS. Point out that this is break-before-make, and when the user will again perceive to have media. > > -> Add in 5.6.4. Modifying the session > > If either party would like to remove existing RTP based media from the session and replace that with a circuit-switched bearer, it would create a new Offer to add the circuit-switched media as described in Section 5.6.1. above, and remove the RTP based media by setting the port number to zero. Once the Offer/Answer exchange is done, but the circuit-switched bearer is not yet established, there may be a period of time when no media is available. Also, it may happen that correlating the circuit-switched call fails for reasons discussed in Section 5.3.3. In this case, even if the Offer/Answer exchange was successful, endpoints are not able to receive or send media. It is up to the implementation to decide the behavior in this case; if nothing else is done, the user most likely hangs up after a while if there was no other media in the session. Note that this may also happen when switching from RTP media to another RTP media (for example when firewall blocks the new media stream). I find it interesting that you describe adding a new m-line for the cs session and rejecting the old one. It should also be valid to simply replace the old (rtp) m-line with the new (cs) m-line. If you are thinking of using two m-lines, then make-before-break is just a matter of keeping them both active for awhile. Thanks, Paul > If either party would like to remove existing circuit-switched media from the session and replace that with RTP based media, it would create a new Offer and set the circuit-switched port number to zero, and add a description for RTP based media. The endpoint MUST then terminate the circuit-switched bearer using whatever mechanism is appropriate for the technology in question. > > * much about external correlation. Is this really a mechanism in the sense that the others are, that serves as a screen on CS calls until the one is found that correlates? Or does it really mean that any incoming CS call is taking as the right one, included in the sip session, with the user left to take independent action (such as hanging up) if he decides it isn't the right one? > > -> add in 5.2.3.5. The External correlation mechanism > > The external correlation mechanism relies on the human user to do the decision on whether the call is related to the ongoing session or not. After the user accepts the call, that bearer is considered as related to the session. There is a small chance that the user receives at the same time another circuit-switched call which is not related to the ongoing session. The user may reject this call if he is able to determine (e.g. based on the calling line identification) that the call is not related to the session, and continue waiting for another call attempt. If the user accepts the incoming circuit-switched call, but it turns out to be not related to the session, the endpoints need to rely on the human user to take appropriate action (typically, they would hang up). > > * For DTMF correlation, does the user see media in the call before the correlation is successfully completed. > > I think this is an implementation specific matter. We could add a recommendation of some sorts, but really it is up to the implementation to decide. > > * potentially (but maybe not in this draft) a discussion of how to achieve make-before-break semantics. (E.g., Using multiple m-lines.) > > This seems to be a larger issue which is not specific to circuit-switched media alone, to probably it would be best to address it in a standalone document. > > Regards, > Simo > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Veikkolainen Simo (Nokia-CTO/Espoo) > Sent: 07 February, 2014 10:38 > To: pkyzivat@alum.mit.edu; mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > See below [SV] > > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 05 February, 2014 21:11 > To: Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > On 2/4/14 2:18 AM, Simo.Veikkolainen@nokia.com wrote: >> >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Paul >> Kyzivat >> Sent: 31 January, 2014 20:53 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt >> >> 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? >> >> [SV] I assume you mean the 200 carries the Answer. > > Not necessarily. I was just trying to sort out the expectations for the timing of the events. The answer could be *before* the 200, but it must be before the call is established. > >> It may happen that the CS call arrives before the Answer, but in this case no correlation can be done. See Section 5.6.3. If the invite (I assume you mean O/A) completes first, but no CS call ever arrives, or correlation - including the "external" mechanism fails, the endpoint should treat the CS call as unrelated; this is described in Section 5.3.3. > > Sure, but my question is whether correlation is expected to occur before or after the INVITE completes. > > [SV] Correlation can only occur after the correlation information has been exchanged, and the CS call is received. I'm not sure what you mean by INVITE being completed, but I would say correlation can be done already before the last request (ACK) has been sent, or after the whole INVITE related request-response exchange has been completed (in case the CS call is received late). > >> - 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?) >> >> [SV] CS media starts to flow after the call has been accepted, as in a normal CS call. Correlation may be possible before accepting the call (for "callerid", "uuie", and "external" mechanisms), and for "dtmf" case only after the call has been accepted. > > I should have been clearer. For DTMF and external correlation media clearly needs to flow on the CS call. My question pertains to whether this is considered part of the SIP session prior to correlation. > > [SV] Again, I'm not sure I'm able to follow your thought but correlation is needed before the CS media is considered as part of the session. > >> - if media flows to the user before correlation, then what if >> correlation fails? Will another call be accepted and correlation >> be attempted again? >> >> [SV] I don' think we have explicitly defined this situation. If a call is accepted and *after* that correlation fails, it means that the DTMF mechanism was used (for other correlation mechanisms, we know before accepting the call whether the correlation was successful). > > external correlation via also has this problem, and more. > >> If the DTMF pattern is not received correctly, as we cannot know whether it is related to the session or not. Now, this raises a possible case of including both "dtmf" and "external" mechanisms in the O/A. If DTMF is successfully negotiated but it fails, we can't really use the "external" mechanism since the call is already accepted. Implementations could in this case release the CS call and try a new O/A without the DTMF. > > I'm finding external correlation to be underspecified. > > One one I could conceive of it working is that the incoming CS call is treated something like a call waiting situation. The existing (sip) call is "suspended" and the user is connected to the CS call, and asked to confirm if it is the intended one. If the user signals confirmation, then the sip call is resumed, with the CS audio stream in it. > > If the external correlation fails, then the sip call is resumed without the CS media. > > A problem with this is that the O/A completes prior to the CS call establishment and correlation. If this happens mid-call (because of a desire to switch from RTP to CS media) then the RTP media will be abandoned once the O/A succeeds, before correlation. So while waiting for a CS call to arrive and be correlated you have no RTP media. :-( > > [SV] Ok now I think I see your point. The O/A needs to be completed before correlation can take place. If this happens mid-call, it can indeed happen that the correlation fails and there is no media. On the other hand, there are a number of reasons why the same could happen to RTP based media as well. So, it can either be considered as an call failure case, or the other possibility would be to first add the CS media, and if it succeeds, do another O/A to remove the RTP based media. The drawback in this case is that the endpoints would receive two media streams for a short while. > >> - 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.) >> >> [SV] This would be an issue for the DTMF case, as there correlation can be only only after accepting the CS call. An unlikely case, but still possible. In this case, one of the CS calls could be related to the session, while other(s) would be normal CS calls. As only one CS call can be handled at a time, others would either wait or be terminated, depending on the callee's supplementary services settings. > > For DTMF, the correlation could be done *before* relating the CS call to the session. Only bind it to the session after correlation is complete. > > But that doesn't work as well for external correlation. > > [SV] For both DTMF and external, the CS call needs to be accepted first, but when using DTMF it is possible (and advisable) to not play back the media to the user until correlation has been done. For external case, the media would need to be played back . > >> - 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? >> >> [SV] The external correlation mechanism does not assume the media flows before "correlation" is made - if the user decides to accept the incoming call, it is considered as "correlated". > > The user has to receive (hear) the media (and maybe send some too) before he can decide on correlation. Has the CS call be "related to the session" then, or not? > > [SV] From a protocol point of view, I would say the call is considered as related to the session if the user accepts the call. But, you're right that the user cannot be really sure before some words are exchanged on the CS call. > > What happens if the user decides the CS call *isn't* correlated? > > [SV] The user would likely hang up. > >> 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. >> >> >> [SV] For being able to perform correlation, yes, the Answer needs to be received. >> >> - 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. >> >> [SV] The O/A needs to be completed before correlation can be done, but CS call may arrive before Answer. In this case the endpoint should wait until the Answer is received. If the CS call does not succeed, or correlation is unsuccessful, then yes there is no media as the RTP stream has been dropped. But, this could also happen when re-negotiating RTP media types (endpoints are not able to load correct codecs, new IP addr/port does not work etc.) so the situation not be specific to the CS media type. > > Yes, it is not entirely unique, but usually updated O/As are done with an option in common to the prior one so that failure is unlikely. The failure modes are quite different when transitioning from RTP to CS. > (And also when transitioning from CS to RTP.) > > [SV] Agreed, adding a CS call introduces an additional level of uncertainty. > >> - all the issues above also apply here. >> >> ISTM that there is a bunch of missing explanation of how this is expected to work. >> >> [SV] Could you check the above whether my comments clarify the situation. We can address them in more details in the draft as well once we know where more explanation is needed. > > Upon rereading section 5.6.2 I realize that it does say that the answer must be received before the CS call is placed and correlated, so it implies a break-before-make approach on reINVITE. > > What I still think is missing is: > > * explanation of how things work when changing media mid call - from RTP to CS, CS to RTP, or even CS to different CS. Point out that this is break-before-make, and when the user will again perceive to have media. > > * much about external correlation. Is this really a mechanism in the sense that the others are, that serves as a screen on CS calls until the one is found that correlates? Or does it really mean that any incoming CS call is taking as the right one, included in the sip session, with the user left to take independent action (such as hanging up) if he decides it isn't the right one? > > * For DTMF correlation, does the user see media in the call before the correlation is successfully completed. > > * potentially (but maybe not in this draft) a discussion of how to achieve make-before-break semantics. (E.g., Using multiple m-lines.) > > [SV] I need to go through these with more thought with my co-author. We'll get back to this. > > Thanks > Simo > > Thanks, > Paul > >> 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" >> >> [SV] Fill fix. >> >> Thanks, >> Simo >> >> 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 >>> >> >> _______________________________________________ >> 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 mom040267@gmail.com Mon Feb 10 09:57: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 1DDB81A0402; Mon, 10 Feb 2014 09:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 tPHi2fmkJEKH; Mon, 10 Feb 2014 09:57:19 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEE11A0326; Mon, 10 Feb 2014 09:57:19 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so5983231pdb.24 for ; Mon, 10 Feb 2014 09:57:19 -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=OGJYLjCJJ/5iTPNmAQBVdX7Dub/K/s8FqrKXMPX9v5I=; b=fPAo8h2+JTxDEKlNKdIHREyezdxD+bB7gqjNz2V3cmmrNO0HvvWpnGtY8+cxoHW5ij wcxyee1UpeUvrtLPtWqf5YQxBkp/RSOtDSqu4EAmgDAMyZ5oNcxzP2Z06wr9IDtLXOB1 9+cG4nN7f6rLLqcFY5LPcfQdG8RTMwYbOY4R1+gZX2C4j1HNA4soJnwd7PM8oOfJ4R0J 1N+R8vewOW1DrMJTXgB+yhVGXF8DlyaS96FgvapTv9mCAaNtD301nDFDcF83dF63QKA5 zj3WfFjTNSEieTjvq10+WevoGbts4Cp/UGn1QkC8gBIXPjcbvyA8ART8fylbXjDwoRMf ogRg== MIME-Version: 1.0 X-Received: by 10.68.139.100 with SMTP id qx4mr10528421pbb.144.1392055039260; Mon, 10 Feb 2014 09:57:19 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 10 Feb 2014 09:57:19 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A242AB165@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242AB165@xmb-rcd-x10.cisco.com> Date: Mon, 10 Feb 2014 09:57:19 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11c361d21f7f0a04f21112d9 Cc: "mmusic@ietf.org" , "tram@ietf.org" Subject: Re: [MMUSIC] [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.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, 10 Feb 2014 17:57:21 -0000 --001a11c361d21f7f0a04f21112d9 Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru I agree. Thanks Oleg On Mon, Feb 10, 2014 at 4:09 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Comment: I am not sure that 501 is the right code to be used. In SIP > and HTTP, 5xx errors are usually about a server code problem of some sort; > 501 means "not implemented". That may be not exactly accurate. A > mobility-aware TURN server may reject the request simply because the > administrator does not allow it., and the server did not encounter an > error. The reason why the server reject the request is rather "not allowed" > (which is the error code 405). > > [TR] we can replace 501 error code with 403 > > May be be, the right approach would be to introduce two separate error > codes here: 405 "not allowed" (the server implements mobility but the > administrator forbade it) or 501 "not implemented" (the server knows about > mobility but it has no implementation for that). > > [TR] Not sure if "not implemented" error will be of any help. TURN server > if it knows about mobility but has not implemented the functionality then > it can continue to ignore MOBILITY-TICKET in the request and not send > MOBILITY-TICKET in the response. > > --001a11c361d21f7f0a04f21112d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Tiru

I agree.

Thank= s
Oleg

On Mon, Feb 10, 2014 at 4:09 AM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:

Comment: I am not sur= e that 501 is the right code to be used. In SIP and HTTP, 5xx errors are us= ually about a server code problem of some sort; 501 means "not impleme= nted". That may be not exactly accurate. A mobility-aware TURN server may reject the request simply because the adm= inistrator does not allow it., and the server did not encounter an error. T= he reason why the server reject the request is rather "not allowed&quo= t; (which is the error code 405).

[TR] we can replace 501 error code with 403

May be be, the right = approach would be to introduce two separate error codes here: 405 "not= allowed" (the server implements mobility but the administrator forbad= e it) or 501 "not implemented" (the server knows about mobility but it has no implementation for that).

[TR] Not sure if “not implemented” error will be of= any help. TURN server if it knows about mobility but has not implemented t= he functionality then it can continue to ignore MOBILITY-TICKET in the reques= t and not send MOBILITY-TICKET in the response.



--001a11c361d21f7f0a04f21112d9-- From Simo.Veikkolainen@nokia.com Tue Feb 11 02:03:41 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 C855D1A0921 for ; Tue, 11 Feb 2014 02:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 3tmQbYxNOQVi for ; Tue, 11 Feb 2014 02:03:37 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id A331B1A092B for ; Tue, 11 Feb 2014 02:03:36 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.47]) by mgw-sa02.nokia.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s1BA3BZ3019847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 11 Feb 2014 12:03:13 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.28]) by 008-AM1MMR1-013.mgdnok.nokia.com ([::1]) with mapi id 14.03.0158.002; Tue, 11 Feb 2014 10:03:11 +0000 From: To: , Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt Thread-Index: AQHPHm620e/80jfD1UW9be2tq4vEmZqeqHFwgACF+wCABX36kIACYuGAgAE485CABhMQMIAAVyEAgAEwdtA= Date: Tue, 11 Feb 2014 10:03:10 +0000 Message-ID: References: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> <52EBF104.7000303@alum.mit.edu> <52F28CE1.2070808@alum.mit.edu> <52F8F4F8.90002@alum.mit.edu> In-Reply-To: <52F8F4F8.90002@alum.mit.edu> 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.219] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean 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: Tue, 11 Feb 2014 10:03:41 -0000 -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 10 February, 2014 17:49 To: Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt Simo, What you describe below is enough to get me to shut up. :-) On 2/10/14 5:44 AM, Simo.Veikkolainen@nokia.com wrote: > Hello Paul, all, > > I've copied the bullets from your email below, and propose the following = text to address your concerns: > > * explanation of how things work when changing media mid call - from RTP = to CS, CS to RTP, or even CS to different CS. Point out that this is break-= before-make, and when the user will again perceive to have media. > > -> Add in 5.6.4. Modifying the session > > If either party would like to remove existing RTP based media from the se= ssion and replace that with a circuit-switched bearer, it would create a ne= w Offer to add the circuit-switched media as described in Section 5.6.1. ab= ove, and remove the RTP based media by setting the port number to zero. Onc= e the Offer/Answer exchange is done, but the circuit-switched bearer is not= yet established, there may be a period of time when no media is available.= Also, it may happen that correlating the circuit-switched call fails for r= easons discussed in Section 5.3.3. In this case, even if the Offer/Answer e= xchange was successful, endpoints are not able to receive or send media. It= is up to the implementation to decide the behavior in this case; if nothin= g else is done, the user most likely hangs up after a while if there was no= other media in the session. Note that this may also happen when switching = from RTP media to another RTP media (for example when firewall blocks the n= ew media strea! m). I find it interesting that you describe adding a new m-line for the cs sess= ion and rejecting the old one. It should also be valid to simply replace th= e old (rtp) m-line with the new (cs) m-line. [SV] This was actually something I was supposed to check before updating th= e draft text, as I wasn't quite sure whether the old media description shou= ld be explicitly rejected first and the new one added. But, as you say, it = should be enough to simply replace the old m-line with the new m-line. If you are thinking of using two m-lines, then make-before-break is just a = matter of keeping them both active for awhile. [SV] That is also possible, though in this case you would receive two media= streams for a while (typically, two audio streams from the same source). B= ut of course, implementations could be clever enough to suppress the other = until cut-over is done.=20 Simo Thanks, Paul > If either party would like to remove existing circuit-switched media from= the session and replace that with RTP based media, it would create a new O= ffer and set the circuit-switched port number to zero, and add a descriptio= n for RTP based media. The endpoint MUST then terminate the circuit-switche= d bearer using whatever mechanism is appropriate for the technology in ques= tion. > > * much about external correlation. Is this really a mechanism in the sens= e that the others are, that serves as a screen on CS calls until the one is= found that correlates? Or does it really mean that any incoming CS call is= taking as the right one, included in the sip session, with the user left t= o take independent action (such as hanging up) if he decides it isn't the r= ight one? > > -> add in 5.2.3.5. The External correlation mechanism > > The external correlation mechanism relies on the human user to do the dec= ision on whether the call is related to the ongoing session or not. After t= he user accepts the call, that bearer is considered as related to the sessi= on. There is a small chance that the user receives at the same time another= circuit-switched call which is not related to the ongoing session. The use= r may reject this call if he is able to determine (e.g. based on the callin= g line identification) that the call is not related to the session, and con= tinue waiting for another call attempt. If the user accepts the incoming ci= rcuit-switched call, but it turns out to be not related to the session, the= endpoints need to rely on the human user to take appropriate action (typic= ally, they would hang up). > > * For DTMF correlation, does the user see media in the call before the co= rrelation is successfully completed. > > I think this is an implementation specific matter. We could add a recomme= ndation of some sorts, but really it is up to the implementation to decide. > > * potentially (but maybe not in this draft) a discussion of how to=20 > achieve make-before-break semantics. (E.g., Using multiple m-lines.) > > This seems to be a larger issue which is not specific to circuit-switched= media alone, to probably it would be best to address it in a standalone do= cument. > > Regards, > Simo > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Veikkolainen Simo (Nokia-CTO/Espoo) > Sent: 07 February, 2014 10:38 > To: pkyzivat@alum.mit.edu; mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > See below [SV] > > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 05 February, 2014 21:11 > To: Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > On 2/4/14 2:18 AM, Simo.Veikkolainen@nokia.com wrote: >> >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Paul=20 >> Kyzivat >> Sent: 31 January, 2014 20:53 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt >> >> I just reviewed the new version. First I looked at just the diffs. But t= hose raised some more general questions in my mind, so I re-reviewed more o= f the draft. I'm left with some considerable confusion about how this is in= tended to work in practice, especially with extern correlation, but even wi= th the other forms. >> >> In particular, I am unclear of the sequencing of O/A processing,=20 >> correlation processing, and signaling completion. (I realize this is=20 >> an mmusic draft and theoretically independent of sip, but forgive me=20 >> 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 a= nd 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 n= ew O/A replace the old one. If the reinvite fails, then the session is supp= osed to continue as it was before the reinvite. In the interim, from the se= nding of the reinvite until its success or failure, things are a little con= fusing - 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 correlat= ion 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? >> >> [SV] I assume you mean the 200 carries the Answer. > > Not necessarily. I was just trying to sort out the expectations for the t= iming of the events. The answer could be *before* the 200, but it must be b= efore the call is established. > >> It may happen that the CS call arrives before the Answer, but in this ca= se no correlation can be done. See Section 5.6.3. If the invite (I assume y= ou mean O/A) completes first, but no CS call ever arrives, or correlation -= including the "external" mechanism fails, the endpoint should treat the CS= call as unrelated; this is described in Section 5.3.3. > > Sure, but my question is whether correlation is expected to occur before = or after the INVITE completes. > > [SV] Correlation can only occur after the correlation information has bee= n exchanged, and the CS call is received. I'm not sure what you mean by INV= ITE being completed, but I would say correlation can be done already before= the last request (ACK) has been sent, or after the whole INVITE related re= quest-response exchange has been completed (in case the CS call is received= late). > >> - 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?) >> >> [SV] CS media starts to flow after the call has been accepted, as in a n= ormal CS call. Correlation may be possible before accepting the call (for "= callerid", "uuie", and "external" mechanisms), and for "dtmf" case only aft= er the call has been accepted. > > I should have been clearer. For DTMF and external correlation media clear= ly needs to flow on the CS call. My question pertains to whether this is co= nsidered part of the SIP session prior to correlation. > > [SV] Again, I'm not sure I'm able to follow your thought but correlation = is needed before the CS media is considered as part of the session. > >> - if media flows to the user before correlation, then what if >> correlation fails? Will another call be accepted and correlation >> be attempted again? >> >> [SV] I don' think we have explicitly defined this situation. If a call i= s accepted and *after* that correlation fails, it means that the DTMF mecha= nism was used (for other correlation mechanisms, we know before accepting t= he call whether the correlation was successful). > > external correlation via also has this problem, and more. > >> If the DTMF pattern is not received correctly, as we cannot know whether= it is related to the session or not. Now, this raises a possible case of i= ncluding both "dtmf" and "external" mechanisms in the O/A. If DTMF is succe= ssfully negotiated but it fails, we can't really use the "external" mechani= sm since the call is already accepted. Implementations could in this case r= elease the CS call and try a new O/A without the DTMF. > > I'm finding external correlation to be underspecified. > > One one I could conceive of it working is that the incoming CS call is tr= eated something like a call waiting situation. The existing (sip) call is "= suspended" and the user is connected to the CS call, and asked to confirm i= f it is the intended one. If the user signals confirmation, then the sip ca= ll is resumed, with the CS audio stream in it. > > If the external correlation fails, then the sip call is resumed without t= he CS media. > > A problem with this is that the O/A completes prior to the CS call=20 > establishment and correlation. If this happens mid-call (because of a=20 > desire to switch from RTP to CS media) then the RTP media will be=20 > abandoned once the O/A succeeds, before correlation. So while waiting=20 > for a CS call to arrive and be correlated you have no RTP media. :-( > > [SV] Ok now I think I see your point. The O/A needs to be completed befor= e correlation can take place. If this happens mid-call, it can indeed happe= n that the correlation fails and there is no media. On the other hand, ther= e are a number of reasons why the same could happen to RTP based media as w= ell. So, it can either be considered as an call failure case, or the other = possibility would be to first add the CS media, and if it succeeds, do anot= her O/A to remove the RTP based media. The drawback in this case is that th= e endpoints would receive two media streams for a short while. > >> - 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.) >> >> [SV] This would be an issue for the DTMF case, as there correlation can = be only only after accepting the CS call. An unlikely case, but still possi= ble. In this case, one of the CS calls could be related to the session, whi= le other(s) would be normal CS calls. As only one CS call can be handled at= a time, others would either wait or be terminated, depending on the callee= 's supplementary services settings. > > For DTMF, the correlation could be done *before* relating the CS call to = the session. Only bind it to the session after correlation is complete. > > But that doesn't work as well for external correlation. > > [SV] For both DTMF and external, the CS call needs to be accepted first, = but when using DTMF it is possible (and advisable) to not play back the med= ia to the user until correlation has been done. For external case, the medi= a would need to be played back . > >> - 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? >> >> [SV] The external correlation mechanism does not assume the media flows = before "correlation" is made - if the user decides to accept the incoming c= all, it is considered as "correlated". > > The user has to receive (hear) the media (and maybe send some too) before= he can decide on correlation. Has the CS call be "related to the session" = then, or not? > > [SV] From a protocol point of view, I would say the call is considered as= related to the session if the user accepts the call. But, you're right tha= t the user cannot be really sure before some words are exchanged on the CS = call. > > What happens if the user decides the CS call *isn't* correlated? > > [SV] The user would likely hang up. > >> Now consider a call that is initially established with one RTP media str= eam. Later, a reinvite is sent with an offer proposing to to replace that w= ith a CS media stream: >> >> - again, there must be an answer before the CS call can be attempted. >> >> >> [SV] For being able to perform correlation, yes, the Answer needs to be = received. >> >> - 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. >> >> [SV] The O/A needs to be completed before correlation can be done, but C= S call may arrive before Answer. In this case the endpoint should wait unti= l the Answer is received. If the CS call does not succeed, or correlation i= s unsuccessful, then yes there is no media as the RTP stream has been dropp= ed. But, this could also happen when re-negotiating RTP media types (endpoi= nts are not able to load correct codecs, new IP addr/port does not work etc= .) so the situation not be specific to the CS media type. > > Yes, it is not entirely unique, but usually updated O/As are done with an= option in common to the prior one so that failure is unlikely. The failure= modes are quite different when transitioning from RTP to CS. > (And also when transitioning from CS to RTP.) > > [SV] Agreed, adding a CS call introduces an additional level of uncertain= ty. > >> - all the issues above also apply here. >> >> ISTM that there is a bunch of missing explanation of how this is expecte= d to work. >> >> [SV] Could you check the above whether my comments clarify the situation= . We can address them in more details in the draft as well once we know whe= re more explanation is needed. > > Upon rereading section 5.6.2 I realize that it does say that the answer m= ust be received before the CS call is placed and correlated, so it implies = a break-before-make approach on reINVITE. > > What I still think is missing is: > > * explanation of how things work when changing media mid call - from RTP = to CS, CS to RTP, or even CS to different CS. Point out that this is break-= before-make, and when the user will again perceive to have media. > > * much about external correlation. Is this really a mechanism in the sens= e that the others are, that serves as a screen on CS calls until the one is= found that correlates? Or does it really mean that any incoming CS call is= taking as the right one, included in the sip session, with the user left t= o take independent action (such as hanging up) if he decides it isn't the r= ight one? > > * For DTMF correlation, does the user see media in the call before the co= rrelation is successfully completed. > > * potentially (but maybe not in this draft) a discussion of how to=20 > achieve make-before-break semantics. (E.g., Using multiple m-lines.) > > [SV] I need to go through these with more thought with my co-author. We'l= l get back to this. > > Thanks > Simo > > Thanks, > Paul > >> 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" >> >> [SV] Fill fix. >> >> Thanks, >> Simo >> >> 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 correlat= ion 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 i= s 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 (be= fore all three were MTI). >>> - we have introduced a fourth correlation type ("external") which indic= ates explicit support for cases where also some external means, typically t= he human user, can do the correlation. This can be as a fallback in cases w= here no other common correlation mechanism is found, or the negotiated corr= elation mechanisms fail due to being not supported in the PSTN network. Thi= s 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 t= hese changes. >>> >>> On behalf of the authors, >>> Simo >>> >>> PS. I'll add the proposed change in http://www.ietf.org/mail-archive/we= b/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=20 >>> 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 dire= ctories. >>> This draft is a work item of the Multiparty Multimedia Session Cont= rol Working Group of the IETF. >>> >>> Title : Session Description Protocol (SDP) Extensi= on 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 extensi= ons >>> for using the Session Description Protocol (SDP) Offer/Answer mod= el >>> for establishing audio and video media streams over circuit-switc= hed >>> 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 submi= ssion 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 >>> >> >> _______________________________________________ >> 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 iesg-secretary@ietf.org Tue Feb 11 07:58: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 610601A0583; Tue, 11 Feb 2014 07:58: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 vXh4rf8wgjE2; Tue, 11 Feb 2014 07:58:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A67EC1A0602; Tue, 11 Feb 2014 07:58:08 -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: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211155808.1141.55716.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 07:58:08 -0800 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'Real Time Streaming Protocol 2.0 (RTSP)' to Proposed Standard (draft-ietf-mmusic-rfc2326bis-40.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: Tue, 11 Feb 2014 15:58:18 -0000 The IESG has approved the following document: - 'Real Time Streaming Protocol 2.0 (RTSP)' (draft-ietf-mmusic-rfc2326bis-40.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-rfc2326bis/ Technical Summary The document 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-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). Working Group Summary The document has been work in progress for an extended period of time dating back to 2002. Earlier versions saw decent WG participation however the later versions have primarily been driven by the document authors with limited overall discussion in the group, especially towards the end of the process. There are no known issues or major discussion points, and there has been no indication of lack of consensus in the WG. Document Quality The document has been reviewed in detail several times after WGLC and in preparation for the publication request and the authors have made several updates as a result of those. The document is considered to be of high quality at this point. There is one known implementation of the specification, and many of the extensions compared to RTSP 1.0 have been implemented separately as well. A Media type review was done for "text/parameters". The review thread can be found at: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01656.html Personnel Document Shepherd: Flemming Andreasen Responsible AD: Gonzalo Camarillo RFC Editor's Note: Section 2 of this document and its subsections provide "an informative overview of the different mechanisms in the RTSP 2.0 protocol, to give the reader a high level understanding". As such, it's very important that it be clear and well written. Some reviewers have found the English to be difficult. Please take an especially critical pen to this section, making sure that the grammar and usage are correct, and that the language is clear. From internet-drafts@ietf.org Tue Feb 11 11:46: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 477FD1A06F9; Tue, 11 Feb 2014 11:46: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 37YhvhEegJcg; Tue, 11 Feb 2014 11:46:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA501A0713; Tue, 11 Feb 2014 11:46:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211194651.20512.73403.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 11:46:51 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-23.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: Tue, 11 Feb 2014 19:46:53 -0000 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-23.txt Pages : 38 Date : 2014-02-11 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-23 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-cs-23 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 Tue Feb 11 11:53: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 B85881A0700 for ; Tue, 11 Feb 2014 11:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 o-8GQxn1OYd3 for ; Tue, 11 Feb 2014 11:53:14 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9191D1A071F for ; Tue, 11 Feb 2014 11:53:12 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.20]) by mgw-sa01.nokia.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s1BJpD9N010239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 11 Feb 2014 21:51:13 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.28]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.03.0158.002; Tue, 11 Feb 2014 19:51:12 +0000 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt Thread-Index: AQHPHm620e/80jfD1UW9be2tq4vEmZqeqHFwgACF+wCABX36kIACYuGAgAE485CABhMQMIAAVyEAgAEwdtCAAKTBIA== Date: Tue, 11 Feb 2014 19:51:12 +0000 Message-ID: References: <20140131102500.16331.97623.idtracker@ietfa.amsl.com> <52EBF104.7000303@alum.mit.edu> <52F28CE1.2070808@alum.mit.edu> <52F8F4F8.90002@alum.mit.edu> In-Reply-To: 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: [213.243.168.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean 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: Tue, 11 Feb 2014 19:53:21 -0000 Dear WG,=20 We just submitted version -23 addressing these comments. The new version also includes the note on the E.164 format which slipped fr= om version -22 (see http://www.ietf.org/mail-archive/web/mmusic/current/msg= 12792.html ) Regards, Simo -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Veikkolainen Sim= o (Nokia-CTO/Espoo) Sent: 11 February, 2014 12:03 To: pkyzivat@alum.mit.edu; mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 10 February, 2014 17:49 To: Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt Simo, What you describe below is enough to get me to shut up. :-) On 2/10/14 5:44 AM, Simo.Veikkolainen@nokia.com wrote: > Hello Paul, all, > > I've copied the bullets from your email below, and propose the following = text to address your concerns: > > * explanation of how things work when changing media mid call - from RTP = to CS, CS to RTP, or even CS to different CS. Point out that this is break-= before-make, and when the user will again perceive to have media. > > -> Add in 5.6.4. Modifying the session > > If either party would like to remove existing RTP based media from the se= ssion and replace that with a circuit-switched bearer, it would create a ne= w Offer to add the circuit-switched media as described in Section 5.6.1. ab= ove, and remove the RTP based media by setting the port number to zero. Onc= e the Offer/Answer exchange is done, but the circuit-switched bearer is not= yet established, there may be a period of time when no media is available.= Also, it may happen that correlating the circuit-switched call fails for r= easons discussed in Section 5.3.3. In this case, even if the Offer/Answer e= xchange was successful, endpoints are not able to receive or send media. It= is up to the implementation to decide the behavior in this case; if nothin= g else is done, the user most likely hangs up after a while if there was no= other media in the session. Note that this may also happen when switching = from RTP media to another RTP media (for example when firewall blocks the n= ew media strea! m). I find it interesting that you describe adding a new m-line for the cs sess= ion and rejecting the old one. It should also be valid to simply replace th= e old (rtp) m-line with the new (cs) m-line. [SV] This was actually something I was supposed to check before updating th= e draft text, as I wasn't quite sure whether the old media description shou= ld be explicitly rejected first and the new one added. But, as you say, it = should be enough to simply replace the old m-line with the new m-line. If you are thinking of using two m-lines, then make-before-break is just a = matter of keeping them both active for awhile. [SV] That is also possible, though in this case you would receive two media= streams for a while (typically, two audio streams from the same source). B= ut of course, implementations could be clever enough to suppress the other = until cut-over is done.=20 Simo Thanks, Paul > If either party would like to remove existing circuit-switched media from= the session and replace that with RTP based media, it would create a new O= ffer and set the circuit-switched port number to zero, and add a descriptio= n for RTP based media. The endpoint MUST then terminate the circuit-switche= d bearer using whatever mechanism is appropriate for the technology in ques= tion. > > * much about external correlation. Is this really a mechanism in the sens= e that the others are, that serves as a screen on CS calls until the one is= found that correlates? Or does it really mean that any incoming CS call is= taking as the right one, included in the sip session, with the user left t= o take independent action (such as hanging up) if he decides it isn't the r= ight one? > > -> add in 5.2.3.5. The External correlation mechanism > > The external correlation mechanism relies on the human user to do the dec= ision on whether the call is related to the ongoing session or not. After t= he user accepts the call, that bearer is considered as related to the sessi= on. There is a small chance that the user receives at the same time another= circuit-switched call which is not related to the ongoing session. The use= r may reject this call if he is able to determine (e.g. based on the callin= g line identification) that the call is not related to the session, and con= tinue waiting for another call attempt. If the user accepts the incoming ci= rcuit-switched call, but it turns out to be not related to the session, the= endpoints need to rely on the human user to take appropriate action (typic= ally, they would hang up). > > * For DTMF correlation, does the user see media in the call before the co= rrelation is successfully completed. > > I think this is an implementation specific matter. We could add a recomme= ndation of some sorts, but really it is up to the implementation to decide. > > * potentially (but maybe not in this draft) a discussion of how to=20 > achieve make-before-break semantics. (E.g., Using multiple m-lines.) > > This seems to be a larger issue which is not specific to circuit-switched= media alone, to probably it would be best to address it in a standalone do= cument. > > Regards, > Simo > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Veikkolainen Simo (Nokia-CTO/Espoo) > Sent: 07 February, 2014 10:38 > To: pkyzivat@alum.mit.edu; mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > See below [SV] > > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 05 February, 2014 21:11 > To: Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt > > On 2/4/14 2:18 AM, Simo.Veikkolainen@nokia.com wrote: >> >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Paul=20 >> Kyzivat >> Sent: 31 January, 2014 20:53 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt >> >> I just reviewed the new version. First I looked at just the diffs. But t= hose raised some more general questions in my mind, so I re-reviewed more o= f the draft. I'm left with some considerable confusion about how this is in= tended to work in practice, especially with extern correlation, but even wi= th the other forms. >> >> In particular, I am unclear of the sequencing of O/A processing,=20 >> correlation processing, and signaling completion. (I realize this is=20 >> an mmusic draft and theoretically independent of sip, but forgive me=20 >> 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 a= nd 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 n= ew O/A replace the old one. If the reinvite fails, then the session is supp= osed to continue as it was before the reinvite. In the interim, from the se= nding of the reinvite until its success or failure, things are a little con= fusing - 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 correlat= ion 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? >> >> [SV] I assume you mean the 200 carries the Answer. > > Not necessarily. I was just trying to sort out the expectations for the t= iming of the events. The answer could be *before* the 200, but it must be b= efore the call is established. > >> It may happen that the CS call arrives before the Answer, but in this ca= se no correlation can be done. See Section 5.6.3. If the invite (I assume y= ou mean O/A) completes first, but no CS call ever arrives, or correlation -= including the "external" mechanism fails, the endpoint should treat the CS= call as unrelated; this is described in Section 5.3.3. > > Sure, but my question is whether correlation is expected to occur before = or after the INVITE completes. > > [SV] Correlation can only occur after the correlation information has bee= n exchanged, and the CS call is received. I'm not sure what you mean by INV= ITE being completed, but I would say correlation can be done already before= the last request (ACK) has been sent, or after the whole INVITE related re= quest-response exchange has been completed (in case the CS call is received= late). > >> - 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?) >> >> [SV] CS media starts to flow after the call has been accepted, as in a n= ormal CS call. Correlation may be possible before accepting the call (for "= callerid", "uuie", and "external" mechanisms), and for "dtmf" case only aft= er the call has been accepted. > > I should have been clearer. For DTMF and external correlation media clear= ly needs to flow on the CS call. My question pertains to whether this is co= nsidered part of the SIP session prior to correlation. > > [SV] Again, I'm not sure I'm able to follow your thought but correlation = is needed before the CS media is considered as part of the session. > >> - if media flows to the user before correlation, then what if >> correlation fails? Will another call be accepted and correlation >> be attempted again? >> >> [SV] I don' think we have explicitly defined this situation. If a call i= s accepted and *after* that correlation fails, it means that the DTMF mecha= nism was used (for other correlation mechanisms, we know before accepting t= he call whether the correlation was successful). > > external correlation via also has this problem, and more. > >> If the DTMF pattern is not received correctly, as we cannot know whether= it is related to the session or not. Now, this raises a possible case of i= ncluding both "dtmf" and "external" mechanisms in the O/A. If DTMF is succe= ssfully negotiated but it fails, we can't really use the "external" mechani= sm since the call is already accepted. Implementations could in this case r= elease the CS call and try a new O/A without the DTMF. > > I'm finding external correlation to be underspecified. > > One one I could conceive of it working is that the incoming CS call is tr= eated something like a call waiting situation. The existing (sip) call is "= suspended" and the user is connected to the CS call, and asked to confirm i= f it is the intended one. If the user signals confirmation, then the sip ca= ll is resumed, with the CS audio stream in it. > > If the external correlation fails, then the sip call is resumed without t= he CS media. > > A problem with this is that the O/A completes prior to the CS call=20 > establishment and correlation. If this happens mid-call (because of a=20 > desire to switch from RTP to CS media) then the RTP media will be=20 > abandoned once the O/A succeeds, before correlation. So while waiting=20 > for a CS call to arrive and be correlated you have no RTP media. :-( > > [SV] Ok now I think I see your point. The O/A needs to be completed befor= e correlation can take place. If this happens mid-call, it can indeed happe= n that the correlation fails and there is no media. On the other hand, ther= e are a number of reasons why the same could happen to RTP based media as w= ell. So, it can either be considered as an call failure case, or the other = possibility would be to first add the CS media, and if it succeeds, do anot= her O/A to remove the RTP based media. The drawback in this case is that th= e endpoints would receive two media streams for a short while. > >> - 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.) >> >> [SV] This would be an issue for the DTMF case, as there correlation can = be only only after accepting the CS call. An unlikely case, but still possi= ble. In this case, one of the CS calls could be related to the session, whi= le other(s) would be normal CS calls. As only one CS call can be handled at= a time, others would either wait or be terminated, depending on the callee= 's supplementary services settings. > > For DTMF, the correlation could be done *before* relating the CS call to = the session. Only bind it to the session after correlation is complete. > > But that doesn't work as well for external correlation. > > [SV] For both DTMF and external, the CS call needs to be accepted first, = but when using DTMF it is possible (and advisable) to not play back the med= ia to the user until correlation has been done. For external case, the medi= a would need to be played back . > >> - 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? >> >> [SV] The external correlation mechanism does not assume the media flows = before "correlation" is made - if the user decides to accept the incoming c= all, it is considered as "correlated". > > The user has to receive (hear) the media (and maybe send some too) before= he can decide on correlation. Has the CS call be "related to the session" = then, or not? > > [SV] From a protocol point of view, I would say the call is considered as= related to the session if the user accepts the call. But, you're right tha= t the user cannot be really sure before some words are exchanged on the CS = call. > > What happens if the user decides the CS call *isn't* correlated? > > [SV] The user would likely hang up. > >> Now consider a call that is initially established with one RTP media str= eam. Later, a reinvite is sent with an offer proposing to to replace that w= ith a CS media stream: >> >> - again, there must be an answer before the CS call can be attempted. >> >> >> [SV] For being able to perform correlation, yes, the Answer needs to be = received. >> >> - 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. >> >> [SV] The O/A needs to be completed before correlation can be done, but C= S call may arrive before Answer. In this case the endpoint should wait unti= l the Answer is received. If the CS call does not succeed, or correlation i= s unsuccessful, then yes there is no media as the RTP stream has been dropp= ed. But, this could also happen when re-negotiating RTP media types (endpoi= nts are not able to load correct codecs, new IP addr/port does not work etc= .) so the situation not be specific to the CS media type. > > Yes, it is not entirely unique, but usually updated O/As are done with an= option in common to the prior one so that failure is unlikely. The failure= modes are quite different when transitioning from RTP to CS. > (And also when transitioning from CS to RTP.) > > [SV] Agreed, adding a CS call introduces an additional level of uncertain= ty. > >> - all the issues above also apply here. >> >> ISTM that there is a bunch of missing explanation of how this is expecte= d to work. >> >> [SV] Could you check the above whether my comments clarify the situation= . We can address them in more details in the draft as well once we know whe= re more explanation is needed. > > Upon rereading section 5.6.2 I realize that it does say that the answer m= ust be received before the CS call is placed and correlated, so it implies = a break-before-make approach on reINVITE. > > What I still think is missing is: > > * explanation of how things work when changing media mid call - from RTP = to CS, CS to RTP, or even CS to different CS. Point out that this is break-= before-make, and when the user will again perceive to have media. > > * much about external correlation. Is this really a mechanism in the sens= e that the others are, that serves as a screen on CS calls until the one is= found that correlates? Or does it really mean that any incoming CS call is= taking as the right one, included in the sip session, with the user left t= o take independent action (such as hanging up) if he decides it isn't the r= ight one? > > * For DTMF correlation, does the user see media in the call before the co= rrelation is successfully completed. > > * potentially (but maybe not in this draft) a discussion of how to=20 > achieve make-before-break semantics. (E.g., Using multiple m-lines.) > > [SV] I need to go through these with more thought with my co-author. We'l= l get back to this. > > Thanks > Simo > > Thanks, > Paul > >> 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" >> >> [SV] Fill fix. >> >> Thanks, >> Simo >> >> 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 correlat= ion 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 i= s 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 (be= fore all three were MTI). >>> - we have introduced a fourth correlation type ("external") which indic= ates explicit support for cases where also some external means, typically t= he human user, can do the correlation. This can be as a fallback in cases w= here no other common correlation mechanism is found, or the negotiated corr= elation mechanisms fail due to being not supported in the PSTN network. Thi= s 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 t= hese changes. >>> >>> On behalf of the authors, >>> Simo >>> >>> PS. I'll add the proposed change in http://www.ietf.org/mail-archive/we= b/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=20 >>> 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 dire= ctories. >>> This draft is a work item of the Multiparty Multimedia Session Cont= rol Working Group of the IETF. >>> >>> Title : Session Description Protocol (SDP) Extensi= on 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 extensi= ons >>> for using the Session Description Protocol (SDP) Offer/Answer mod= el >>> for establishing audio and video media streams over circuit-switc= hed >>> 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 submi= ssion 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 >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Tue Feb 11 14:43: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 E274C1A07D6 for ; Tue, 11 Feb 2014 14:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 7d3ezOnx9YEu for ; Tue, 11 Feb 2014 14:43:32 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D35D11A0767 for ; Tue, 11 Feb 2014 14:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1699; q=dns/txt; s=iport; t=1392158612; x=1393368212; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=h6c7GZWSwuWldkm6LZ7zar/5Knj4l0ON7abwm3B8des=; b=LHcoLvRNmWatTXjhrILWK+S7Hcn8wUVhVMUJu1zLFDblZQVNmSKUeC0P lgo+8dNKbeSBb+NEqN574cKsbILoCH37s+dy55n4IG5dVEDVtVWWN9DNn w4iVJgDE8IW1SiPa+b2ZAMaBmhoxP7v/VKlMXjt0cQ7X598rtxTLo1sLq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAAyn+lKrRDoJ/2dsb2JhbABagww4vxlPgRcWdIIlAQEBBAEBATU2ChELGAkWDwkDAgECARUwBgEMBgIBAYgADslbEwSPAIQ4AQOJSIp5g2mSIINLHg X-IronPort-AV: E=Sophos;i="4.95,828,1384300800"; d="scan'208";a="105450680" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 11 Feb 2014 22:43:32 +0000 Received: from bxb-fandreas-8814.cisco.com (bxb-fandreas-8814.cisco.com [10.98.149.197]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1BMhUH5023868; Tue, 11 Feb 2014 22:43:31 GMT Message-ID: <52FAA792.1090500@cisco.com> Date: Tue, 11 Feb 2014 17:43: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: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1533E8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1533E8@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-04 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, 11 Feb 2014 22:43:35 -0000 Hi Christer I took a look at the latest draft and I have some comments: - The Offer/Answer sections could use a bit more work. We try to have the following sub-sections with relevant procedures called out (in line with RFC 3264): 1) Generating the Initial Offer 2) Generating the Answer 3) Offerer Processing of the Answer 4) Modify the Session and I'd much prefer the same here. - Related to offer/answer, I find it underspecified in terms of things that are (or are not) at the session versus media-level. It should be more explicit here. - NAT Traversal Without ICE I'm not sure I follow this section. If the passive party is behind a NAT and then sends a STUN request to the active party in order to create a NAT binding, then the active party won't know the external NAT address and hence its ClientHello message won't get through (unless you are saying that it needs to look for such unauthenticated STUN messages and then start sending packet to their source address, at which point we are headed down a slippery slope on security implications, reinventing or ICE, or both). - Backwards compatibility/interoperability considerations with vanilla UDPTL implementations; how do you negotiate successfully ? I have a couple of nits that I'll send to you off-line as well. Thanks -- Flemming On 2/1/14, 9:31 AM, Christer Holmberg wrote: > Hi, > > Based on the review comments by Adam G and Ari K, I've submitted a new version (-04) of the udptl-dtls draft. > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Wed Feb 12 03:40: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 F2F8A1A0967 for ; Wed, 12 Feb 2014 03:40:37 -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 0V77O_Bfv5Lb for ; Wed, 12 Feb 2014 03:40:36 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 66B4C1A0974 for ; Wed, 12 Feb 2014 03:40:33 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-52-52fb5daf1cac Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 39.F3.10875.FAD5BF25; Wed, 12 Feb 2014 12:40:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 12:40:31 +0100 From: Christer Holmberg To: Flemming Andreasen , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-04 Thread-Index: Ac8fWlB56/jKKzGxQfaztM+rXapv5gIF/00AABvz/DA= Date: Wed, 12 Feb 2014 11:40:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16E918@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1533E8@ESESSMB209.ericsson.se> <52FAA792.1090500@cisco.com> In-Reply-To: <52FAA792.1090500@cisco.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvje6G2N9BBj3TOCzeX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbHq0W/mgi88FfcbtjI1MC7n6mLk5JAQMJF4 sOQTO4QtJnHh3nq2LkYuDiGBQ4wS05e8YoJwFjNKbJywmrWLkYODTcBCovufNkiDiECQxOr7 u5lAwsICHhL7H3lAhD0lzky4xQJhW0m8eviaCcRmEVCVmH37PjOIzSvgKzGt/R1YjZBAjsT7 R8fYQGxOAU2Jo2ffMYLYjED3fD+1BqyXWUBc4taT+UwQdwpILNlznhnCFpV4+fgf2GUSAooS y/vlIMp1JBbs/sQGYWtLLFv4GmqtoMTJmU9YJjCKzkIydRaSlllIWmYhaVnAyLKKkT03MTMn vdxwEyMwCg5u+a27g/HUOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YOzgWmza0FzG9Ddw2nabDP6zz5+75ES/134lf3hSc4n2XbUvqVfUL8+oSY9sabeQi9kiHRMZ t9RpTj7X13ntPwQEfnlXPTrdtVjlsR9/vd+ja0rbTb1FJtUmmJUsz+zUCm82OqHJNvnB3Dtu XBuTOPU4tlg759jplqqsruV5mZ/vmPJSR8NIiaU4I9FQi7moOBEASsgnSVACAAA= Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-04 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, 12 Feb 2014 11:40:38 -0000 Hi, I'll get back to your comment regarding SDP Offer/Answer procedures later. > - NAT Traversal Without ICE > I'm not sure I follow this section. If the passive party is behind a NAT = and then sends a STUN request to the active party=20 > in order to create a NAT binding, then the active party won't know the ex= ternal NAT address and hence its ClientHello=20 > message won't get through (unless you are saying that it needs to look fo= r such unauthenticated STUN messages and=20 > then start sending packet to their source address, at which point we are = headed down a slippery slope on security implications, reinventing or ICE, = or both). This part is re-used from RFC 5763, as part of the Middlebox Interaction se= ction, so I assume the idea is that the STUN messages are terminated by an = SBC (5763 talks about latching). However, my suggestion would be to remove section 4.2.2 completely. We need= 4.2.1 and 4.2.3, which are related to ICE. Then, whatever other mechanisms= people may use to do NAT traversal, are out of the scope. ------------------ > - Backwards compatibility/interoperability considerations with vanilla UD= PTL implementations; how do you negotiate successfully ? The draft defines a mechanism to negotiate a secure fax channel. If one end= point doesn't support it, there will be no successful negotiation, and no s= ecure fax channel.=20 However, I guess I can add some informative text, saying that if the user i= s ok to have a non-secure fax channel in case of failure, it can send a new= offer with non-secure fax. Or, it can use CapNeg. Regards, Christer From christer.holmberg@ericsson.com Wed Feb 12 06:46: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 B06141A09A9 for ; Wed, 12 Feb 2014 06:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 u2uDS77HlY04 for ; Wed, 12 Feb 2014 06:46:43 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C4D2D1A0340 for ; Wed, 12 Feb 2014 06:46:42 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-b1-52fb89517b82 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 30.94.23809.1598BF25; Wed, 12 Feb 2014 15:46:41 +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; Wed, 12 Feb 2014 15:46:40 +0100 From: Christer Holmberg To: Flemming Andreasen , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-04 Thread-Index: Ac8fWlB56/jKKzGxQfaztM+rXapv5gIF/00AAB/OqZA= Date: Wed, 12 Feb 2014 14:46:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16EDB9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1533E8@ESESSMB209.ericsson.se> <52FAA792.1090500@cisco.com> In-Reply-To: <52FAA792.1090500@cisco.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvjW5g5+8gg0NLZSzeX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfF6yROmgk0KFYtmPmBtYJwj2cXIySEhYCIx Yf07RghbTOLCvfVsXYxcHEIChxglZj6ZyAzhLGaU2Dm3kaWLkYODTcBCovufNkiDiECQxOr7 u5lAwsICHhL7H3lAhD0lzky4xQJhW0m8f7aVCcRmEVCVaGhcygxi8wr4Sjx63w9WIySQI/H+ 0TE2EJtTQFPi6FmIexiB7vl+ag1YL7OAuMStJ/OZIO4UkFiy5zwzhC0q8fLxP1aQEyQEFCWW 98tBlOtILNj9iQ3C1pZYtvA11FpBiZMzn7BMYBSdhWTqLCQts5C0zELSsoCRZRUje25iZk56 udEmRmAUHNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA WNC93W1d2vyanzOVHm2JP5bhuKZ7c8who6IpZg2pBtc8bvx0PtIw34G9WpOf+8SiCrMfEsGz yuZH/bVTvr8meJKjZ/nZTMUSe4dL7QeCr7VxK3b29J5wrrxc9OrGYpXpio1md5uOOStcNXc4 f3bH0+PVVgLnZLuuGuxo/NkWuvpOyfPIc+krlViKMxINtZiLihMBOPQl91ACAAA= Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-04 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, 12 Feb 2014 14:46:45 -0000 Hi Flemming, >- The Offer/Answer sections could use a bit more work. We try to have the = following sub-sections with relevant procedures called out (in line with RF= C 3264): >1) Generating the Initial Offer >2) Generating the Answer >3) Offerer Processing of the Answer >4) Modify the Session >and I'd much prefer the same here. > >- Related to offer/answer, I find it underspecified in terms of things tha= t are (or are not) at the session versus media-level. It should be more exp= licit here. It did require some restructuring, but I was able to keep most of the text = (with some clarifications). Something like (Note that the compatibility with UDPTL over UDP will be cov= ered in Section 5): ---------------- 3. Secure Channel The UDPTL over DTLS media stream is negotiated using the SDP offer/ answer mechanism [RFC3264]. DTLS is used as specified in [RFC6347]. Once the DTLS handshake is successfully completed (in order to prevent facsimile data from being transmitted insecurely), the UDPTL packets SHALL be transported in DTLS record layer "application_data" packets. 4. SDP Offerer/Answerer Procedures 4.1. General The offerer and answerer MUST create an SDP media description ("m=3D" line) for each UDPTL over DTLS media stream, and MUST assign a UDP/ TLS/UDPTL value to the "proto" field of the "m=3D" line. The procedures in this section apply to such "m=3D" line. In negotiation of a UDPTL over DTLS media stream, the following SDP attbibutes are used: o The SDP attributes defined for UDPTL over UDP, as described in [ITU.T38.2010]; and o The SDP attributes, defined in [RFC4145] and [RFC4572], as described in this section. The offerer and answerer MUST NOT use the SDP connection attribute [RFC4145]. In order to negotiate the TLS roles for the UDPTL over DTLS transport connection, the offerer and answerer MUST use the SDP setup attribute [RFC4145]. If an endpoint supports, and is willing to use, a cipher suite with an associated certificate, it MUST include an SDP fingerprint attribute [RFC4572]. 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. If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects. 4.2. SDP Offerer Procedures The offerer SHOULD assign the SDP setup attribute with a setup:actpass value. Alternatively, the offerer MAY assign the SDP setup attribute with a setup:active value or setup:passive value. The offerer MUST NOT assign an SDP setup attribute with a setup:holdconn value. If the offerer assigns the SDP setup attribute with a setup:actpass value or setup:passive value, the offerer MUST be prepared to receive a DTLS client_hello message before it receives the SDP answer. When the offerer receives the associated answer, if the offerer ends up being active it MUST initiate a DTLS handshake by sending a ClientHello message on the negotiated media stream, towards the IP address and port of the answerer. 4.3. SDP Answerer Procedures If the answerer accepts the offered UDPTL over DTLS transport connection, in the associated answer the answerer MUST assign an SDP setup attribute with either a setup:active value or setup:passive value, according to the procedures in [RFC4145]. The answerer MUST NOT assign an SDP setup attribute with a setup:holdconn value. If the answerer assigns a setup:active value, the answerer MUST initiate a DTLS handshake by sending a ClientHello message on the negotiated media stream, towards the IP address and port of the offerer. ---------------- From fandreas@cisco.com Wed Feb 12 07:10: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 47D7F1A03F5 for ; Wed, 12 Feb 2014 07:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 Kfz8XI2sgmfK for ; Wed, 12 Feb 2014 07:10:57 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 794F11A02A7 for ; Wed, 12 Feb 2014 07:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1927; q=dns/txt; s=iport; t=1392217831; x=1393427431; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=pKxD9yUr7czoXf7L/Zg1y3sca3wDJVf7Vyl6E2PyYiI=; b=cs8p+HmIsa8YnEzFu38cg7hIjTPevFe5q/SONXE4ipBcYOvOakGgcTxN 9/pZpRh9TUQ1ee2uyvBhdinXOEPtQNe0mUJn1hpt0U+DtXiFjbor5cWBm qePMXaBU1EtsIHZB7O2eCrHBJm2DZrZ6I5uN8rhOGQDLds5e7rFrYcPiB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FABiO+1KrRDoG/2dsb2JhbABagwzAN4ESFnSCJQEBAQMBOEAGCwsYCRYPCQMCAQIBRQYBDAgBAYd5B8lHF48AhDgBA4lIinmDaZIhg0se X-IronPort-AV: E=Sophos;i="4.95,832,1384300800"; d="scan'208";a="102287722" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 12 Feb 2014 15:10:31 +0000 Received: from bxb-fandreas-8814.cisco.com (bxb-fandreas-8814.cisco.com [10.98.149.197]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1CFAUYA000835; Wed, 12 Feb 2014 15:10:31 GMT Message-ID: <52FB8EE6.2030409@cisco.com> Date: Wed, 12 Feb 2014 10:10: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: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1533E8@ESESSMB209.ericsson.se> <52FAA792.1090500@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D16E918@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16E918@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-04 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, 12 Feb 2014 15:10:59 -0000 On 2/12/14, 6:40 AM, Christer Holmberg wrote: > Hi, > > I'll get back to your comment regarding SDP Offer/Answer procedures later. > >> - NAT Traversal Without ICE >> I'm not sure I follow this section. If the passive party is behind a NAT and then sends a STUN request to the active party >> in order to create a NAT binding, then the active party won't know the external NAT address and hence its ClientHello >> message won't get through (unless you are saying that it needs to look for such unauthenticated STUN messages and >> then start sending packet to their source address, at which point we are headed down a slippery slope on security implications, reinventing or ICE, or both). > This part is re-used from RFC 5763, as part of the Middlebox Interaction section, so I assume the idea is that the STUN messages are terminated by an SBC (5763 talks about latching). Ok - the draft doesn't say that and in general we don't recommend latching since it introduces various security issues (see the latching draft for more on all of this). > However, my suggestion would be to remove section 4.2.2 completely. We need 4.2.1 and 4.2.3, which are related to ICE. Then, whatever other mechanisms people may use to do NAT traversal, are out of the scope. I would agree with that. > > ------------------ > >> - Backwards compatibility/interoperability considerations with vanilla UDPTL implementations; how do you negotiate successfully ? > The draft defines a mechanism to negotiate a secure fax channel. If one endpoint doesn't support it, there will be no successful negotiation, and no secure fax channel. > > However, I guess I can add some informative text, saying that if the user is ok to have a non-secure fax channel in case of failure, it can send a new offer with non-secure fax. Or, it can use CapNeg. Sounds good. Thanks -- Flemming > Regards, > > Christer > > . > From suhasietf@gmail.com Wed Feb 12 11:10: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 43A7A1A0676 for ; Wed, 12 Feb 2014 11:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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_12=0.6, 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 4e9YAmUnBj16 for ; Wed, 12 Feb 2014 11:10:01 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 338201A062C for ; Wed, 12 Feb 2014 11:10:01 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so7487251wib.6 for ; Wed, 12 Feb 2014 11:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UUSWGTbgxzKhzwS8mk68REFR6t20nfsXvG+LrLOE2G0=; b=lueoNis5idjYLicNRL0RJ3a1KbaldokX7Jnjvuo6TUvQEFQFll/1XX4JwsUlsjAuR7 iW8kizbhGqblb0QALGhyih3B995ySFUZ2nf81muC0w8QbAO2qiJFV0CuPcFwxYQqnpXH dCxmhPlEuFWbyVi2/lZaXuqILna3HR8GOMAe42FYfiO6jViGY3KDzPdi+DZsL4YWU049 1FS9nAijWcHqQx6dHgA6YvaUKmziY6L5B4kf6I05NoVrMbCE0AuZmAd1pcQWRSVy+6zG dlGx0E814RugbkJUAYX3Ot/F+Fq77wrWIHpUKjOfMokyBSk3GFZAFNlfD/8UiAzx4IIq F1rQ== MIME-Version: 1.0 X-Received: by 10.180.210.171 with SMTP id mv11mr3378859wic.44.1392232199888; Wed, 12 Feb 2014 11:09:59 -0800 (PST) Received: by 10.195.12.134 with HTTP; Wed, 12 Feb 2014 11:09:59 -0800 (PST) Date: Wed, 12 Feb 2014 11:09:59 -0800 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=001a11c25d36b8433304f23a5122 Subject: [MMUSIC] BUNDLE and RFC 4091 ANAT Semantics 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, 12 Feb 2014 19:10:03 -0000 --001a11c25d36b8433304f23a5122 Content-Type: text/plain; charset=ISO-8859-1 Hello All, I am trying to analyze the multiplexing categorization for media streams that has ANAT semantics. Say we have the below SDP example v=0 o=bob 280744730 28977631 IN IP4 host.example.com s= t=0 0 a=group:ANAT 1 2 a=group:ANAT 3 4 m=audio 25000 RTP/AVP 0 c=IN IP6 2001:DB8::1 a= a=mid:1 m=audio 22334 RTP/AVP 0 c=IN IP4 192.0.2.1 a= a=mid:2 m=video 25112 RTP/AVP 0 c=IN IP6 2001:DB8::1 a= a=mid:3 m=video 24544 RTP/AVP 0 c=IN IP4 192.0.2.1 a= a=mid:4 Here we have audio stream with IPV6 and IPV6 network address, video streams doing the same as well. Now if we want to BUNDLE these m=lines, one possible way is to split BUNDLE into groups that belong to the same network address type (IPV4 or IPV6) as shown below v=0 o=bob 280744730 28977631 IN IP4 host.example.com s= t=0 0 a=group:ANAT 1 2 a=group:ANAT 3 4 a=group:BUNDLE 1 3 // BUNDLE IPv4 audio and video streams a=group:BUNDLE 2 4 // BUNDLE IPv6 audio and video streams. m=audio 25000 RTP/AVP 0 c=IN IP6 2001:DB8::1 a= a=mid:1 m=audio 22334 RTP/AVP 0 c=IN IP4 192.0.2.1 a= a=mid:2 m=video 25112 RTP/AVP 0 c=IN IP6 2001:DB8::1 a= a=mid:3 m=video 24544 RTP/AVP 0 c=IN IP4 192.0.2.1 a= a=mid:4 Any thoughts if this sounds like the right approach ? Cheers Suhas --001a11c25d36b8433304f23a5122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All,

I am trying to analyze= the multiplexing categorization for media streams that has ANAT semantics.=

Say we have the below SDP example
v=3D0
o=3Dbob 280744730 28977631 IN IP4 host.=
example.com
s=3D
t=3D0 0
a=3Dgroup:ANAT 1 2
a=3Dgroup:ANAT 3 4
m=3Daudio 25000 RTP/AVP 0
c=3DIN IP6 2001:DB8::1
a=3D <ICE-encoded additional IPv6 addresses (and ports)>
a=3Dmid:1
m=3Daudio 22334 RTP/AVP 0
c=3DIN IP4 192.0.2.1
a=3D <ICE-encoded additional IPv4 addresses (and ports)>
a=3Dmid:2
m=3Dvideo 25112 RTP/AVP 0
c=3DIN IP6 2001:DB8::1
a=3D <ICE-encoded additional IPv6 addresses (and ports)>
a=3Dmid:3
m=3Dvideo 24544 RTP/AVP 0
c=3DIN IP4 192.0.2.1
a=3D <ICE-encoded additional IPv4 addresses (and ports)>
a=3Dmid:4

Here we have audio stream with IPV6 and IPV6 network addres=
s, video streams doing the same as well.
Now if we want to BUNDLE thes=
e m=3Dlines, one possible way is to split BUNDLE into groups that belong to=
 the same network address type (IPV4 or IPV6) as shown below<=
/pre>

v=3D0
o=3Dbob 280744730 28977631 IN IP4 host.=
example.com
s=3D
t=3D0 0
a=3Dgroup:ANAT 1 2
a=3Dgroup:ANAT 3 4
a=3Dgroup:BUNDLE 1 3     // BUNDLE IPv4 audio and video streams
a=3Dgroup:BUNDLE 2 4     // BUNDLE IPv6 audio and video streams.
m=3Daudio 25000 RTP/AVP 0
c=3DIN IP6 2001:DB8::1
a=3D <ICE-encoded additional IPv6 addresses (and ports)>
a=3Dmid:1
m=3Daudio 22334 RTP/AVP 0
c=3DIN IP4 192.0.2.1
a=3D <ICE-encoded additional IPv4 addresses (and ports)>
a=3Dmid:2
m=3Dvideo 25112 RTP/AVP 0
c=3DIN IP6 2001:DB8::1
a=3D <ICE-encoded additional IPv6 addresses (and ports)>
a=3Dmid:3
m=3Dvideo 24544 RTP/AVP 0
c=3DIN IP4 192.0.2.1
a=3D <ICE-encoded additional IPv4 addresses (and ports)>
a=3Dmid:4

Any thoughts if this sounds like the right approach ?
=




Chee=
rs
Suhas
--001a11c25d36b8433304f23a5122-- From martin.thomson@gmail.com Wed Feb 12 11:26: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 513651A0548 for ; Wed, 12 Feb 2014 11:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 eKskj7zTjh0L for ; Wed, 12 Feb 2014 11:26:47 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CD8B21A0647 for ; Wed, 12 Feb 2014 11:26:46 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so7514555wib.0 for ; Wed, 12 Feb 2014 11:26:45 -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=+2Io4eYZmO+nIWUo6gE4irFysf/zDIWIdgI78LS8mCU=; b=NMj9xfNxo0yzeDR5CcedXIf1WaxWmBVpwR4Ak0WE8Ry3iU54MR7K5x5OeUPHHz8rti hyTQ2dZHQm0MbxuJqbBhMn8BquGqw36dLRLlUdfZ+694fNPzXfkbWBhR2WI/fYNmseE/ YUgteJHmlg0NIfiiUUKBD4VNhHqqyLkMzBoLadmtv+TBPWJvn/+UqT3QklK+U65iOZsw HXNYNdIAavYFzqBVoQ/xMmtukcs9HcN36V0yFFTLpPF0jZqc19d1szNFU8M65vL0PeRE 6s2cEDIzyrB2/fyXSlR+IUdTN0kbbbQT1xNlqLMiXbUdBuW+xg+7v8Xhdds+4baa3FBg rV4A== MIME-Version: 1.0 X-Received: by 10.194.89.33 with SMTP id bl1mr2072100wjb.64.1392233205539; Wed, 12 Feb 2014 11:26:45 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 12 Feb 2014 11:26:45 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Feb 2014 11:26:45 -0800 Message-ID: From: Martin Thomson To: Suhas Nandakumar Content-Type: text/plain; charset=UTF-8 Cc: mmusic WG Subject: Re: [MMUSIC] BUNDLE and RFC 4091 ANAT Semantics 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, 12 Feb 2014 19:26:48 -0000 On 12 February 2014 11:09, Suhas Nandakumar wrote: > ANAT semantics Since RFC 4091 is obsolete, is this really that important? From suhasietf@gmail.com Wed Feb 12 11:31: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 676CB1A0631 for ; Wed, 12 Feb 2014 11:31:48 -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 Ar_6lgETqZx4 for ; Wed, 12 Feb 2014 11:31:46 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 77F471A062C for ; Wed, 12 Feb 2014 11:31:46 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t61so6534349wes.28 for ; Wed, 12 Feb 2014 11:31:45 -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=S4ipxmXrXLY7buOPoJEYyGS3tdi/ENIVGTb3Luea1kI=; b=mtXPH6GKwGxC8A/mxeCUzhyit3ma306KE5Mnn5Pc+n3OSu93v8yWy1QUlTR2bpn16l dblO6A9edg87M8+DgD5BahjdHnDNU2OVQP0D+YaMLnOJYE+nEI9YBZxqsnx2DpF980/a R2r+f31dzzgtiGOlHu5Y2YnrzzOQRHbCRixx5R1xiq09QgiGz7sdZe5Jb2p/c57wOe9t RWebh/YdRwz0JJ770sYkbCNN+DeZKijotSU1MggKX4YOX3ro4gDS0+2kzZb7Uz38Ix0g F9i9pnAjyu7lyZxGhQvAZbgwmedgnjhGV5i+Y9VRD7BwDBXseXC7q4fpp9X0UQ/vfgTB NPqw== MIME-Version: 1.0 X-Received: by 10.180.98.71 with SMTP id eg7mr3387056wib.31.1392233505049; Wed, 12 Feb 2014 11:31:45 -0800 (PST) Received: by 10.195.12.134 with HTTP; Wed, 12 Feb 2014 11:31:45 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Feb 2014 11:31:45 -0800 Message-ID: From: Suhas Nandakumar To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d04428070836fc004f23a9fc8 Cc: mmusic WG Subject: Re: [MMUSIC] BUNDLE and RFC 4091 ANAT Semantics 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, 12 Feb 2014 19:31:48 -0000 --f46d04428070836fc004f23a9fc8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 12, 2014 at 11:26 AM, Martin Thomson wrote: > On 12 February 2014 11:09, Suhas Nandakumar wrote: > > ANAT semantics > > Since RFC 4091 is obsolete, is this really that important? > Good point. I feel we should just assign NOT RECOMMENDED in the Mux draft and leave it there. Cheers Suhas --f46d04428070836fc004f23a9fc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 12, 2014 at 11:26 AM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 12 February 2014 11:09, Suhas Nandakumar = <suhasietf@gmail.com> wrot= e:
> ANAT semantics

Since RFC 4091 is obsolete, is this really that important?
=

Good point. I feel we should just assign NOT RECOMMENDE= D in the Mux draft and leave it there.

Cheers
Suhas=A0

--f46d04428070836fc004f23a9fc8-- From magnus.westerlund@ericsson.com Thu Feb 13 01:05:54 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 DE6511A01B6; Thu, 13 Feb 2014 01:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 h8kVPa9nfwdO; Thu, 13 Feb 2014 01:05:51 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 21F071A018B; Thu, 13 Feb 2014 01:05:50 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-43-52fc8aedd2a7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F5.B2.10875.DEA8CF25; Thu, 13 Feb 2014 10:05:49 +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, 13 Feb 2014 10:05:47 +0100 Message-ID: <52FC8AEB.6020906@ericsson.com> Date: Thu, 13 Feb 2014 10:05:47 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti , Jonathan Lennox References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.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+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvje7brj9BBkt3KVl0TGazOHHjNLPF /sXnmS22ThWymLr8MYvF2n/t7A5sHlN+b2T1WLCp1GPJkp9MHm3P7rAHsERx2aSk5mSWpRbp 2yVwZfza08RUsI+rYu2l62wNjNs5uhg5OSQETCTOXP/BBGGLSVy4t56ti5GLQ0jgEKPEvfYm RghnOaNE4+sOsCpeAW2J771P2UFsFgFVifeL5rGC2GwCFhI3fzSygdiiAsESOw/8ZoSoF5Q4 OfMJSxcjB4eIgI/Em02CIDOZBboZJS4e6gGrERawlFgzu40dYtkeJom587eAJTgFAiWmr+pk AmmWEBCX6GkMAgkzC+hJTLnawghhy0s0b53NDGILAd3W0NTBOoFRaBaS1bOQtMxC0rKAkXkV I3tuYmZOernhJkZgiB/c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwKgWut7jq/6/Ds9u8WglvueC9xKPiIvlralaVS3ALV+qbCfQdEV126HjYh+Mb/a+ OrtqnsXp/MvNy31P2m4ti+jlu/oj+1dV172MrQpLbLPfTngVHtN1RSbSU1Y8x511Ov/Knp33 Izd4FC7X2Hgr21PoH+vWL1zP5OW47rZtP9UYrPyvWWjffyWW4oxEQy3mouJEALB1gMY/AgAA Cc: Cullen Jennings , Harald Alvestrand , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 13 Feb 2014 09:05:55 -0000 On 2014-02-04 01:05, Justin Uberti wrote: > > Agree that msid should map m-line to MST, but it would seem recv-msid > could map RTP flow to m=line as well as indicate whether the receiver is > in fact interested in receiving the MST associated with said m= line. > Note that recv-msid doesn't specify an actual MSID; its purpose is to > indicate that the receiver wants to receive data from the remote side's > MST, and provide a mechanism for the sender to mark the data > accordingly. (Which ends up seeming a lot like appid.) > A question here, what are you really trying to reject? Is it the MST, a particular RTP Stream (Id by SSRC) or the usage of this media description (m= block) in a particular direction (i.e. SDP internal)? I think the solution differs quite a lot depending on what you really try to accomplish. 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 2mkristensen@gmail.com Thu Feb 13 05:31:58 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 0D38D1A01CF for ; Thu, 13 Feb 2014 05:31:58 -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 Zw2fKWwLjRcJ for ; Thu, 13 Feb 2014 05:31:55 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 05C9A1A0056 for ; Thu, 13 Feb 2014 05:31:54 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id e9so18096065qcy.1 for ; Thu, 13 Feb 2014 05:31:53 -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=PPiTbtsbyzCFYoi+q5fZj9WIjT/6GVYxA/DSxjbPS8Q=; b=gVkvIpzMbDVdHMvbzSsaQc+hRiHt6Ot/vsfqmAjOZDk0VuytTG48RDqGl2X+KeaQ+C zaU0bhC9x/zgioTQpIXbwzOh9X/QMEGsHFpZb9boyIoqEHDOl4Csn6FmMZai4RsuSC7G 4f+eWIPVjHPSnI7LD0sX42NhCd7rcdummyopvzYFrwMzYsvRQa/QCYitww3sg/i0vZt/ FzDrIbPG4rMxQc1XT2ouv+23dF/CxJsduiZqiATHOVQFusufECH2jLBYdJmM/7LWYULE JHvv/gy7R2Q5ykaptcP+EofZtCgvXl3siJvOk/Fx+JYpyE4pVpZNUHfZm1iEShNrhdsm 18eQ== MIME-Version: 1.0 X-Received: by 10.140.108.116 with SMTP id i107mr2347103qgf.80.1392298313678; Thu, 13 Feb 2014 05:31:53 -0800 (PST) Received: by 10.229.2.69 with HTTP; Thu, 13 Feb 2014 05:31:53 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Feb 2014 14:31:53 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a113aadc268837b04f249b60d 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: Thu, 13 Feb 2014 13:31:58 -0000 --001a113aadc268837b04f249b60d Content-Type: text/plain; charset=ISO-8859-1 On 14 January 2014 03:05, Charles Eckel (eckelcu) wrote: > I am afraid Ali is right. Let's take the SHOULDs 1 by 1 and see how to > deal with them. > I assume Ali and Charles are right, so we better brush up the mandatory language before issuing the next (and hopefully last) version of the draft. > 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". > Yes, but we have seen an implementation (old, but might be out in the wild) using a digit and not *. So, I propose we use the SHOULD here still, but introduce the text proposed by Mary Barnes in the accompanying BFCPbis WG PROTO review thread: "The fmt (format) list is not applicable to BFCP. The fmt list of 'm' lines in the case of any proto field value related to BFCP SHOULD contain a single "*" character. If the the fmt list contains any other value it is ignored." > 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. > I agree, since the default behaviour is specified. > 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". > Yes, I agree that the floor control server must include these identificators. > 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". > Yes, I agree here as well. > 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. > True, and as proposed in the accompanying BFCPbis WG PROTO review thread merging in this requirement for implementations of the upcoming RFCXXX of this draft. The paragraph will then read: "Endpoints that use the offer/answer model to establish BFCP connections SHOULD support the 'bfcpver' attribute. A floor control server acting as an offerer or as an answerer SHOULD include this attribute in its session descriptions. However, endpoints that support RFCXXXX, and not only the RFC 4583 subset, are REQUIRED to support and, when acting as a floor control server to use the 'bfcpver' attribute. [...]" > 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. > Yes, will be done. > 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. > This might be considered being part of application logic/policy, but I can't see a reason for not trying to reestablish the connection here and now. Anyway, I'll leave these two as "SHOULD". Shout out if you disagree. > 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. To actually get the security/authentication from TLS and establish a secure channel, the fingerprint attribute must be used of course. So, I'm fine with mandating the use of it. Will change to "MUST". Thanks to Charles for going through all the "SHOULDs" in the draft an discuss them, the fixes will be in the upcoming version of the draft to be issued very very soon. In addition Ali's original review issue #1 is fixed, but #2 is considered taken care of in the existing text as described earlier. -- Tom --001a113aadc268837b04f249b60d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 14 January 2014 03:05, Charles Eckel (eckelcu) <eckelc= u@cisco.com> wrote:
I am afraid Ali is right. Let's take the SHOULDs 1 by = 1 and see how to
deal with them.

I assume Ali and = Charles are right, so we better brush up the mandatory language before issu= ing the next (and hopefully last) version of the draft.
=A0
1) From section 3:
"The fmt (format) list is ignored for BFCP. =A0The fmt list of BFCP &#= 39;m'
The fmt (format) list is ignored for BFCP. =A0The fmt list of BFCP 'm&#= 39;
=A0 =A0 =A0 =A0 =A0lines SHOULD contain a single "*" character.&q= uot;


This is inherited from RFC 4583. I see no reason to not use '*'. Un= less
someone can identify one, I suggest changing to "MUST".

Yes, but we have seen an implementation (o= ld, but might be out in the wild) using a digit and not *. So, I propose we= use the SHOULD here still, but introduce the text proposed by Mary Barnes = in the accompanying BFCPbis WG PROTO review thread:

=A0 "The fmt (format) list is not= applicable to BFCP. The fmt list of 'm'
=A0 =A0lines in = the case of any proto field value related to BFCP SHOULD
=A0 =A0c= ontain a single "*" character. If the the fmt list contains any o= ther
=A0 =A0value it is ignored."
=A0
2) From section 4:
"Endpoints that use the offer/answer model to establish BFCP
=A0 =A0connections MUST support the 'floorctrl' attribute. =A0A flo= or control
=A0 =A0server acting as an offerer or as an answerer SHOULD include this =A0 =A0attribute in its session descriptions.
=A0 =A0If the 'floorctrl' attribute is not used in an offer/answer = exchange,
=A0 =A0by default the offerer and the answerer will act as a floor control<= br> =A0 =A0client and as a floor control server, respectively."

I think this is okay as is.

I agr= ee, since the default behaviour is specified.
=A0
3) From section 5:
"Endpoints that use the offer/answer model to establish BFCP
=A0 =A0connections MUST support the 'confid' and the 'userid= 9; attributes. =A0A
=A0 =A0floor control server acting as an offerer or as an answerer SHOULD =A0 =A0include 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".

Yes, I agree that the floor control server must = include these identificators.
=A0
4) From section 6:
"Endpoints that use the offer/answer model to establish BFCP
=A0 =A0connections MUST support the 'floorid' and the 'label= 9; attributes. =A0A
=A0 =A0floor control server acting as an offerer or as an answerer SHOULD =A0 =A0include 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".
=

Yes, I agree here as well.
=A0
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.

True, and as = proposed in the accompanying BFCPbis WG PROTO review thread merging in this= requirement for implementations of the upcoming RFCXXX of this draft. The = paragraph will then read:

=A0 "Endpoints that use the offer/answ= er model to establish BFCP
=A0 =A0connections SHOULD suppor= t the 'bfcpver' attribute. A floor control
=A0 =A0s= erver acting as an offerer or as an answerer SHOULD include
=A0 =A0this attribute in its session descriptions. =A0 However, = endpoints that
=A0 =A0support RFCXXXX, and not only the RFC= 4583 subset, are
=A0 =A0REQUIRED to support and, when acti= ng as a floor control server
=A0 =A0to use the 'bfcpver' attribute. =A0[...]"
=A0
The only should for which this is not the case is the following:

"Tokens representing versions SHOULD be
=A0 =A0integers matching the "Version" field that would be presen= ted in the
=A0 =A0BFCP COMMON-HEADER [8
<http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4= 583bis-08#ref-8>]."

I think this can be changed to "MUST" for all cases.

Yes, will be done.
=A0
6) From section 8.1:
"When the existing TCP connection is reset following the rules in [8 <http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4= 583bis-08#ref-8>],
=A0 =A0the client SHOULD generate an offer towards the floor control server=
=A0 =A0in order to reestablish the connection. =A0If a TCP connection canno= t
=A0 =A0deliver a BFCP message and times out, the entity that attempted to =A0 =A0send the message (i.e., the one that detected the TCP timeout) SHOUL= D
=A0 =A0generate an offer in order to reestablish the TCP connection."<= br>
I am not sure about these. I think they could be changed to "MUST"= ;.
Hopefully others can chime in.

Th= is might be considered being part of application logic/policy, but I can= 9;t see a reason for not trying to reestablish the connection here and now.= Anyway, I'll leave these two as "SHOULD". Shout out if you d= isagree.
=A0
7) Section 9 reads as follows:
"Endpoints that use the offer/
=A0 =A0answer model to establish BFCP connections MUST support the
=A0 =A0'fingerprint' attribute and SHOULD include it in their sessi= on
=A0 =A0descriptions."

I think this can be changed to "MUST"; however, I would appreciat= e
additional opinions on this one as well.=A0

To actually get the security/authentication from TLS and establish a= secure channel, the fingerprint attribute must be used of course. So, I= 9;m fine with mandating the use of it. Will change to "MUST".

=A0Thanks to Charles for going through all = the "SHOULDs" in the draft an discuss them, the fixes will be in = the upcoming version of the draft to be issued very very soon.

In addition Ali's original review issue #1 is fixe= d, but #2 is considered taken care of in the existing text as described ear= lier.

-- Tom=A0
--001a113aadc268837b04f249b60d-- From tomkrist@cisco.com Thu Feb 13 06:15: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 4CD321A0273 for ; Thu, 13 Feb 2014 06:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.548, 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 UeiuqySqChD9 for ; Thu, 13 Feb 2014 06:15:02 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 680C41A02B5 for ; Thu, 13 Feb 2014 06:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4508; q=dns/txt; s=iport; t=1392300883; x=1393510483; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=5wi+cRj1kkAzRgEHojJxC6nE85Pwql2l83WrtFEAdEI=; b=k77GL80FelOczB50M5rjJHcGE6nQXq6AZ29C4gaHhuhxmSX8/0U95t4A cHFXejvDeXVx/w9T6nVYoO1nDTaKFJjeLpfwtWeUPusmOqb/8ePinhZ5a o6LMgTSdFEd7AAfnfaQ+FO5Dcrao1GIdTUXH0EF+8pw8vO1mWjoTvAzm2 M=; X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208,217";a="5010053" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 13 Feb 2014 14:14:41 +0000 Received: from [10.61.91.92] (ams3-vpn-dhcp7005.cisco.com [10.61.91.92]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DEEfgf013558; Thu, 13 Feb 2014 14:14:41 GMT Message-ID: <52FCD350.90104@cisco.com> Date: Thu, 13 Feb 2014 15:14:40 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Tom Kristensen <2mkristensen@gmail.com> References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010708080104010105000003" Cc: "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: Thu, 13 Feb 2014 14:15:04 -0000 This is a multi-part message in MIME format. --------------010708080104010105000003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/13/2014 02:31 PM, Tom Kristensen wrote: > On 14 January 2014 03:05, Charles Eckel (eckelcu) > wrote: > > I am afraid Ali is right. Let's take the SHOULDs 1 by 1 and see how to > deal with them. > [...] > 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. > > > This might be considered being part of application logic/policy, but I > can't see a reason for not trying to reestablish the connection here > and now. Anyway, I'll leave these two as "SHOULD". Shout out if you > disagree. I'm disagreeing with the previous version of me. This will be changed to "MUSTs" for the two cases, I cannot really see a reason for keeping the "SHOULDs". -- Tom --------------010708080104010105000003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/13/2014 02:31 PM, Tom Kristensen wrote:
On 14 January 2014 03:05, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:
I am afraid Ali is right. Let's take the SHOULDs 1 by 1 and see how to
deal with them.

[...]
 
6) >From section 8.1:
"When the existing TCP connection is reset following the rules in [8
<http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-08#ref-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.

This might be considered being part of application logic/policy, but I can't see a reason for not trying to reestablish the connection here and now. Anyway, I'll leave these two as "SHOULD". Shout out if you disagree.

I'm disagreeing with the previous version of me. This will be changed to "MUSTs" for the two cases, I cannot really see a reason for keeping the "SHOULDs".

-- Tom

<snip>
--------------010708080104010105000003-- From internet-drafts@ietf.org Thu Feb 13 06:20: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 342CF1A0281; Thu, 13 Feb 2014 06:20:42 -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 98FdKwkEzO2s; Thu, 13 Feb 2014 06:20:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 196501A0237; Thu, 13 Feb 2014 06:20:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213142037.9494.98174.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 06:20:37 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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, 13 Feb 2014 14:20:43 -0000 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 : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) Authors : Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13 Abstract: SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for SDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-06 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 nobody Thu Feb 13 10:09: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 053181A03A4 for ; Thu, 13 Feb 2014 10:09:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 IJZbV8CWH6ap for ; Thu, 13 Feb 2014 10:09:31 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0283D1A03AE for ; Thu, 13 Feb 2014 10:09:30 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/13/2014 1:09:27 PM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-72/SG:2 2/13/2014 1:08:49 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.884305 p=-0.972988 Source White X-Signature-Violations: 0-0-0-4398-c X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/13/2014 1:09:17 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 72143725 for mmusic@ietf.org; Thu, 13 Feb 2014 13:09:27 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Thu, 13 Feb 2014 12:09:26 -0600 From: Jonathan Lennox To: mmusic Thread-Topic: MSID and AppID: solving different problems Thread-Index: AQHPKOa6Fs8ExCOTx0uariEDbNRUNA== Date: Thu, 13 Feb 2014 18:09:25 +0000 Message-ID: <10C8325A-F234-4034-BD05-D0D24C0B562B@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.116.130.167] Content-Type: text/plain; charset="us-ascii" Content-ID: <71C42B273CFD0647BFB8A430AA3E7526@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Wf5bcVLpM2do_0cAK4EtvBZwbqQ Subject: [MMUSIC] MSID and AppID: solving different problems 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, 13 Feb 2014 18:09:33 -0000 The chairs asked that the authors of the MSID and AppID drafts discuss the = relationship between the two documents. My personal opinion (which I mentioned in the RTCWeb Rejecting MediaStreamT= racks thread, but folks might not have seen) is that they're solving differ= ent problems, and so are non-conflicting. MSID provides an identifier for SDP m=3D lines. Its primary use case is pr= oviding a Javascript-level handle in WebRTC. AppID -- which needs a better name, suggestions welcome -- provides an indi= rection label for identifying individual RTP packet streams in SDP, in scen= arios where the SSRC is unavailable to the signaling. The scenarios we've identified so far for AppID where an SSRC might be unav= ailable are: "early media" race conditions where media outraces an SDP answ= er; SSRC collisions; applications which wish to dynamically switch which SS= RC is fulfilling a higher-level application role; and architectures where t= he signaling stack can't control/doesn't have visibility onto the SSRC sele= ction. AppID should be applicable to anything using BUNDLE, I think, and certainly= anything using it with a vaguely Unified-style semantic. (I think it woul= d apply to a "Plan B"-style semantic, as well, which I know some people are= still advocating for some non-WebRTC contexts; however, I'm not positive a= ll the syntax necessary for that is currently complete.) The difference between AppID and MSID should be most clear in scenarios whe= re an m=3D line group has more than one packet stream (my canonical example= is a primary stream and a retransmission stream). In this case, the m=3D = line group has one msid attribute, but multiple appid attributes.= From nobody Thu Feb 13 10:09: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 63FD51A03AB for ; Thu, 13 Feb 2014 10:09:42 -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 Yxnz5qFwYg4a for ; Thu, 13 Feb 2014 10:09:40 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EE2DC1A03B3 for ; Thu, 13 Feb 2014 10:09:39 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-5d-52fd0a61c0a6 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 15.4F.10875.16A0DF25; Thu, 13 Feb 2014 19:09:38 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.347.0; Thu, 13 Feb 2014 19:09:37 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id ACFD1110296; Thu, 13 Feb 2014 20:09:37 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2F58D56902; Thu, 13 Feb 2014 20:09:33 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D48F453DDD; Thu, 13 Feb 2014 20:09:32 +0200 (EET) Message-ID: <52FD0A60.2040909@ericsson.com> Date: Thu, 13 Feb 2014 20:09:36 +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.3.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> <52EA38C9.4070003@ericsson.com> <37A6AA83-867F-4DD1-A79D-081ECFA23B22@cisco.com> In-Reply-To: <37A6AA83-867F-4DD1-A79D-081ECFA23B22@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+JvjW4S198gg3eT+CymLn/MYvH++koW ixO7tzE6MHtM+b2R1WPJkp9MAUxRXDYpqTmZZalF+nYJXBk/d9QWLBetOPvrFFsD40n+LkZO DgkBE4mru/6wQthiEhfurWfrYuTiEBI4xChxdOtcFpCEkMAGRokpk2Ih7D2MEq/WlUEUrWWU 2DThICuEs5xR4tfTiewgVbwC2hJPT8xmBLFZBFQlvuzYBmazCThK3H74EmydqECyxKdFnYwQ 9YISJ2c+AdsmImAs0XzkKNgcZoEgiUebLzCD2MIC8RLdD0DmgCz7ySSxd/k1sASngK1E294N QHdzADXYSzzYWgbRKy/RvHU2M8RrahJXz21ihvhAVeLqv1eMExhFZyFZPQuhexaS7gWMzKsY 2XMTM3PSyw03MQKD/+CW37o7GE+dEznEKM3BoiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGxpiFmZF1q78bXZWPapG5unhKrPxx1XqbL6ERx5N1f3wJsj690pyPN2OV/cy2WNXS aVGf6vi5Jy/ZYNvENnPdtunSlrJ7pypzqdlnnheyWn5Pz0z01bbFHdcytO+2pbVtnHRLxkD9 +qsliRc2qzzQnZwkI2zJ8LG3P/57QtrD3qR/8k/zRfnmK7EUZyQaajEXFScCAE+aDOtMAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jUBvdVZdCkK26comKIm_sAyRxkg 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, 13 Feb 2014 18:09:42 -0000 On 31/01/14 15:44, Pal Martinsen (palmarti) wrote: > On 30 Jan 2014, at 12:34 pm, Ari Keränen wrote: >> On 28/01/14 15:49, Pal Martinsen (palmarti) wrote: [...] >> 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. >> > > As I do believe in running code, I wrote a simple implementation of the algorithm described below. That's very nice, but unfortunately that didn't compile on my Mac so I couldn't give it a try. >> 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. >> > 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-> > > > The local preference can be calculated by the given formula: > > > local_preference = 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. > Could you give an example how this algorithm and some priority values, e.g., from your program, result in the candidate pairs and order of checks? Especially the pairing part with respect to different types of candidates and IP families is where I'm afraid things may go wrong. Cheers, Ari From nobody Thu Feb 13 10:12: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 A355C1A03BF for ; Thu, 13 Feb 2014 10:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.548, 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 XcbEjJ_uP7eI for ; Thu, 13 Feb 2014 10:12:15 -0800 (PST) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA241A03C0 for ; Thu, 13 Feb 2014 10:12:08 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id m1so13127212oag.34 for ; Thu, 13 Feb 2014 10:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3782Tv+lTZwyjmw5vHI2Z/xje3sZropwl1cXflCjRWY=; b=VVPORjTZSMvWS78lea6HrcUM0XM1QhtT6JIkOmjqu6id7ehvjtDnfGrq6f4236AGim oqU/zl8zLW+q/xiP4S/yQsGgVrV7y2f18V7a7Wn6WizGtnNtJS9iXmDWqKDx5EqeNkj1 RqXkCb3+HEzdopvSwX2N70loUfmPH+fSZGRsarx/+E+vb5jlDccOMWpshq44p17V6ln/ 7wKr1+RkIDWKvTJw9V3u/sOncRWWn+1wEXZVM/Bbof1ApyvRLtpVQS/ILtbgc33t70Ti PT/HM+q7uVGuchtLLQGkK7QKW3JSnrFhw9w+x9kTbWDwtDkLY/eExdomK45srmlquzLu D0OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3782Tv+lTZwyjmw5vHI2Z/xje3sZropwl1cXflCjRWY=; b=nKWQHekRRC8ZTkpuA9iD/uJniTYXpBrtHBtGv84PecIkKNE0fgBcHV0xzM1uwhYHce aMfAI0tYDpMWz0Pqe7yKuwPGzooq/v6bjY4jLXis3d6iJOShaZpwwmex0e75Ep1o2rrS OzlhOx7+Via/4/UA/8A5b6O763bawdCLYBafby4fi7Iop8xnRyv6jbgwOtIFfR9K9YZY W4npsEBkHz2c6/9ZIWttAibEU7jaEfq2dY+pVE2zjaZ63WWlYTKtx84OrnUtG5ZQPOSG cv/QyLpQRz0PmzT+emlC/WzH0YiNXT1Ep9beBpTLBeMkuDuE7yxWBGkhbJPXZmJvzC9y YYyQ== X-Gm-Message-State: ALoCoQmir2XW3bSeDbN8vKPnlvTbkF69zPCilRyKd7AjXPyqad7A/BG/5mEGRFwYdi3jAHtN6GgRC1G+rSE74Zl5wepVo6uDEJrSG+6oJIBfVYBtrPXxAWgvHatYpSuMC69Bmm7SCU/KZZ8cRTlrZ7wCSXPgt/IzSgRXkGSCjx/VE7CXNPkckEhq0yK+7gYr08LimxoCYdXD X-Received: by 10.60.84.143 with SMTP id z15mr2377147oey.27.1392315127491; Thu, 13 Feb 2014 10:12:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.38.137 with HTTP; Thu, 13 Feb 2014 10:11:47 -0800 (PST) In-Reply-To: <52FC8AEB.6020906@ericsson.com> References: <9E51C939-CCFE-4EA6-83BF-9B871D64CDA0@vidyo.com> <52FC8AEB.6020906@ericsson.com> From: Harald Alvestrand Date: Thu, 13 Feb 2014 19:11:47 +0100 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=089e0117696f994d5b04f24da06a Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/taYXDR1SkSyN5VmEs6H3FzuKEsQ Cc: Cullen Jennings , Jonathan Lennox , "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP 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, 13 Feb 2014 18:12:17 -0000 --089e0117696f994d5b04f24da06a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What's being asked for is a way to control MediaStreamTracks. The RTP streams are only incidentally impacted. I'll put a strawman proposal into -msid- today. On Thu, Feb 13, 2014 at 10:05 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-02-04 01:05, Justin Uberti wrote: > > > > > Agree that msid should map m-line to MST, but it would seem recv-msid > > could map RTP flow to m=3Dline as well as indicate whether the receiver= is > > in fact interested in receiving the MST associated with said m=3D line. > > Note that recv-msid doesn't specify an actual MSID; its purpose is to > > indicate that the receiver wants to receive data from the remote side's > > MST, and provide a mechanism for the sender to mark the data > > accordingly. (Which ends up seeming a lot like appid.) > > > > A question here, what are you really trying to reject? > > Is it the MST, a particular RTP Stream (Id by SSRC) or the usage of this > media description (m=3D block) in a particular direction (i.e. SDP > internal)? > > I think the solution differs quite a lot depending on what you really > try to accomplish. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --089e0117696f994d5b04f24da06a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What's being asked for is a way to control MediaStream= Tracks.

The RTP streams are only incidentally impacted.<= /div>

I'll put a strawman proposal into -msid- today= .


On Thu,= Feb 13, 2014 at 10:05 AM, Magnus Westerlund <magnus.westerl= und@ericsson.com> wrote:
On 2014-02-04 01:05, Justin = Uberti wrote:

>
> Agree that msid should map m-line to MST, but it would seem recv-msid<= br> > could map RTP flow to m=3Dline as well as indicate whether the receive= r is
> in fact interested in receiving the MST associated with said m=3D line= .
> Note that recv-msid doesn't specify an actual MSID; its purpose is= to
> indicate that the receiver wants to receive data from the remote side&= #39;s
> MST, and provide a mechanism for the sender to mark the data
> accordingly. (Which ends up seeming a lot like appid.)
>

A question here, what are you really trying to reject?

Is it the MST, a particular RTP Stream (Id by SSRC) or the usage of this media description (m=3D block) =C2=A0in a particular direction (i.e. SDP in= ternal)?

I think the solution differs quite a lot depending on what you really
try to accomplish.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Phone= =C2=A0+46 10 7= 148287
F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | Mobile +4= 6 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--089e0117696f994d5b04f24da06a-- From nobody Thu Feb 13 12:57:41 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 6226A1A040C for ; Thu, 13 Feb 2014 12:57:40 -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 0MYFy8jm5jMD for ; Thu, 13 Feb 2014 12:57:33 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C004B1A0283 for ; Thu, 13 Feb 2014 12:57:32 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-0b-52fd31bac4da Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EC.FB.23809.AB13DF25; Thu, 13 Feb 2014 21:57:30 +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, 13 Feb 2014 21:57:30 +0100 From: Christer Holmberg To: mmusic Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments Thread-Index: Ac8o/jG9d4h50B84TBauKcEd8AH/LQ== Date: Thu, 13 Feb 2014 20:57:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D17183EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje4uw79BBls2GVpMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGS+ae1kKNi5hrNg5p4m9gfFlF2MXIweHhICJxOLZal2MnECm mMSFe+vZuhi5OIQEDjFKfFq+gBnCWcwosXvhElaQBjYBC4nuf9ogDSICMhJ7N21mBrGFBZIl 5hx8wwoRT5E4frqRGcLWk9h68i0jiM0ioCqx+vYyJhCbV8BXYvmLP2A2I9Di76fWgNnMAuIS Hw5eZ4Y4SEBiyZ7zULaoxMvH/1ghbCWJxiVPWCHq8yVeTZzNBjFTUOLkzCcsExiFZiEZNQtJ 2SwkZRBxPYkbU6ewQdjaEssWvoaq15WY8e8QC7L4Akb2VYzsuYmZOenlRpsYgYF/cMtv1R2M d86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjxqK76QsPyk1Z9V4o 6rf85o9MEty1tZf2zX141+pFllHu+yOy4Q23LRql5p3hn/n+e3HDT4u6/JtXNBeWFEZkzdU1 +ZTKOu+UCqvdi45lDCE//n23y/DJX/jh+nHLnZvZD5tY/Nprdr185ZIov6N9ITX1kRzu/993 uvDJpE+vWWiWKOMblB+kxFKckWioxVxUnAgATc9E0EoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ChAPKtNvaOb3eV6fWaUWh5pY_VE Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 13 Feb 2014 20:57:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D17183EESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I gave some comments off-line to Salvatore, which have been addressed in th= e new version. Some additional comments. I do realize some are pure editorial, but rather = to write then down in some notes I put them directly into the e-mail :) Section 1: ------------ Q1 (EDITORIAL): The text says: "Since no-one so far has implemented SCTP over TLS, due to some serious limitations described in [RFC6083], this document does not make use of TLS over SCTP as described in RFC3436 [RFC3436]." I suggest to simply say something like: "As described in [RFC6083], there are limitations associated with implem= enting SCTP over TLS. For that reason, SCTP over TLS is outside the scope of thi= s document." Q2 (EDITORIAL): The text says: "Additionally, this document specifies the use of the 'setup' and 'connection' SDP attributes to establish SCTP associations. These attributes were defined in RFC4145 [RFC4145] for TCP. This document discusses their use with SCTP." I suggest to remove the last sentence, as it only repeats what is said in t= he first sentence. Section 3: ------------ Q3 (EDITORIAL): The text says: "This document defines three new values for the 'proto' field: 'SCTP', '= SCTP/DTLS' and 'DTLS/SCTP'." I would suggest to say: "This document defines three new protocol identifier values for the 'pro= to' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." ...because, you use "protocol identifier" terminology later. Q4 (CLARIFICATION): The text says: "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST further qualify the application-layer protocol using an fmt identifier." I do understand what you are trying to say, but I think the "qualify" word = is a little confusing. Maybe something like: "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST further include an fmt value that identifies the application-layer proto= col carried on top of the SCTP association." Section 4.1: -------------- Q5 (TECHNICAL): The text says: "For the payload type assignments the "a=3Dsctpmap:" attribute (see Section 5.1) SHOULD be used to map from a port number to a media encoding name that identifies the payload format transported by the association or the actual application protocol running on top of it." It is very difficult for me to parse this, and figure out the semantics of = the sctpmap attribute. First, what do you mean by "media encoding name"? Second, when you talk about "application protocol", I assume you refer to t= he SCTP protocol? Third, the text say SHOULD. When is it ok to not use the sctpmap attribute? Section 5: ------------ Q6 (EDITORIAL): I suggest to rename section 5 to "SDP sctpmap attribute", rename section 5.= 1 to "General", and add a new section 5.2 named "ABNF". Q7 (TECHNICAL): The text says: "The sctpmap MUST include the app parameter indicating the application running on top of the association." This is fine if the sctpmap attribute maps to an application. But, what if = the sctpmap attribute maps to a "media encoding" or "payload"? Q8 (EDITORIAL): The text says: "The sctpmap line should also contain the max-message-size parameter indicating the maximum message size, in bytes, the endpoint is willing to accept." I suggest to replace "accept" with "receive on the associated SCTP associat= ion". Q9 (EDITORIAL): The text says: "The peer should assume that larger message will be rejected by the endpoint, though it is up to the endpoint decide the appropriate behaviour." I suggest to either remove this paragraph, OR replace it with a sentence sa= ying that a peer must/should not send messages bigger than the indicated ma= x value. Q10 (CLARIFICATION): The text says: "If the parameter is not present, the implementation should provide a default, with a suggested value of 64K." I don't understand "suggested". If the default value is 64K the text should= specify (rather than suggest) that. The same comment applies to the stream parameter, described later in the se= ction. Q11 (CLARIFICATION): The text says: "It may also provide the stream parameter to specify the initial number of incoming streams to be supported by each side of the association." First, to be consistent with previous text, I suggest to replace "It may al= so provide" with "The sctpmap line may also contain" Second, I don't understand "incoming streams to be supported by each side o= f the association". Doesn't each peer indicate the number of streams it is = willing to receive? Then, we can always recommend that the peer indicates t= he same number of streams, if possible. Q12 (EDITORIAL): The text that follows the ABNF should be put into a separate "SDP Offer/Ans= wer Procedures" section. Section 7: ------------ Q13 (EDITORIAL): Please don't talk about re-INVITEs, or other SIP messages. Simply talk abou= t offers and answers. Q14 (EDITORIAL): The text says: "It is worth to underline that when using SCTP on top of DTLS,.." To have consistent terminology, please say "SCTP over DTLS". That's all for now! :) Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta internet-= drafts@ietf.org L=E4hetetty: 13. helmikuuta 2014 16:21 Vastaanottaja: i-d-announce@ietf.org Kopio: mmusic@ietf.org Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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 : Stream Control Transmission Protocol (SCTP)-Based= Media Transport in the Session Description Protocol (SDP) Authors : Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13 Abstract: SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for SDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-06 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 --_000_7594FB04B1934943A5C02806D1A2204B1D17183EESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I gave some comments off-line to Salvatore, which have been addressed = in the new version.
 
Some additional comments. I do realize some are pure editorial, but ra= ther to write then down in some notes I put them directly into the e-mail <= font face=3D"Wingdings">J
 
 
Section 1:
------------
 
Q1 (EDITORIAL):
 
The text says:
 
   "Since
   no-one so far has implemented SCTP over TLS, due to some = serious
   limitations described in [RFC6083], this document does no= t make use
   of TLS over SCTP as described in RFC3436 [RFC3436]."=
 
I suggest to simply say something like:
 
   "As described in [RFC6083], there are limitations as= sociated with implementing
  SCTP over TLS. For that reason, SCTP over TLS is outside the sc= ope of this document."
 
 
Q2 (EDITORIAL):
 
The text says:
 
  "Additionally, this document specifies the use of the 'set= up' and
   'connection' SDP attributes to establish SCTP association= s.  These
   attributes were defined in RFC4145 [RFC4145] for TCP.&nbs= p; This document
   discusses their use with SCTP."
 
I suggest to remove the last sentence, as it only repeats what is said= in the first sentence.
 
 
Section 3:
------------
 
Q3 (EDITORIAL):
 
The text says:
 
   “This document defines three new values for the 'pr= oto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'.”
 
I would suggest to say:
 
   “This document defines three new protocol identi= fier values for the 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'.= ”
 
…because, you use “protocol identifier” terminology = later.
 
 
Q4 (CLARIFICATION):
 
The text says:
 
   “An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' o= r 'DTLS/SCTP' MUST
   further qualify the application-layer protocol using an f= mt
   identifier.”
 
I do understand what you are trying to say, but I think the “qua= lify” word is a little confusing.
 
Maybe something like:
 
   “An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' o= r 'DTLS/SCTP' MUST
   further include an fmt value that identifies the applicat= ion-layer protocol
   carried on top of the SCTP association.”
 
 
Section 4.1:
--------------
 
Q5 (TECHNICAL):
 
The text says:
 
   “For the payload type assignments the "a=3Dsct= pmap:"
   attribute (see Section 5.1) SHOULD be used to map from a = port number
   to a media encoding name that identifies the payload form= at
   transported by the association or the actual application = protocol
   running on top of it.”
 
It is very difficult for me to parse this, and figure out the semantic= s of the sctpmap attribute.
 
First, what do you mean by “media encoding name”?
 
Second, when you talk about “application protocol”, I assu= me you refer to the SCTP protocol?
 
Third, the text say SHOULD. When is it ok to not use the sctpmap attri= bute?
 
 
Section 5:
------------
 
Q6 (EDITORIAL):
 
I suggest to rename section 5 to “SDP sctpmap attribute”, = rename section 5.1 to “General”, and add a new section 5.2 name= d “ABNF”.
 
 
Q7 (TECHNICAL):
 
The text says:
 
   “The sctpmap MUST include the app parameter indicat= ing the application
   running on top of the association.”
 
This is fine if the sctpmap attribute maps to an application. But, wha= t if the sctpmap attribute maps to a “media encoding” or “= ;payload”?
 
 
Q8 (EDITORIAL):
 
The text says:
 
   “The sctpmap line should also contain the max-messa= ge-size parameter
   indicating the maximum message size, in bytes, the endpoi= nt is
   willing to accept.”
 
I suggest to replace “accept” with “receive on the a= ssociated SCTP association”.
 
 
Q9 (EDITORIAL):
 
The text says:
 
      “The peer should assume that larg= er message will be rejected by the
      endpoint, though it is up to the endpoi= nt decide the appropriate
      behaviour.”
 
I suggest to either remove this paragraph, OR replace it with a senten= ce saying that a peer must/should not send messages bigger than the indicat= ed max value.
 
 
Q10 (CLARIFICATION):
 
The text says:
 
      “If the parameter is not present,= the implementation should provide
      a default, with a suggested value of 64= K.”
 
I don’t understand “suggested”. If the default value= is 64K the text should specify (rather than suggest) that.
 
The same comment applies to the stream parameter, described later in t= he section.
 
 
Q11 (CLARIFICATION):
 
The text says:
 
   “It may also provide the stream parameter to specif= y the initial
   number of incoming streams to be supported by each side o= f the
   association.”
 
First, to be consistent with previous text, I suggest to replace ̶= 0;It may also provide” with “The sctpmap line may also contain&= #8221;
 
Second, I don’t understand “incoming streams to be support= ed by each side of the association”. Doesn’t each peer indicate= the number of streams it is willing to receive? Then, we can always recomm= end that the peer indicates the same number of streams, if possible.
 
 
Q12 (EDITORIAL):
 
The text that follows the ABNF should be put into a separate “SD= P Offer/Answer Procedures” section.
 
 
Section 7:
------------
 
Q13 (EDITORIAL):
 
Please don’t talk about re-INVITEs, or other SIP messages. Simpl= y talk about offers and answers.
 
 
Q14 (EDITORIAL):
 
The text says:
 
   “It is worth to underline that when using SCTP on t= op of DTLS,..”
 
To have consistent terminology, please say “SCTP over DTLS”= ;.
 
 
 
That’s all for now! :)
 
Regards,
 
Christer
 
 
 
 
 
-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: mmusic [mailto:= mmusic-bounces@ietf.org] Puolesta internet-drafts@ietf.org
L=E4hetetty: 13. helmikuuta 2014 16:21
Vastaanottaja: i-d-announce@ietf.org
Kopio: mmusic@ietf.org
Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt
 
 
A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.
 
        Title   &nbs= p;       : Stream Control Transmission Protoc= ol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)
        Authors   &n= bsp;     : Salvatore Loreto
           &nbs= p;            &= nbsp; Gonzalo Camarillo
        Filename   &= nbsp;    : draft-ietf-mmusic-sctp-sdp-06.txt
        Pages   &nbs= p;       : 14
        Date    = ;        : 2014-02-13
 
Abstract:
   SCTP (Stream Control Transmission Protocol) is a transpor= t protocol
   used to establish associations between two endpoints.&nbs= p; This document
   describes how to express media transport over SCTP in SDP= (Session
   Description Protocol).  This document defines the 'S= CTP', 'SCTP/DTLS'
   and 'DTLS/SCTP' protocol identifiers for SDP.
 
 
The IETF datatracker status page for this draft is:
 
There's also a htmlized version available at:
 
A diff from the previous version is available at:
 
 
Please note that it may take a couple of minutes from the time of subm= ission until the htmlized version and diff are available at tools.ietf.org.=
 
Internet-Drafts are also available by anonymous FTP at:
 
_______________________________________________
mmusic mailing list
 
 --_000_7594FB04B1934943A5C02806D1A2204B1D17183EESESSMB209erics_-- From nobody Thu Feb 13 13:18: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 BBDD51A047C for ; Thu, 13 Feb 2014 13:17:52 -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 ZBTY50_LIliA for ; Thu, 13 Feb 2014 13:17:51 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 34FE31A04F1 for ; Thu, 13 Feb 2014 13:17:51 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta15.westchester.pa.mail.comcast.net with comcast id Rt3A1n0070SCNGk5FxHpzF; Thu, 13 Feb 2014 21:17:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id RxHp1n00l3ZTu2S3VxHpmn; Thu, 13 Feb 2014 21:17:49 +0000 Message-ID: <52FD367D.5060908@alum.mit.edu> Date: Thu, 13 Feb 2014 16:17:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392326269; bh=YoMZQOJOaWx9aiKolmpVx7/fkGKwbTEtTxg0Qo/Xz0g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WimRdArIh9AC28F5NiuxvptKHs0jZHIjOViSxCNwuClZmRXjixzWVMNOTTH74LMRZ DG51hAkysALhWvKXjI6y2/i15aYv054QtyQnfs+GbAtkb6WdWBabY0zI7+LefLysP9 6YmDTS35gF16HOf85UVJW4QoRBwjek3JtX145AFTTnV9/D4+INDG/6nFfwibffMwo7 B2jkJhblsbAYIrgkk9r8x2T0s8qpc6YbJpayJSfS89z2UnVqZauo6m939k4OM0isHm GfzRinPYm/73/sDszPss8HcZHZxBik7oU/GL0yFZ84w1tDnyPs4bP+5WuvPqEUAQXy Trnm/e1s2dKYA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Clm3Wu_suGVgzUU5jwKinWln_do Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 13 Feb 2014 21:17:53 -0000 On 2/13/14 3:57 PM, Christer Holmberg wrote: > *Q4 (CLARIFICATION):* > The text says: > “An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST > further qualify the application-layer protocol using an fmt > identifier.” > I do understand what you are trying to say, but I think the “qualify” > word is a little confusing. > Maybe something like: > “An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST > further include an fmt value that identifies the application-layer > protocol > carried on top of the SCTP association.” The clarification would be fine, but both the original and the clarification are misleading. The fmt value does not identify an application-layer protocol - it identifies a port number. This is explained later in section 4.1. I think this paragraph could just be omitted, or else be replaced by a forward reference to section 4.1. Thanks, Paul From nobody Thu Feb 13 13:47: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 7462A1A00A9 for ; Thu, 13 Feb 2014 13:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 EEvUVsk_WKZH for ; Thu, 13 Feb 2014 13:47:51 -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 5323B1A0055 for ; Thu, 13 Feb 2014 13:47:51 -0800 (PST) Received: from localhost ([127.0.0.1]:40314 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE48C-0003sM-E0; Thu, 13 Feb 2014 22:47:40 +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: draft-ietf-mmusic-media-loopback@tools.ietf.org, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Thu, 13 Feb 2014 21:47:40 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/mmusic/trac/ticket/4#comment:2 Message-ID: <078.f51cbd2a33ec2c9d740ee1efd048045b@trac.tools.ietf.org> References: <063.2b351d5217e1a7d41df6a2b9b08298a8@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <063.2b351d5217e1a7d41df6a2b9b08298a8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, 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 Resent-To: hkaplan@acmepacket.com, kaynam.hedayat@exfo.com, nathan@robotics.net, paulej@packetizer.com, vnagarjuna@saperix.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DAL7yl7sdCvPLnZnWzgSmUmTbws Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #4: #4: Multi-stream demultiplexing 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, 13 Feb 2014 21:47:53 -0000 #4: #4: Multi-stream demultiplexing Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mmusic-media- hkaplan@acmepacket.com | loopback@tools.ietf.org Type: defect | Status: closed Priority: minor | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: worksforme | Keywords: -------------------------+------------------------------------------------- Ticket URL: mmusic From nobody Thu Feb 13 13:52:50 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 C4F361A0124 for ; Thu, 13 Feb 2014 13:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 avEGw2eY-yCG for ; Thu, 13 Feb 2014 13:52:47 -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 03E221A00C3 for ; Thu, 13 Feb 2014 13:52:47 -0800 (PST) Received: from localhost ([127.0.0.1]:40458 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE4D2-0003XS-PU; Thu, 13 Feb 2014 22:52:40 +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: Thu, 13 Feb 2014 21:52:40 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/3#comment:2 Message-ID: <078.139fcff31cce90ae938dc72c74cbbc95@trac.tools.ietf.org> References: <063.c6ad2ca26b75b2c4a024f9648d322815@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <063.c6ad2ca26b75b2c4a024f9648d322815@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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/spUgkCq833lFCjvbRyY-HZTIq9A Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #3: Packet size and fragmentation avoidance 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, 13 Feb 2014 21:52:49 -0000 #3: Packet size and fragmentation avoidance Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------------------+------------------------------------ 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: worksforme | Keywords: -------------------------------------+------------------------------------ Ticket URL: mmusic From nobody Thu Feb 13 13:53: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 E426E1A01BE for ; Thu, 13 Feb 2014 13:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 Vc_4mF6ZZjTT for ; Thu, 13 Feb 2014 13:53:39 -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 5E7901A014B for ; Thu, 13 Feb 2014 13:53:39 -0800 (PST) Received: from localhost ([127.0.0.1]:40486 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE4Ds-0001Og-KT; Thu, 13 Feb 2014 22:53:32 +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: draft-ietf-mmusic-media-loopback@tools.ietf.org, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Thu, 13 Feb 2014 21:53:32 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/5#comment:2 Message-ID: <078.31e6312da2dd3dd72d6c026bf85a7179@trac.tools.ietf.org> References: <063.e1029da131b62c6b604af950aed417f9@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <063.e1029da131b62c6b604af950aed417f9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, 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 Resent-To: hkaplan@acmepacket.com, kaynam.hedayat@exfo.com, nathan@robotics.net, paulej@packetizer.com, vnagarjuna@saperix.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/eV7HG-5Yqmn3O424VHBBzKoFTC4 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #5: #5: Marker bit handling 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, 13 Feb 2014 21:53:42 -0000 #5: #5: Marker bit handling Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mmusic-media- hkaplan@acmepacket.com | loopback@tools.ietf.org Type: defect | Status: closed Priority: minor | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: worksforme | Keywords: -------------------------+------------------------------------------------- Ticket URL: mmusic From nobody Thu Feb 13 13:54: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 3AE731A012A for ; Thu, 13 Feb 2014 13:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 BehjNBB8q_c5 for ; Thu, 13 Feb 2014 13:54:32 -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 82CD61A0055 for ; Thu, 13 Feb 2014 13:54:32 -0800 (PST) Received: from localhost ([127.0.0.1]:40516 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE4Em-0000KV-2o; Thu, 13 Feb 2014 22:54:28 +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: draft-ietf-mmusic-media-loopback@tools.ietf.org, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Thu, 13 Feb 2014 21:54:28 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/6#comment:2 Message-ID: <078.74bff1ce927e7adffda4192e3d715fe7@trac.tools.ietf.org> References: <063.51ae082f90ef143996ba440744be8ed8@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <063.51ae082f90ef143996ba440744be8ed8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, 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 Resent-To: hkaplan@acmepacket.com, kaynam.hedayat@exfo.com, nathan@robotics.net, paulej@packetizer.com, vnagarjuna@saperix.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CJ-p0qRGdBnjlnMKAwRMy5JgP7s Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #6: Clock-rate per payload type 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, 13 Feb 2014 21:54:34 -0000 #6: Clock-rate per payload type Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mmusic-media- hkaplan@acmepacket.com | loopback@tools.ietf.org Type: defect | Status: closed Priority: minor | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: worksforme | Keywords: -------------------------+------------------------------------------------- Ticket URL: mmusic From nobody Thu Feb 13 13:55: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 E22681A01FA for ; Thu, 13 Feb 2014 13:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 bkWmUavWmvib for ; Thu, 13 Feb 2014 13:55:15 -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 335D81A0124 for ; Thu, 13 Feb 2014 13:55:15 -0800 (PST) Received: from localhost ([127.0.0.1]:40557 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE4FS-0003ox-LJ; Thu, 13 Feb 2014 22:55:10 +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: draft-ietf-mmusic-media-loopback@tools.ietf.org, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Thu, 13 Feb 2014 21:55:10 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/7#comment:2 Message-ID: <078.14f87b188a913648b2525a21f1e16f5b@trac.tools.ietf.org> References: <063.de10303cc890e70e8d8a6c55265441d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <063.de10303cc890e70e8d8a6c55265441d8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, 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 Resent-To: hkaplan@acmepacket.com, kaynam.hedayat@exfo.com, nathan@robotics.net, paulej@packetizer.com, vnagarjuna@saperix.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VbSl9k3HPTnS8ll7-oyqOjUXcew Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #7: Encapsulated packet format 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, 13 Feb 2014 21:55:17 -0000 #7: Encapsulated packet format Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mmusic-media- hkaplan@acmepacket.com | loopback@tools.ietf.org Type: defect | Status: closed Priority: minor | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: worksforme | Keywords: -------------------------+------------------------------------------------- Ticket URL: mmusic From nobody Thu Feb 13 13:55: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 913881A01FA for ; Thu, 13 Feb 2014 13:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 tPgry0abBfAU for ; Thu, 13 Feb 2014 13:55:34 -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 502291A0124 for ; Thu, 13 Feb 2014 13:55:34 -0800 (PST) Received: from localhost ([127.0.0.1]:40593 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE4Fl-0000Yq-Mo; Thu, 13 Feb 2014 22:55:29 +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: draft-ietf-mmusic-media-loopback@tools.ietf.org, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Thu, 13 Feb 2014 21:55:29 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/8#comment:2 Message-ID: <078.94d6f2b91f2f4c728c8c0abbb1d5492e@trac.tools.ietf.org> References: <063.36a21c8ae2201648ed1fc600bd2822b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <063.36a21c8ae2201648ed1fc600bd2822b5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, 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 Resent-To: hkaplan@acmepacket.com, kaynam.hedayat@exfo.com, nathan@robotics.net, paulej@packetizer.com, vnagarjuna@saperix.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/pKr4_bze0zeAPPYPSumUgclvFQk Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #8: Mirrored packet field overwriting 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, 13 Feb 2014 21:55:38 -0000 #8: Mirrored packet field overwriting Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mmusic-media- hkaplan@acmepacket.com | loopback@tools.ietf.org Type: defect | Status: closed Priority: minor | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: worksforme | Keywords: -------------------------+------------------------------------------------- Ticket URL: mmusic From nobody Thu Feb 13 13:55: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 BEC451A0283 for ; Thu, 13 Feb 2014 13:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 sTHECs4OA213 for ; Thu, 13 Feb 2014 13:55:53 -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 C8CC71A01FA for ; Thu, 13 Feb 2014 13:55:52 -0800 (PST) Received: from localhost ([127.0.0.1]:40631 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE4G4-0005oa-BP; Thu, 13 Feb 2014 22:55:48 +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: draft-ietf-mmusic-media-loopback@tools.ietf.org, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Thu, 13 Feb 2014 21:55:48 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/9#comment:2 Message-ID: <078.5212c2421501133b6b40413109f51af0@trac.tools.ietf.org> References: <063.44ff21944ceee55a80e50994a1d23be1@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <063.44ff21944ceee55a80e50994a1d23be1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, 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 Resent-To: hkaplan@acmepacket.com, kaynam.hedayat@exfo.com, nathan@robotics.net, paulej@packetizer.com, vnagarjuna@saperix.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/AIoHKQ3qKgc5l0mEWONVI_2nwtg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #9: Header extensions in fragmented mirror packet 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, 13 Feb 2014 21:55:55 -0000 #9: Header extensions in fragmented mirror packet Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mmusic-media- hkaplan@acmepacket.com | loopback@tools.ietf.org Type: defect | Status: closed Priority: minor | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: worksforme | Keywords: -------------------------+------------------------------------------------- Ticket URL: mmusic From nobody Thu Feb 13 13:56: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 7BC931A01FA for ; Thu, 13 Feb 2014 13:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 NRQPa77qqAz6 for ; Thu, 13 Feb 2014 13:56:11 -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 925571A0055 for ; Thu, 13 Feb 2014 13:56:11 -0800 (PST) Received: from localhost ([127.0.0.1]:40657 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE4GM-00021O-RG; Thu, 13 Feb 2014 22:56:06 +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: draft-ietf-mmusic-media-loopback@tools.ietf.org, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Thu, 13 Feb 2014 21:56:06 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/10#comment:2 Message-ID: <078.f8f2ff1d422ad293d81681817a6c42fd@trac.tools.ietf.org> References: <063.07ba0297eaf42eaa2184d6af45879e65@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <063.07ba0297eaf42eaa2184d6af45879e65@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, 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 Resent-To: hkaplan@acmepacket.com, kaynam.hedayat@exfo.com, nathan@robotics.net, paulej@packetizer.com, vnagarjuna@saperix.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PzBxzZaiJyRgeFeKRTMoPfHyaxQ Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #10: Source and mirror clock synchronization 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, 13 Feb 2014 21:56:13 -0000 #10: Source and mirror clock synchronization Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mmusic-media- hkaplan@acmepacket.com | loopback@tools.ietf.org Type: defect | Status: closed Priority: minor | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: worksforme | Keywords: -------------------------+------------------------------------------------- Ticket URL: mmusic From nobody Thu Feb 13 13:56: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 4C0E11A028A for ; Thu, 13 Feb 2014 13:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 r41oK0rokycn for ; Thu, 13 Feb 2014 13:56:29 -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 23ED31A01FA for ; Thu, 13 Feb 2014 13:56:29 -0800 (PST) Received: from localhost ([127.0.0.1]:40686 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE4Ge-00070h-Fa; Thu, 13 Feb 2014 22:56:24 +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: draft-ietf-mmusic-media-loopback@tools.ietf.org, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Thu, 13 Feb 2014 21:56:24 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/11#comment:2 Message-ID: <078.a9465a5684e2610a1d2361ed636f1f40@trac.tools.ietf.org> References: <063.4bd7c6dda0aff547eeb6d5483307c23f@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <063.4bd7c6dda0aff547eeb6d5483307c23f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, 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 Resent-To: hkaplan@acmepacket.com, kaynam.hedayat@exfo.com, nathan@robotics.net, paulej@packetizer.com, vnagarjuna@saperix.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TKiKAa4R3rcLPL-i3z1zTWGwmks Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #11: Padding in mirrored packets 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, 13 Feb 2014 21:56:34 -0000 #11: Padding in mirrored packets Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mmusic-media- hkaplan@acmepacket.com | loopback@tools.ietf.org Type: defect | Status: closed Priority: minor | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: worksforme | Keywords: -------------------------+------------------------------------------------- Ticket URL: mmusic From nobody Thu Feb 13 13:56:49 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 0261B1A01FA for ; Thu, 13 Feb 2014 13:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 ec0gr6_Ru9vS for ; Thu, 13 Feb 2014 13:56:46 -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 4530D1A027D for ; Thu, 13 Feb 2014 13:56:46 -0800 (PST) Received: from localhost ([127.0.0.1]:40719 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WE4Gv-0003YI-Qx; Thu, 13 Feb 2014 22:56:41 +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: draft-ietf-mmusic-media-loopback@tools.ietf.org, ari.keranen@ericsson.com, fandreas@cisco.com X-Trac-Project: mmusic Date: Thu, 13 Feb 2014 21:56:41 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/12#comment:2 Message-ID: <078.a69055b46a50bb2a1759ee4036972f51@trac.tools.ietf.org> References: <063.88288e22e77a8504c75e33201a2edc37@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <063.88288e22e77a8504c75e33201a2edc37@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, 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 Resent-To: hkaplan@acmepacket.com, kaynam.hedayat@exfo.com, nathan@robotics.net, paulej@packetizer.com, vnagarjuna@saperix.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/C9M-CCGBCf8ut8L3w_g_v2qe3_M Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #12: MUST vs. SHOULD for mirror RTP seq number 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, 13 Feb 2014 21:56:48 -0000 #12: MUST vs. SHOULD for mirror RTP seq number Changes (by fandreas@cisco.com): * status: new => closed * resolution: => worksforme -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mmusic-media- hkaplan@acmepacket.com | loopback@tools.ietf.org Type: defect | Status: closed Priority: minor | Component: media-loopback Version: 1.0 | Severity: In WG Last Call Resolution: worksforme | Keywords: -------------------------+------------------------------------------------- Ticket URL: mmusic From nobody Thu Feb 13 14:44:05 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 097091A0021 for ; Thu, 13 Feb 2014 14:44:02 -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 dHYBDX52xrL5 for ; Thu, 13 Feb 2014 14:43:59 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2151A0018 for ; Thu, 13 Feb 2014 14:43:58 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id p61so8287833wes.17 for ; Thu, 13 Feb 2014 14:43:57 -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=hWEZhRihcbZELE10YdtpnaoOmNjwsWFTuS1IdvCoMes=; b=vrwBQBNvoNh+SOeoQOAxZTkflT/rAsCa2I/3iJNfdfbEIFY3dDdIP++PLyMYZ6rKBd z2FR/ttCAC1iRjYGmQDLv4PlpYwGI4A3povf9sq5tZZ5SLMUDjXyPJEDUPTwtAsNr8bg RkY9dfw3IoHQmC/TdK8b5T0Lx8mEbFcjqQ24BWubwXMJvpOxYhVMQdmp2HAA1UaDYfsa inUCKBCm6CcSlJt22mlNso/S7Nx+toI6F0tuH6pVViKRDJTgkL21NKLNbLtQ4unl5bke rqpVNz7oJT0YDcPehga373xhtDzQxvKYHa5R3lJ6OKOW7H6o1bG8UVvSduo6Z99UNvfM PrnQ== MIME-Version: 1.0 X-Received: by 10.194.179.69 with SMTP id de5mr3439326wjc.4.1392331437436; Thu, 13 Feb 2014 14:43:57 -0800 (PST) Received: by 10.195.12.134 with HTTP; Thu, 13 Feb 2014 14:43:57 -0800 (PST) In-Reply-To: <10C8325A-F234-4034-BD05-D0D24C0B562B@vidyo.com> References: <10C8325A-F234-4034-BD05-D0D24C0B562B@vidyo.com> Date: Thu, 13 Feb 2014 14:43:57 -0800 Message-ID: From: Suhas Nandakumar To: Jonathan Lennox Content-Type: multipart/alternative; boundary=089e01493caebd102404f2516c21 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vYjRn9ORzVDnxfb2VhHgpHWbWlQ Cc: mmusic Subject: Re: [MMUSIC] MSID and AppID: solving different problems 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, 13 Feb 2014 22:44:02 -0000 --089e01493caebd102404f2516c21 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 13, 2014 at 10:09 AM, Jonathan Lennox wrote: > The chairs asked that the authors of the MSID and AppID drafts discuss the > relationship between the two documents. > > My personal opinion (which I mentioned in the RTCWeb Rejecting > MediaStreamTracks thread, but folks might not have seen) is that they're > solving different problems, and so are non-conflicting. > MSID provides an identifier for SDP m= lines. Its primary use case is > providing a Javascript-level handle in WebRTC. > > AppID -- which needs a better name, suggestions welcome -- provides an > indirection label for identifying individual RTP packet streams in SDP, in > scenarios where the SSRC is unavailable to the signaling. > [Suhas] How about the name SSID (Source Stream ID) to identify the individual RTP packet streams > > The scenarios we've identified so far for AppID where an SSRC might be > unavailable are: "early media" race conditions where media outraces an SDP > answer; SSRC collisions; applications which wish to dynamically switch > which SSRC is fulfilling a higher-level application role; and architectures > where the signaling stack can't control/doesn't have visibility onto the > SSRC selection. > > AppID should be applicable to anything using BUNDLE, I think, and > certainly anything using it with a vaguely Unified-style semantic. (I > think it would apply to a "Plan B"-style semantic, as well, which I know > some people are still advocating for some non-WebRTC contexts; however, I'm > not positive all the syntax necessary for that is currently complete.) > > The difference between AppID and MSID should be most clear in scenarios > where an m= line group has more than one packet stream (my canonical > example is a primary stream and a retransmission stream). In this case, > the m= line group has one msid attribute, but multiple appid attributes. > [Suhas] +1 on the difference be made clear. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --089e01493caebd102404f2516c21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 13, 2014 at 10:09 AM, Jonathan Lennox <jonathan@vidyo= .com> wrote:
The chairs asked that the authors of the MSI= D and AppID drafts discuss the relationship between the two documents.

My personal opinion (which I mentioned in the RTCWeb Rejecting MediaStreamT= racks thread, but folks might not have seen) is that they're solving di= fferent problems, and so are non-conflicting.
MSID provides an identifier for SDP m=3D lines. =A0Its primary use case is = providing a Javascript-level handle in WebRTC.

AppID -- which needs a better name, suggestions welcome -- provides an indi= rection label for identifying individual RTP packet streams in SDP, in scen= arios where the SSRC is unavailable to the signaling.

[Suhas] How about the name SSID (Source Stream ID) to i= dentify the individual RTP packet streams
=A0

The scenarios we've identified so far for AppID where an SSRC might be = unavailable are: "early media" race conditions where media outrac= es an SDP answer; SSRC collisions; applications which wish to dynamically s= witch which SSRC is fulfilling a higher-level application role; and archite= ctures where the signaling stack can't control/doesn't have visibil= ity onto the SSRC selection.

AppID should be applicable to anything using BUNDLE, I think, and certainly= anything using it with a vaguely Unified-style semantic. =A0(I think it wo= uld apply to a "Plan B"-style semantic, as well, which I know som= e people are still advocating for some non-WebRTC contexts; however, I'= m not positive all the syntax necessary for that is currently complete.)
The difference between AppID and MSID should be most clear in scenarios whe= re an m=3D line group has more than one packet stream (my canonical example= is a primary stream and a retransmission stream). =A0In this case, the m= =3D line group has one msid attribute, but multiple appid attributes.

[Suhas] +1 on the difference be made clear= .=A0
=A0
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--089e01493caebd102404f2516c21-- From nobody Thu Feb 13 15:49:50 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 85EFF1A043B for ; Thu, 13 Feb 2014 15:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=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 L5-S-0eolLh4 for ; Thu, 13 Feb 2014 15:49:46 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D3C1A01F5 for ; Thu, 13 Feb 2014 15:49:14 -0800 (PST) Received: from ppp118-209-210-231.lns20.mel6.internode.on.net ([118.209.210.231]:52940 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WE5zy-0004Wl-FO for mmusic@ietf.org; Fri, 14 Feb 2014 10:47:18 +1100 Message-ID: <52FD59F3.7030306@nteczone.com> Date: Fri, 14 Feb 2014 10:49:07 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/OIRykfG_ZxRrrQpQquWZa-UJsOg Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 13 Feb 2014 23:49:48 -0000 Hello, Some further comments: Section 11.1 (Editorial) - 11.1 The first paragraph regarding 'sctpmap' attribute appears to be repeated. Section 4.1 (Technical): I see the draft has removed the using using "bfcp" and "t38" as values for the "App" field under one m-line. However that also removes any hint about multiple a=sctpmaps being used under one m-line. For example should there be one a=sctpmap per 'fmt' or could there be zero or more a=sctpmaps per 'fmt' in the m-line? If think this should be clarified. General: There was a discussion on the CLUE mailing list whether there could be multiple CLUE protocol instances per SCTP association. We couldn't identify a use case but couldn't rule it out either. I assume this would apply to other "apps" also. For example something like: m=application 54111 DTLS/SCTP 5000 c=IN IP4 79.97.215.79 a=sctpmap:5000 clue max-message-size=100000 streams=1 a=sctpmap:5000 clue max-message-size=100000 streams=1 a=sctpmap:5000 clue max-message-size=100000 streams=1 Do we need a "label" to uniquely identify a particular 'app' instance? i.e. Similar to the optional label that draft-ietf-rtcweb-data-protocol uses. e.g. a=sctpmap:5000 clue max-message-size=100000 streams=1 label1 a=sctpmap:5000 clue max-message-size=100000 streams=1 label2 a=sctpmap:5000 clue max-message-size=100000 streams=1 label3 Regards, Christian On 14/02/2014 7:57 AM, Christer Holmberg wrote: > Hi, > I gave some comments off-line to Salvatore, which have been addressed > in the new version. > Some additional comments. I do realize some are pure editorial, but > rather to write then down in some notes I put them directly into the > e-mail J > *Section 1:* > *------------* > *Q1**(EDITORIAL)**:* > The text says: > "Since > no-one so far has implemented SCTP over TLS, due to some serious > limitations described in [RFC6083], this document does not make use > of TLS over SCTP as described in RFC3436 [RFC3436]." > I suggest to simply say something like: > "As described in [RFC6083], there are limitations associated with > implementing > SCTP over TLS. For that reason, SCTP over TLS is outside the scope of > this document." > *Q2**(EDITORIAL)**:* > The text says: > "Additionally, this document specifies the use of the 'setup' and > 'connection' SDP attributes to establish SCTP associations. These > attributes were defined in RFC4145 [RFC4145] for TCP. This document > discusses their use with SCTP." > I suggest to remove the last sentence, as it only repeats what is said > in the first sentence. > *Section 3:* > *------------* > *Q3 (EDITORIAL):* > The text says: > “This document defines three new values for the 'proto' field: 'SCTP', > 'SCTP/DTLS' and 'DTLS/SCTP'.” > I would suggest to say: > “This document defines three new *protocol identifier* values for the > 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'.” > …because, you use “protocol identifier” terminology later. > *Q4 (CLARIFICATION):* > The text says: > “An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST > further qualify the application-layer protocol using an fmt > identifier.” > I do understand what you are trying to say, but I think the “qualify” > word is a little confusing. > Maybe something like: > “An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST > further include an fmt value that identifies the application-layer > protocol > carried on top of the SCTP association.” > *Section 4.1:* > *--------------* > *Q5 (TECHNICAL):* > The text says: > “For the payload type assignments the "a=sctpmap:" > attribute (see Section 5.1) SHOULD be used to map from a port number > to a media encoding name that identifies the payload format > transported by the association or the actual application protocol > running on top of it.” > It is very difficult for me to parse this, and figure out the > semantics of the sctpmap attribute. > First, what do you mean by “media encoding name”? > Second, when you talk about “application protocol”, I assume you refer > to the SCTP protocol? > Third, the text say SHOULD. When is it ok to not use the sctpmap > attribute? > *Section **5**:* > *------------* > *Q6 (EDITORIAL):* > I suggest to rename section 5 to “SDP sctpmap attribute”, rename > section 5.1 to “General”, and add a new section 5.2 named “ABNF”. > *Q7 (TECHNICAL):* > The text says: > “The sctpmap MUST include the app parameter indicating the application > running on top of the association.” > This is fine if the sctpmap attribute maps to an application. But, > what if the sctpmap attribute maps to a “media encoding” or “payload”? > *Q8 **(EDITORIAL):* > The text says: > “The sctpmap line should also contain the max-message-size parameter > indicating the maximum message size, in bytes, the endpoint is > willing to accept.” > I suggest to replace “accept” with “receive on the associated SCTP > association”. > *Q9 (EDITORIAL):* > The text says: > “The peer should assume that larger message will be rejected by the > endpoint, though it is up to the endpoint decide the appropriate > behaviour.” > I suggest to either remove this paragraph, OR replace it with a > sentence saying that a peer must/should not send messages bigger than > the indicated max value. > *Q10 (CLARIFICATION):* > The text says: > “If the parameter is not present, the implementation should provide > a default, with a suggested value of 64K.” > I don’t understand “suggested”. If the default value is 64K the text > should specify (rather than suggest) that. > The same comment applies to the stream parameter, described later in > the section. > *Q11 (CLARIFICATION):* > The text says: > “It may also provide the stream parameter to specify the initial > number of incoming streams to be supported by each side of the > association.” > First, to be consistent with previous text, I suggest to replace “It > may also provide” with “The sctpmap line may also contain” > Second, I don’t understand “incoming streams to be supported by each > side of the association”. Doesn’t each peer indicate the number of > streams it is willing to receive? Then, we can always recommend that > the peer indicates the same number of streams, if possible. > *Q12 (EDITORIAL):* > The text that follows the ABNF should be put into a separate “SDP > Offer/Answer Procedures” section. > *Section 7:* > *------------* > *Q13 (EDITORIAL):* > Please don’t talk about re-INVITEs, or other SIP messages. Simply talk > about offers and answers. > *Q14 (EDITORIAL):* > The text says: > “It is worth to underline that when using SCTP on top of DTLS,..” > To have consistent terminology, please say “SCTP over DTLS”. > That’s all for now! :) > Regards, > Christer > -----Alkuperäinen viesti----- > Lähettäjä: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta > internet-drafts@ietf.org > Lähetetty: 13. helmikuuta 2014 16:21 > Vastaanottaja: i-d-announce@ietf.org > Kopio: mmusic@ietf.org > Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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 : Stream Control Transmission Protocol (SCTP)-Based Media > Transport in the Session Description Protocol (SDP) > Authors : Salvatore Loreto > Gonzalo Camarillo > Filename : draft-ietf-mmusic-sctp-sdp-06.txt > Pages : 14 > Date : 2014-02-13 > Abstract: > SCTP (Stream Control Transmission Protocol) is a transport protocol > used to establish associations between two endpoints. This document > describes how to express media transport over SCTP in SDP (Session > Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' > and 'DTLS/SCTP' protocol identifiers for SDP. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-06 > 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 From nobody Thu Feb 13 22:56: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 18DB71A0115 for ; Thu, 13 Feb 2014 22:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, 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 SixI1zOV5Mwt for ; Thu, 13 Feb 2014 22:56:44 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 849651A0131 for ; Thu, 13 Feb 2014 22:56:43 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-7e-52fdbe295bd9 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BF.19.10875.92EBDF25; Fri, 14 Feb 2014 07:56:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 07:56:40 +0100 From: Christer Holmberg To: Christian Groves , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments Thread-Index: Ac8o/jG9d4h50B84TBauKcEd8AH/LQAD5tmAABD2C2A= Date: Fri, 14 Feb 2014 06:56:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D17213B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> <52FD59F3.7030306@nteczone.com> In-Reply-To: <52FD59F3.7030306@nteczone.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvja7mvr9BBt83a1h8ed/IYjF1+WMW ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSujcfVipoIZvhX3789hamD8Y9/FyMkhIWAi 8eXqLBYIW0ziwr31bCC2kMAhRok9l/y7GLmA7MWMEsu2zgdKcHCwCVhIdP/TBqkREYiWmLSw GaxeWCBZ4sOJB8wQ8RSJ46cboWwricO978BqWARUJb4+PsEKYvMK+Eo0H2thhtiVL7Htzlmw GzgFdCQuvH/DDmIzAt3z/dQaJhCbWUBc4taT+UwQdwpILNlznhnCFpV4+fgfK4StJPFjwyUW iHo9iRtTp7BB2NoSyxa+ZobYKyhxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYmTPTczMSS83 3MQIjISDW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhh5 9ALEj227PJ1/k/arBZdbGM8v9DD7M/Fb0e0W/peBV+cyT/Ga+JP7/HqBHTIzGhx+X1CSdF54 88diHymvuGm5YSskDr4yXvr0x5qPz7JYy/ijMyfEP6xpmazHsbnnZ8UtkYnMwmzh8fV+pn8v KC5VOy2wcdfGaKG2Yp8d3M36Po5vBOcbeD9WYinOSDTUYi4qTgQAIP30nlICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RRDCQ-p-pFgsvQUQ9gy_Bng8GvY Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 14 Feb 2014 06:56:46 -0000 Hi Christian, A comment, based on your example. I don't think we would indicate "clue" in= the sctpmap attribute. We would indicate "webrtc-datachannel", in order to= be able to interwork with browsers. Then, on that webrtc-datachannel, we w= ould run the CLUE protocol (which we would negotiate e.g. using the DCP, Ri= chard's draft, or some other mechanism). Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves Sent: 14. helmikuuta 2014 1:49 To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Chris= ter's initial comments Hello, Some further comments: Section 11.1 (Editorial) - 11.1 The first paragraph regarding 'sctpmap'=20 attribute appears to be repeated. Section 4.1 (Technical): I see the draft has removed the using using "bfcp"= and "t38" as values for the "App" field under one m-line. However that als= o removes any hint about multiple a=3Dsctpmaps being used under one m-line.= For example should there be one a=3Dsctpmap per 'fmt' or could there be ze= ro or more a=3Dsctpmaps per 'fmt' in the m-line? If think this should be cl= arified. General: There was a discussion on the CLUE mailing list whether there coul= d be multiple CLUE protocol instances per SCTP association. We couldn't ide= ntify a use case but couldn't rule it out either. I assume this would apply= to other "apps" also. For example something like: m=3Dapplication 54111 DTLS/SCTP 5000 c=3DIN IP4 79.97.215.79 a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 Do we need a "l= abel" to uniquely identify a particular 'app' instance?=20 i.e. Similar to the optional label that draft-ietf-rtcweb-data-protocol use= s. e.g. a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label1 a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label2 a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label3 Regards, Christian On 14/02/2014 7:57 AM, Christer Holmberg wrote: > Hi, > I gave some comments off-line to Salvatore, which have been addressed=20 > in the new version. > Some additional comments. I do realize some are pure editorial, but=20 > rather to write then down in some notes I put them directly into the=20 > e-mail J *Section 1:* > *------------* > *Q1**(EDITORIAL)**:* > The text says: > "Since > no-one so far has implemented SCTP over TLS, due to some serious=20 > limitations described in [RFC6083], this document does not make use of=20 > TLS over SCTP as described in RFC3436 [RFC3436]." > I suggest to simply say something like: > "As described in [RFC6083], there are limitations associated with=20 > implementing SCTP over TLS. For that reason, SCTP over TLS is outside=20 > the scope of this document." > *Q2**(EDITORIAL)**:* > The text says: > "Additionally, this document specifies the use of the 'setup' and=20 > 'connection' SDP attributes to establish SCTP associations. These=20 > attributes were defined in RFC4145 [RFC4145] for TCP. This document=20 > discusses their use with SCTP." > I suggest to remove the last sentence, as it only repeats what is said=20 > in the first sentence. > *Section 3:* > *------------* > *Q3 (EDITORIAL):* > The text says: > "This document defines three new values for the 'proto' field: 'SCTP',=20 > 'SCTP/DTLS' and 'DTLS/SCTP'." > I would suggest to say: > "This document defines three new *protocol identifier* values for the=20 > 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." > .because, you use "protocol identifier" terminology later. > *Q4 (CLARIFICATION):* > The text says: > "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST=20 > further qualify the application-layer protocol using an fmt=20 > identifier." > I do understand what you are trying to say, but I think the "qualify"=20 > word is a little confusing. > Maybe something like: > "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST=20 > further include an fmt value that identifies the application-layer=20 > protocol carried on top of the SCTP association." > *Section 4.1:* > *--------------* > *Q5 (TECHNICAL):* > The text says: > "For the payload type assignments the "a=3Dsctpmap:" > attribute (see Section 5.1) SHOULD be used to map from a port number=20 > to a media encoding name that identifies the payload format=20 > transported by the association or the actual application protocol=20 > running on top of it." > It is very difficult for me to parse this, and figure out the=20 > semantics of the sctpmap attribute. > First, what do you mean by "media encoding name"? > Second, when you talk about "application protocol", I assume you refer=20 > to the SCTP protocol? > Third, the text say SHOULD. When is it ok to not use the sctpmap=20 > attribute? > *Section **5**:* > *------------* > *Q6 (EDITORIAL):* > I suggest to rename section 5 to "SDP sctpmap attribute", rename=20 > section 5.1 to "General", and add a new section 5.2 named "ABNF". > *Q7 (TECHNICAL):* > The text says: > "The sctpmap MUST include the app parameter indicating the application=20 > running on top of the association." > This is fine if the sctpmap attribute maps to an application. But,=20 > what if the sctpmap attribute maps to a "media encoding" or "payload"? > *Q8 **(EDITORIAL):* > The text says: > "The sctpmap line should also contain the max-message-size parameter=20 > indicating the maximum message size, in bytes, the endpoint is willing=20 > to accept." > I suggest to replace "accept" with "receive on the associated SCTP=20 > association". > *Q9 (EDITORIAL):* > The text says: > "The peer should assume that larger message will be rejected by the=20 > endpoint, though it is up to the endpoint decide the appropriate=20 > behaviour." > I suggest to either remove this paragraph, OR replace it with a=20 > sentence saying that a peer must/should not send messages bigger than=20 > the indicated max value. > *Q10 (CLARIFICATION):* > The text says: > "If the parameter is not present, the implementation should provide a=20 > default, with a suggested value of 64K." > I don't understand "suggested". If the default value is 64K the text=20 > should specify (rather than suggest) that. > The same comment applies to the stream parameter, described later in=20 > the section. > *Q11 (CLARIFICATION):* > The text says: > "It may also provide the stream parameter to specify the initial=20 > number of incoming streams to be supported by each side of the=20 > association." > First, to be consistent with previous text, I suggest to replace "It=20 > may also provide" with "The sctpmap line may also contain" > Second, I don't understand "incoming streams to be supported by each=20 > side of the association". Doesn't each peer indicate the number of=20 > streams it is willing to receive? Then, we can always recommend that=20 > the peer indicates the same number of streams, if possible. > *Q12 (EDITORIAL):* > The text that follows the ABNF should be put into a separate "SDP=20 > Offer/Answer Procedures" section. > *Section 7:* > *------------* > *Q13 (EDITORIAL):* > Please don't talk about re-INVITEs, or other SIP messages. Simply talk=20 > about offers and answers. > *Q14 (EDITORIAL):* > The text says: > "It is worth to underline that when using SCTP on top of DTLS,.." > To have consistent terminology, please say "SCTP over DTLS". > That's all for now! :) > Regards, > Christer > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta=20 > internet-drafts@ietf.org > L=E4hetetty: 13. helmikuuta 2014 16:21 > Vastaanottaja: i-d-announce@ietf.org > Kopio: mmusic@ietf.org > Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt A New=20 > Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Multiparty Multimedia Session Control=20 > Working Group of the IETF. > Title : Stream Control Transmission Protocol (SCTP)-Based Media=20 > Transport in the Session Description Protocol (SDP) Authors :=20 > Salvatore Loreto Gonzalo Camarillo Filename :=20 > draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13 > Abstract: > SCTP (Stream Control Transmission Protocol) is a transport protocol=20 > used to establish associations between two endpoints. This document=20 > describes how to express media transport over SCTP in SDP (Session=20 > Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' > and 'DTLS/SCTP' protocol identifiers for SDP. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-06 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > _______________________________________________ > mmusic mailing list > mmusic@ietf.org =20 > 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 nobody Thu Feb 13 23:07: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 CFE781A0177; Thu, 13 Feb 2014 23:07: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 skd4B_sUBM_B; Thu, 13 Feb 2014 23:07:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B14D51A0151; Thu, 13 Feb 2014 23:07:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214070718.7731.54828.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 23:07:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VHoCabTFtjuWXUXuKGc6dQdVcy8 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-04.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, 14 Feb 2014 07:07:26 -0000 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 : WebRTC MediaStream Identification in the Session Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-04.txt Pages : 17 Date : 2014-02-13 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-04 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 nobody Thu Feb 13 23:11:05 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 D9A4C1A0115 for ; Thu, 13 Feb 2014 23:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 8PEy1x7TLBcb for ; Thu, 13 Feb 2014 23:10:59 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 95CAC1A012C for ; Thu, 13 Feb 2014 23:10:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D3ADD7C4C8B for ; Fri, 14 Feb 2014 08:10:57 +0100 (CET) Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Dr32-FNGcJp for ; Fri, 14 Feb 2014 08:10:57 +0100 (CET) Received: from [10.1.1.234] (64-71-23-98.static.wiline.com [64.71.23.98]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0F68D7C4B05 for ; Fri, 14 Feb 2014 08:10:56 +0100 (CET) Message-ID: <52FDC17E.8070708@alvestrand.no> Date: Fri, 14 Feb 2014 08:10:54 +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 X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ERfFvX4Vb3LZIHK241lm4g6DjZc Subject: [MMUSIC] msid-04 submitted 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, 14 Feb 2014 07:11:04 -0000 I have submitted a new version of the MSID draft, -04. It tries to make it crystal clear that the msid-semantic:wms is only intended for signalling MediaStreamTracks and MediaStreams. It also adds a new functionality: msid-control, which can be used by a receiver of MediaStreamTracks to signal the sender of a MediaStreamTrack what the receiver wishes with regard to that MediaStreamTrack; this need has been identified within the WebRTC and RTCWEB WGs. It seemed logical to extend this draft with that functionality, since it is closely allied functionality. Comments are welcome. Harald -- Surveillance is pervasive. Go Dark. From nobody Thu Feb 13 23:14: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 2FB361A00CA for ; Thu, 13 Feb 2014 23:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 4MvmAFtibFUz for ; Thu, 13 Feb 2014 23:14:37 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 58BEF1A0087 for ; Thu, 13 Feb 2014 23:14:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9F8217C4C8C for ; Fri, 14 Feb 2014 08:14:35 +0100 (CET) Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-vf0Nbkpszi for ; Fri, 14 Feb 2014 08:14:35 +0100 (CET) Received: from [10.1.1.234] (64-71-23-98.static.wiline.com [64.71.23.98]) by mork.alvestrand.no (Postfix) with ESMTPSA id DB5D17C4C8B for ; Fri, 14 Feb 2014 08:14:34 +0100 (CET) Message-ID: <52FDC258.9000608@alvestrand.no> Date: Fri, 14 Feb 2014 08:14:32 +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: <10C8325A-F234-4034-BD05-D0D24C0B562B@vidyo.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060006040203020604020403" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/W4oDwGjMVmjRLnlF9fMyabTLU3I Subject: Re: [MMUSIC] MSID and AppID: solving different problems 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, 14 Feb 2014 07:14:39 -0000 This is a multi-part message in MIME format. --------------060006040203020604020403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/13/2014 11:43 PM, Suhas Nandakumar wrote: > > > > On Thu, Feb 13, 2014 at 10:09 AM, Jonathan Lennox > wrote: > > The chairs asked that the authors of the MSID and AppID drafts > discuss the relationship between the two documents. > > My personal opinion (which I mentioned in the RTCWeb Rejecting > MediaStreamTracks thread, but folks might not have seen) is that > they're solving different problems, and so are non-conflicting. > > MSID provides an identifier for SDP m= lines. Its primary use > case is providing a Javascript-level handle in WebRTC. > > AppID -- which needs a better name, suggestions welcome -- > provides an indirection label for identifying individual RTP > packet streams in SDP, in scenarios where the SSRC is unavailable > to the signaling. > I am certainly happy with drawing a distinction along these lines, and let each find its own user base. > > [Suhas] How about the name SSID (Source Stream ID) to identify the > individual RTP packet streams I would advise against using such a frequently used acronym. If inventing a new one, what about RTP Packet Stream Correlation Tag - RPSCT? I don't think I've encountered that in the IETF yet.... --------------060006040203020604020403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/13/2014 11:43 PM, Suhas Nandakumar wrote:



On Thu, Feb 13, 2014 at 10:09 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
The chairs asked that the authors of the MSID and AppID drafts discuss the relationship between the two documents.

My personal opinion (which I mentioned in the RTCWeb Rejecting MediaStreamTracks thread, but folks might not have seen) is that they're solving different problems, and so are non-conflicting.
MSID provides an identifier for SDP m= lines.  Its primary use case is providing a Javascript-level handle in WebRTC.

AppID -- which needs a better name, suggestions welcome -- provides an indirection label for identifying individual RTP packet streams in SDP, in scenarios where the SSRC is unavailable to the signaling.

I am certainly happy with drawing a distinction along these lines, and let each find its own user base.


[Suhas] How about the name SSID (Source Stream ID) to identify the individual RTP packet streams

I would advise against using such a frequently used acronym.
If inventing a new one, what about RTP Packet Stream Correlation Tag - RPSCT?
I don't think I've encountered that in the IETF yet....


--------------060006040203020604020403-- From nobody Thu Feb 13 23: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 682281A01DB; Thu, 13 Feb 2014 23:43: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 XkkjAryAXJDX; Thu, 13 Feb 2014 23:43:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA91C1A01C5; Thu, 13 Feb 2014 23:43:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214074300.10657.776.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 23:43:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/0xZgZhnIIQSyowZqTUpQOwN6YOI Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-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: Fri, 14 Feb 2014 07:43:02 -0000 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 : UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) Authors : Christer Holmberg Ivo Sedlacek Gonzalo Salgueiro Filename : draft-ietf-mmusic-udptl-dtls-05.txt Pages : 23 Date : 2014-02-13 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-udptl-dtls-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 nobody Thu Feb 13 23:45: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 F16311A01C7 for ; Thu, 13 Feb 2014 23:45:02 -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 t22iuIFNIFEc for ; Thu, 13 Feb 2014 23:45:01 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9A08B1A01C3 for ; Thu, 13 Feb 2014 23:45:00 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-aa-52fdc97a1b1d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 22.72.23809.A79CDF25; Fri, 14 Feb 2014 08:44:58 +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, 14 Feb 2014 08:44:57 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-udptl-dtls-05 Thread-Index: Ac8pWJX3SntVSGX0Rwiw650jzJ8ZBA== Date: Fri, 14 Feb 2014 07:44:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D172331@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_7594FB04B1934943A5C02806D1A2204B1D172331ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvjW7Vyb9BBtP6tS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD0z5jMWPBau2Dl9NmsD40XBLkZODgkBE4mfXTOZIGwxiQv3 1rN1MXJxCAkcYpRYvXoyO4SzmFFi6ZIbQA4HB5uAhUT3P22QBhEBdYmve3uYQWxhAWuJRX+3 MUHEHSSmzV3HBmHrSVxpe8EKYrMIqEpMP9PDCGLzCvhK7P/3hgXEZgRa/P3UGrBeZgFxiVtP 5kMdJCCxZM95ZghbVOLl43+sELaSxI8Nl1gg6vOB9k5jh5gpKHFy5hOWCYxCs5CMmoWkbBaS Moi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03MTMnvdxoEyMw7A9u+a26g/HOOZFD jNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJzgtTcl1N5tTuTrDa8kE4Qf lK67ufp/p6z57Xi26GtJfUUc6+YV9R8qDqvpZHJpYXidIu9+Zq/i3vPiaSebOk83b7LTPXH/ rfn/F84dUl0V7A/SPoh7t2qF3O1446UfHNot9oib8ZbS1pnb32y4rpWmr7Sn9SPrCl+O5drF k22PBHpmPtqUr8RSnJFoqMVcVJwIAJ4neCRJAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LprcL0j9RMVfKqsx-x4D-B3FVx4 Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-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: Fri, 14 Feb 2014 07:45:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D172331ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the review comments by Flemming, I've submitted a new version of t= he udptl-dtls draft. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D172331ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the review comments by Flemming, I’ve= submitted a new version of the udptl-dtls draft.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D172331ESESSMB209erics_-- From nobody Fri Feb 14 00:00: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 E664C1A00FD for ; Fri, 14 Feb 2014 00:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 Ekp9yFsLeGf1 for ; Fri, 14 Feb 2014 00:00:19 -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 E6BD81A0102 for ; Fri, 14 Feb 2014 00:00:17 -0800 (PST) Received: from localhost ([127.0.0.1]:39527 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WEDh1-0006Kn-TX; Fri, 14 Feb 2014 09:00: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: abegen@cisco.com X-Trac-Project: mmusic Date: Fri, 14 Feb 2014 08:00:15 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/mmusic/trac/ticket/13 Message-ID: <057.623779feec9bfa672fc3218eb4ffb595@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abegen@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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vx1_VxFFtHSRpJZJ6ncr4utpJXM Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #13: This is a test ticket for 4566bis 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, 14 Feb 2014 08:00:22 -0000 #13: This is a test ticket for 4566bis This is a test, please ignore. -- -----------------------------+-------------------------------- Reporter: abegen@cisco.com | Owner: abegen@cisco.com Type: defect | Status: new Priority: trivial | Component: rfc4566bis Version: 2.0 | Severity: Active WG Document Keywords: | -----------------------------+-------------------------------- Ticket URL: mmusic From nobody Fri Feb 14 00:34: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 CA1F61A0139 for ; Fri, 14 Feb 2014 00:34:49 -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 u7O6e6gWUMav for ; Fri, 14 Feb 2014 00:34:48 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C6B311A0127 for ; Fri, 14 Feb 2014 00:34:47 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c1-52fdd525adc5 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 82.B4.10875.525DDF25; Fri, 14 Feb 2014 09:34:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 09:34:45 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments Thread-Index: Ac8o/jG9d4h50B84TBauKcEd8AH/Lf//9PCA//8yaRA= Date: Fri, 14 Feb 2014 08:34:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1725A1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> <52FD367D.5060908@alum.mit.edu> In-Reply-To: <52FD367D.5060908@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvja7q1b9BBtP3m1tMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGsd3vmArWsFd8/7SJtYHxAWsXIyeHhICJ xIeWfjYIW0ziwr31YLaQwCFGifVdWl2MXED2YkaJhpt/mboYOTjYBCwkuv9pg9SICPhKPHt8 G6xeWCBZ4sOJB8wQ8RSJ46cboWwriT8NS8BqWARUJRa9vAW2lxeo9+2BF+wQu/Il7jdNZAKx OQV0JJb1XgKrYQS65/upNWBxZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/UL8oSfzYcIkFol5H YsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGNlzEzNz0ssNNzEC I+Hglt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZWjtif HkoNDUUJq9VLK7cv6j8tVejnNi+pUk79d5YtZ5a/feCf5iJTTcMa38/ZJ14tCa6yXbelwGdZ XcmHuQue6jfUNbL/2J83P3zzNoGHi6c3HFnCu/D82S2L/uod3j1B/4be6k2lPceZ25xF9XSz d1yxzTn7NuOGQJHWFM/PD34/L7rx7bkSS3FGoqEWc1FxIgDKkZ5LUgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tQEd9MoSTfMv6eXYcgMdYrP4WlE Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 14 Feb 2014 08:34:50 -0000 Hi, >> *Q4 (CLARIFICATION):* >> The text says: >> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUS= T >> further qualify the application-layer protocol using an fmt >> identifier." >> I do understand what you are trying to say, but I think the "qualify" >> word is a little confusing. >> Maybe something like: >> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUS= T >> further include an fmt value that identifies the application-layer=20 >> protocol >> carried on top of the SCTP association." > > The clarification would be fine, but both the original and the clarificat= ion are misleading. The fmt value does not identify an application-layer pr= otocol - it identifies a port number. This is explained later in section 4.= 1. Correct. The SDP sctpmap attribute then associates that port number with an= SCTP application. Regards, Christer From nobody Fri Feb 14 01:05:47 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 43F991A01CF for ; Fri, 14 Feb 2014 01:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=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 7Pt8A4FMihmC for ; Fri, 14 Feb 2014 01:05:40 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483F21A0123 for ; Fri, 14 Feb 2014 01:05:39 -0800 (PST) Received: from ppp118-209-210-231.lns20.mel6.internode.on.net ([118.209.210.231]:63253 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WEEgM-0007pQ-HT; Fri, 14 Feb 2014 20:03:38 +1100 Message-ID: <52FDDC5B.40900@nteczone.com> Date: Fri, 14 Feb 2014 20:05:31 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> <52FD59F3.7030306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17213B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D17213B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/63HetNemVagzDtTkzBicGfSi4Ts Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 14 Feb 2014 09:05:43 -0000 Hello Christer, I'm not assuming the use of webrtc-data channel. The issue would apply to any "app" being used multiple times in an SCTP association. Are you suggesting any time that you want to use multiple instances of an "app" that you must use "webrtc-datachannel" even if there are no web browsers involved? Regards, Christian On 14/02/2014 5:56 PM, Christer Holmberg wrote: > Hi Christian, > > A comment, based on your example. I don't think we would indicate "clue" in the sctpmap attribute. We would indicate "webrtc-datachannel", in order to be able to interwork with browsers. Then, on that webrtc-datachannel, we would run the CLUE protocol (which we would negotiate e.g. using the DCP, Richard's draft, or some other mechanism). > > Regards, > > Christer > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 14. helmikuuta 2014 1:49 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments > > Hello, > > Some further comments: > > Section 11.1 (Editorial) - 11.1 The first paragraph regarding 'sctpmap' > attribute appears to be repeated. > > Section 4.1 (Technical): I see the draft has removed the using using "bfcp" and "t38" as values for the "App" field under one m-line. However that also removes any hint about multiple a=sctpmaps being used under one m-line. For example should there be one a=sctpmap per 'fmt' or could there be zero or more a=sctpmaps per 'fmt' in the m-line? If think this should be clarified. > > General: There was a discussion on the CLUE mailing list whether there could be multiple CLUE protocol instances per SCTP association. We couldn't identify a use case but couldn't rule it out either. I assume this would apply to other "apps" also. > For example something like: > m=application 54111 DTLS/SCTP 5000 > c=IN IP4 79.97.215.79 > a=sctpmap:5000 clue max-message-size=100000 streams=1 > a=sctpmap:5000 clue max-message-size=100000 streams=1 > a=sctpmap:5000 clue max-message-size=100000 streams=1 Do we need a "label" to uniquely identify a particular 'app' instance? > i.e. Similar to the optional label that draft-ietf-rtcweb-data-protocol uses. > e.g. a=sctpmap:5000 clue max-message-size=100000 streams=1 label1 > a=sctpmap:5000 clue max-message-size=100000 streams=1 label2 > a=sctpmap:5000 clue max-message-size=100000 streams=1 label3 > > Regards, Christian > > > On 14/02/2014 7:57 AM, Christer Holmberg wrote: >> Hi, >> I gave some comments off-line to Salvatore, which have been addressed >> in the new version. >> Some additional comments. I do realize some are pure editorial, but >> rather to write then down in some notes I put them directly into the >> e-mail J *Section 1:* >> *------------* >> *Q1**(EDITORIAL)**:* >> The text says: >> "Since >> no-one so far has implemented SCTP over TLS, due to some serious >> limitations described in [RFC6083], this document does not make use of >> TLS over SCTP as described in RFC3436 [RFC3436]." >> I suggest to simply say something like: >> "As described in [RFC6083], there are limitations associated with >> implementing SCTP over TLS. For that reason, SCTP over TLS is outside >> the scope of this document." >> *Q2**(EDITORIAL)**:* >> The text says: >> "Additionally, this document specifies the use of the 'setup' and >> 'connection' SDP attributes to establish SCTP associations. These >> attributes were defined in RFC4145 [RFC4145] for TCP. This document >> discusses their use with SCTP." >> I suggest to remove the last sentence, as it only repeats what is said >> in the first sentence. >> *Section 3:* >> *------------* >> *Q3 (EDITORIAL):* >> The text says: >> "This document defines three new values for the 'proto' field: 'SCTP', >> 'SCTP/DTLS' and 'DTLS/SCTP'." >> I would suggest to say: >> "This document defines three new *protocol identifier* values for the >> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." >> .because, you use "protocol identifier" terminology later. >> *Q4 (CLARIFICATION):* >> The text says: >> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST >> further qualify the application-layer protocol using an fmt >> identifier." >> I do understand what you are trying to say, but I think the "qualify" >> word is a little confusing. >> Maybe something like: >> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST >> further include an fmt value that identifies the application-layer >> protocol carried on top of the SCTP association." >> *Section 4.1:* >> *--------------* >> *Q5 (TECHNICAL):* >> The text says: >> "For the payload type assignments the "a=sctpmap:" >> attribute (see Section 5.1) SHOULD be used to map from a port number >> to a media encoding name that identifies the payload format >> transported by the association or the actual application protocol >> running on top of it." >> It is very difficult for me to parse this, and figure out the >> semantics of the sctpmap attribute. >> First, what do you mean by "media encoding name"? >> Second, when you talk about "application protocol", I assume you refer >> to the SCTP protocol? >> Third, the text say SHOULD. When is it ok to not use the sctpmap >> attribute? >> *Section **5**:* >> *------------* >> *Q6 (EDITORIAL):* >> I suggest to rename section 5 to "SDP sctpmap attribute", rename >> section 5.1 to "General", and add a new section 5.2 named "ABNF". >> *Q7 (TECHNICAL):* >> The text says: >> "The sctpmap MUST include the app parameter indicating the application >> running on top of the association." >> This is fine if the sctpmap attribute maps to an application. But, >> what if the sctpmap attribute maps to a "media encoding" or "payload"? >> *Q8 **(EDITORIAL):* >> The text says: >> "The sctpmap line should also contain the max-message-size parameter >> indicating the maximum message size, in bytes, the endpoint is willing >> to accept." >> I suggest to replace "accept" with "receive on the associated SCTP >> association". >> *Q9 (EDITORIAL):* >> The text says: >> "The peer should assume that larger message will be rejected by the >> endpoint, though it is up to the endpoint decide the appropriate >> behaviour." >> I suggest to either remove this paragraph, OR replace it with a >> sentence saying that a peer must/should not send messages bigger than >> the indicated max value. >> *Q10 (CLARIFICATION):* >> The text says: >> "If the parameter is not present, the implementation should provide a >> default, with a suggested value of 64K." >> I don't understand "suggested". If the default value is 64K the text >> should specify (rather than suggest) that. >> The same comment applies to the stream parameter, described later in >> the section. >> *Q11 (CLARIFICATION):* >> The text says: >> "It may also provide the stream parameter to specify the initial >> number of incoming streams to be supported by each side of the >> association." >> First, to be consistent with previous text, I suggest to replace "It >> may also provide" with "The sctpmap line may also contain" >> Second, I don't understand "incoming streams to be supported by each >> side of the association". Doesn't each peer indicate the number of >> streams it is willing to receive? Then, we can always recommend that >> the peer indicates the same number of streams, if possible. >> *Q12 (EDITORIAL):* >> The text that follows the ABNF should be put into a separate "SDP >> Offer/Answer Procedures" section. >> *Section 7:* >> *------------* >> *Q13 (EDITORIAL):* >> Please don't talk about re-INVITEs, or other SIP messages. Simply talk >> about offers and answers. >> *Q14 (EDITORIAL):* >> The text says: >> "It is worth to underline that when using SCTP on top of DTLS,.." >> To have consistent terminology, please say "SCTP over DTLS". >> That's all for now! :) >> Regards, >> Christer >> -----Alkuperäinen viesti----- >> Lähettäjä: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta >> internet-drafts@ietf.org >> Lähetetty: 13. helmikuuta 2014 16:21 >> Vastaanottaja: i-d-announce@ietf.org >> Kopio: mmusic@ietf.org >> Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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 : Stream Control Transmission Protocol (SCTP)-Based Media >> Transport in the Session Description Protocol (SDP) Authors : >> Salvatore Loreto Gonzalo Camarillo Filename : >> draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13 >> Abstract: >> SCTP (Stream Control Transmission Protocol) is a transport protocol >> used to establish associations between two endpoints. This document >> describes how to express media transport over SCTP in SDP (Session >> Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' >> and 'DTLS/SCTP' protocol identifiers for SDP. >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-06 >> 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 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Feb 14 01:21:50 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 A6F211A00BA for ; Fri, 14 Feb 2014 01:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=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 OuvWqFanhVHB for ; Fri, 14 Feb 2014 01:21:46 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id CDAA91A010D for ; Fri, 14 Feb 2014 01:21:45 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-2a-52fde027309e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id AA.20.04249.720EDF25; Fri, 14 Feb 2014 10:21:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 10:21:28 +0100 From: Christer Holmberg To: Christian Groves , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments Thread-Index: Ac8o/jG9d4h50B84TBauKcEd8AH/LQAD5tmAABD2C2AAAniQgAACJpFA Date: Fri, 14 Feb 2014 09:21:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D17278E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> <52FD59F3.7030306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17213B@ESESSMB209.ericsson.se> <52FDDC5B.40900@nteczone.com> In-Reply-To: <52FDDC5B.40900@nteczone.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvja76g79BBr8mGlt8ed/IYjF1+WMW ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugStj57Yu5oIloRUzfnA3MO5262Lk5JAQMJE4 c2EjI4QtJnHh3nq2LkYuDiGBI4wSnQ0zmCGcxYwS06Y9A8pwcLAJWEh0/9MGaRARiJaYtLCZ DcQWFkiW+HDiATNEPEXi+OlGKNtN4sKO26wgNouAqsSiT+/BbF4BX4m7305Dzb/MKPF5+i+w Bk4BLYnOpklgFzECXfT91BomEJtZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B8rhK0k8WPDJRaI ej2JG1OnsEHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxi5ChOLU7KTTcy 2MQIjIaDW35b7GC8/NfmEKM0B4uSOO/Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgT zC7/r7q8/lDSqo53cbO8u9c83jzzWY8Qm+TytzHvUv19Faaa3b8eytO75+hZHwHXc8/ibqbp JlY2Cc1+PeulBavF/Y8ndN/mCh2T2NrOKeiy8umRFUs9PT9F7WI+q6V1IsMjb0pRRaVPDscc I/7YkKiAybYO1xOXrW46ol+10NF6xqN5l24qsRRnJBpqMRcVJwIABqjv8FQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/9p1xlx0f_7tQX0dDP92PDuN44Ds Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 14 Feb 2014 09:21:48 -0000 Hi Christian, > I'm not assuming the use of webrtc-data channel. The issue would apply to= any "app" being used multiple times in an SCTP association. Correct.=20 My comment was not on multiple apps per SCTP association (which I agree was= the main focus of your e-mail), but simply on the example :) > Are you suggesting any time that you want to use multiple instances of an= "app" that you must use "webrtc-datachannel" even if there are no web brow= sers involved? No. Only if you want interoperability with a browser. BUT, even if there are no browser involved, you can still use the webrtc-da= tachannel if you want. The name should probably be changed to something mor= e generic, though. Regards, Christer On 14/02/2014 5:56 PM, Christer Holmberg wrote: > Hi Christian, > > A comment, based on your example. I don't think we would indicate "clue" = in the sctpmap attribute. We would indicate "webrtc-datachannel", in order = to be able to interwork with browsers. Then, on that webrtc-datachannel, we= would run the CLUE protocol (which we would negotiate e.g. using the DCP, = Richard's draft, or some other mechanism). > > Regards, > > Christer > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian=20 > Groves > Sent: 14. helmikuuta 2014 1:49 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt -=20 > Christer's initial comments > > Hello, > > Some further comments: > > Section 11.1 (Editorial) - 11.1 The first paragraph regarding 'sctpmap' > attribute appears to be repeated. > > Section 4.1 (Technical): I see the draft has removed the using using "bfc= p" and "t38" as values for the "App" field under one m-line. However that a= lso removes any hint about multiple a=3Dsctpmaps being used under one m-lin= e. For example should there be one a=3Dsctpmap per 'fmt' or could there be = zero or more a=3Dsctpmaps per 'fmt' in the m-line? If think this should be = clarified. > > General: There was a discussion on the CLUE mailing list whether there co= uld be multiple CLUE protocol instances per SCTP association. We couldn't i= dentify a use case but couldn't rule it out either. I assume this would app= ly to other "apps" also. > For example something like: > m=3Dapplication 54111 DTLS/SCTP 5000 > c=3DIN IP4 79.97.215.79 > a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 > a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 > a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 Do we need a = "label" to uniquely identify a particular 'app' instance? > i.e. Similar to the optional label that draft-ietf-rtcweb-data-protocol u= ses. > e.g. a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label1 > a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label2 > a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label3 > > Regards, Christian > > > On 14/02/2014 7:57 AM, Christer Holmberg wrote: >> Hi, >> I gave some comments off-line to Salvatore, which have been addressed=20 >> in the new version. >> Some additional comments. I do realize some are pure editorial, but=20 >> rather to write then down in some notes I put them directly into the=20 >> e-mail J *Section 1:* >> *------------* >> *Q1**(EDITORIAL)**:* >> The text says: >> "Since >> no-one so far has implemented SCTP over TLS, due to some serious=20 >> limitations described in [RFC6083], this document does not make use=20 >> of TLS over SCTP as described in RFC3436 [RFC3436]." >> I suggest to simply say something like: >> "As described in [RFC6083], there are limitations associated with=20 >> implementing SCTP over TLS. For that reason, SCTP over TLS is outside=20 >> the scope of this document." >> *Q2**(EDITORIAL)**:* >> The text says: >> "Additionally, this document specifies the use of the 'setup' and=20 >> 'connection' SDP attributes to establish SCTP associations. These=20 >> attributes were defined in RFC4145 [RFC4145] for TCP. This document=20 >> discusses their use with SCTP." >> I suggest to remove the last sentence, as it only repeats what is=20 >> said in the first sentence. >> *Section 3:* >> *------------* >> *Q3 (EDITORIAL):* >> The text says: >> "This document defines three new values for the 'proto' field:=20 >> 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." >> I would suggest to say: >> "This document defines three new *protocol identifier* values for the=20 >> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." >> .because, you use "protocol identifier" terminology later. >> *Q4 (CLARIFICATION):* >> The text says: >> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST=20 >> further qualify the application-layer protocol using an fmt=20 >> identifier." >> I do understand what you are trying to say, but I think the "qualify" >> word is a little confusing. >> Maybe something like: >> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST=20 >> further include an fmt value that identifies the application-layer=20 >> protocol carried on top of the SCTP association." >> *Section 4.1:* >> *--------------* >> *Q5 (TECHNICAL):* >> The text says: >> "For the payload type assignments the "a=3Dsctpmap:" >> attribute (see Section 5.1) SHOULD be used to map from a port number=20 >> to a media encoding name that identifies the payload format=20 >> transported by the association or the actual application protocol=20 >> running on top of it." >> It is very difficult for me to parse this, and figure out the=20 >> semantics of the sctpmap attribute. >> First, what do you mean by "media encoding name"? >> Second, when you talk about "application protocol", I assume you=20 >> refer to the SCTP protocol? >> Third, the text say SHOULD. When is it ok to not use the sctpmap=20 >> attribute? >> *Section **5**:* >> *------------* >> *Q6 (EDITORIAL):* >> I suggest to rename section 5 to "SDP sctpmap attribute", rename=20 >> section 5.1 to "General", and add a new section 5.2 named "ABNF". >> *Q7 (TECHNICAL):* >> The text says: >> "The sctpmap MUST include the app parameter indicating the=20 >> application running on top of the association." >> This is fine if the sctpmap attribute maps to an application. But,=20 >> what if the sctpmap attribute maps to a "media encoding" or "payload"? >> *Q8 **(EDITORIAL):* >> The text says: >> "The sctpmap line should also contain the max-message-size parameter=20 >> indicating the maximum message size, in bytes, the endpoint is=20 >> willing to accept." >> I suggest to replace "accept" with "receive on the associated SCTP=20 >> association". >> *Q9 (EDITORIAL):* >> The text says: >> "The peer should assume that larger message will be rejected by the=20 >> endpoint, though it is up to the endpoint decide the appropriate=20 >> behaviour." >> I suggest to either remove this paragraph, OR replace it with a=20 >> sentence saying that a peer must/should not send messages bigger than=20 >> the indicated max value. >> *Q10 (CLARIFICATION):* >> The text says: >> "If the parameter is not present, the implementation should provide a=20 >> default, with a suggested value of 64K." >> I don't understand "suggested". If the default value is 64K the text=20 >> should specify (rather than suggest) that. >> The same comment applies to the stream parameter, described later in=20 >> the section. >> *Q11 (CLARIFICATION):* >> The text says: >> "It may also provide the stream parameter to specify the initial=20 >> number of incoming streams to be supported by each side of the=20 >> association." >> First, to be consistent with previous text, I suggest to replace "It=20 >> may also provide" with "The sctpmap line may also contain" >> Second, I don't understand "incoming streams to be supported by each=20 >> side of the association". Doesn't each peer indicate the number of=20 >> streams it is willing to receive? Then, we can always recommend that=20 >> the peer indicates the same number of streams, if possible. >> *Q12 (EDITORIAL):* >> The text that follows the ABNF should be put into a separate "SDP=20 >> Offer/Answer Procedures" section. >> *Section 7:* >> *------------* >> *Q13 (EDITORIAL):* >> Please don't talk about re-INVITEs, or other SIP messages. Simply=20 >> talk about offers and answers. >> *Q14 (EDITORIAL):* >> The text says: >> "It is worth to underline that when using SCTP on top of DTLS,.." >> To have consistent terminology, please say "SCTP over DTLS". >> That's all for now! :) >> Regards, >> Christer >> -----Alkuper=E4inen viesti----- >> L=E4hett=E4j=E4: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta=20 >> internet-drafts@ietf.org >> L=E4hetetty: 13. helmikuuta 2014 16:21 >> Vastaanottaja: i-d-announce@ietf.org >> Kopio: mmusic@ietf.org >> Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt A New=20 >> Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> This draft is a work item of the Multiparty Multimedia Session=20 >> Control Working Group of the IETF. >> Title : Stream Control Transmission Protocol (SCTP)-Based Media=20 >> Transport in the Session Description Protocol (SDP) Authors : >> Salvatore Loreto Gonzalo Camarillo Filename : >> draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13 >> Abstract: >> SCTP (Stream Control Transmission Protocol) is a transport protocol=20 >> used to establish associations between two endpoints. This document=20 >> describes how to express media transport over SCTP in SDP (Session=20 >> Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' >> and 'DTLS/SCTP' protocol identifiers for SDP. >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-06 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org =20 >> 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 nobody Fri Feb 14 01:36:49 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 679C01A00F7 for ; Fri, 14 Feb 2014 01:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 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.548, 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 Jb-bfjOgDF3J for ; Fri, 14 Feb 2014 01:36:44 -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 CECD91A00A8 for ; Fri, 14 Feb 2014 01:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4143; q=dns/txt; s=iport; t=1392370602; x=1393580202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9mU9qnhmk9YgglNoeiyRACAWsdLcCRccxCuD1OAu73o=; b=ObSA7haMv24wohOgDBhwtr75JDoHHIwfLhIm7LxlRkuhULB1TO/gTem1 ysQ+diYn4RklooNYsrz+KtjOFcu5QDKlhsbEUQs1F6QmeBf9CXEW/x2jE ox9Htg2fR3+q8MIUR6DCYjPL4MCNS8q/csb7Npp8H4dM4yjQB5iefQdGv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAKLi/VKtJV2d/2dsb2JhbABZgwaBD78ygRYWdIIlAQEBAwEnUAIFCwIBCBguMiUCBA4Fh30IyG8XjiElMweDJIEUAQOUQ4NpkiOBb4E+gWhC X-IronPort-AV: E=Sophos;i="4.95,843,1384300800"; d="scan'208";a="20433573" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 14 Feb 2014 09:36:42 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1E9afjY017777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 09:36:42 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.214]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 03:36:41 -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: AQHPEFUUlb4N8W3Wl06M5kiJnPk5wZqUXPIAgAZGcwCAAv8DgIABtqYAgBS4XgCAAQMCgA== Date: Fri, 14 Feb 2014 09:36:41 +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> <7C0E6D63-D816-4415-B621-73A0309C6AB2@cisco.com> <52EA38C9.4070003@ericsson.com> <37A6AA83-867F-4DD1-A79D-081ECFA23B22@cisco.com> <52FD0A60.2040909@ericsson.com> In-Reply-To: <52FD0A60.2040909@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/h1UDbzVDOgfqf3a__8eI-5IZx4M 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, 14 Feb 2014 09:36:46 -0000 On 13 Feb 2014, at 19:09 pm, Ari Ker=E4nen wrote= : > On 31/01/14 15:44, Pal Martinsen (palmarti) wrote: >> On 30 Jan 2014, at 12:34 pm, Ari Ker=E4nen wr= ote: >>> On 28/01/14 15:49, Pal Martinsen (palmarti) wrote: > [...] >>> 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 connectivit= y checks done in cases where a) both support this with same promo algo b) b= oth support this but with different promo algo c) only one endpoint support= s this. >>>=20 >>=20 >> As I do believe in running code, I wrote a simple implementation of the = algorithm described below. >=20 > That's very nice, but unfortunately that didn't compile on my Mac so I=20 > couldn't give it a try. Runs fine on my mac. (Famous last words..) But I have ports installed with = gcc and the usual *NIX toolchain. Have not yet figured out to create a x-code project. If time permits.. I should probably have written it in phyton, but my skills in that language= is limited. =20 >=20 >>> Also maybe a recommended promo algo would make sense so that there is a= t least a fair chance that both will use the same algo/values and get most = out of this. >>>=20 >> First shot an an algorithm: >>=20 >> 5. Example Algorithm for Choosing the Local Preference >>=20 >> 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. >>=20 >> 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. >>=20 >> IPv6 IPv4 >> Start Start >> 65535 60k 59k 58k 57k 56k 55k 0 >> +--------+------+------+------+------+------+---------------------+ >> | | IPv6 | IPv4 | IPv6 | IPv4 | IPv6 | | >> | | (1) | (1) | (2) | (2) | (3) | | >> +--------+------+------+------+------+------+---------------------+ >> <- N-> >>=20 >>=20 >> The local preference can be calculated by the given formula: >>=20 >>=20 >> local_preference =3D N*2*(Cn/Cmax) >>=20 >> 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. >>=20 >=20 > Could you give an example how this algorithm and some priority values,=20 > e.g., from your program, result in the candidate pairs and order of=20 > checks? Especially the pairing part with respect to different types of=20 > candidates and IP families is where I'm afraid things may go wrong. >=20 I am struggling a bit with the RFC format, trying to create an readable lis= t that is of any use to the reader. The generated checklist will depend largely on what values the remote side = have chosen. If he the remote side for some reason gave all his candidates = a local_preference in the range 64000-65000 the above formula would have no= effect. If he chooses more =93normal=94 values we should see an effect. But the most important thing is that this does not break anything as the IC= E spec allows us to play with this value. My biggest concern now is how the unfrezing works. Reading 7.1.3.2.3 in the= ICE spec I realise that some of the sorting of the candidates regarding co= mponent might not be optimal, but not sure. Will mark this as an open quest= ion in the draft (Will post in a few hrs, so will not attempt to solve thi= s problem now.) .-. P=E5l-Erik >=20 > Cheers, > Ari >=20 From nobody Fri Feb 14 04:02:47 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 289451A0244 for ; Fri, 14 Feb 2014 04:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 A9UKEPpcOr1j for ; Fri, 14 Feb 2014 04:02:42 -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 F2AC71A0212 for ; Fri, 14 Feb 2014 04:02:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1245; q=dns/txt; s=iport; t=1392379360; x=1393588960; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=DUtHJ2CGsuMwp+DjrUpC1mZi5Q2e4I90nRCyhu8fDGw=; b=JECj4RIfYliNfRpRmu+Y80p7yo1TY3jk8EOv8XK/0nrYxTaHLKW2RHoE 6eBKFB5OiK1a9NcFMidRkYoxhMoL0JP2T0o4RRmbBfD0/KFOATgiquzOI gfD3JaBFcXhCPTZSeRMiphKtki7uw2fneO4/J5HO4SF0eSw2bRJRigVE4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIFAKQE/lKtJXG8/2dsb2JhbABZgwY4UQbASRZ0giYBAQR3EgIBTjIbCgIEHId8CAXIeheSJIEUBIkQjxyBMpBxgy2CKg X-IronPort-AV: E=Sophos;i="4.95,844,1384300800"; d="scan'208";a="20456284" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 14 Feb 2014 12:02:40 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1EC2eUh019936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Feb 2014 12:02:40 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.214]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 06:02:40 -0600 From: "Pal Martinsen (palmarti)" To: "mmusic (E-mail)" Thread-Topic: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-06.txt Thread-Index: AQHPKXsX0iDYWseijk6UBWh3GKb6UA== Date: Fri, 14 Feb 2014 12:02:39 +0000 Message-ID: <9AFF3A20-FA2D-4F02-ABD2-AE0EEA23E29B@cisco.com> References: <20140214115122.29863.77108.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6D2FC51D3110B141917C8CA2E9781F68@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/K7lYhfhli8zkY1U_T6ap2g8mGTY Subject: [MMUSIC] Fwd: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-06.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, 14 Feb 2014 12:02:44 -0000 Hi All, We have updated the ICE Happy Eyeballs draft to include an example algorith= m. (local_preference =3D N*2*(Cn/Cmax), se draft for details) Minor tweaks and improvements based on feedback on the list.=20 Usual submission details below: >=20 > A new version of I-D, draft-reddy-mmusic-ice-happy-eyeballs-06.txt > has been successfully submitted by Paal-Erik Martinsen and posted to the > IETF repository. >=20 > Name: draft-reddy-mmusic-ice-happy-eyeballs > Revision: 06 > Title: Happy Eyeballs Extension for ICE > Document date: 2014-02-14 > Group: Individual Submission > Pages: 11 > URL: http://www.ietf.org/internet-drafts/draft-reddy-mmusic-ic= e-happy-eyeballs-06.txt > Status: https://datatracker.ietf.org/doc/draft-reddy-mmusic-ice-h= appy-eyeballs/ > Htmlized: http://tools.ietf.org/html/draft-reddy-mmusic-ice-happy-e= yeballs-06 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-mmusic-ice= -happy-eyeballs-06 >=20 > Abstract: > This document provides guidelines on how to make Interactive > Connectivity Establishment (ICE) conclude faster in IPv4/IPv6 dual- > stack scenarios where broken paths exist. >=20 >=20 >=20 .-. P=E5l-Erik= From nobody Fri Feb 14 07:04: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 9872E1A0282 for ; Fri, 14 Feb 2014 07:04:04 -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 Oj5zMdWph23O for ; Fri, 14 Feb 2014 07:04:02 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4E1A026E for ; Fri, 14 Feb 2014 07:04:01 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-e1-52fe305f6219 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7C.D9.23809.F503EF25; Fri, 14 Feb 2014 16:03:59 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Feb 2014 16:03:59 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0DF8A110293; Fri, 14 Feb 2014 17:03:59 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 84ED65693E; Fri, 14 Feb 2014 17:03:54 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 36561563F4; Fri, 14 Feb 2014 17:03:54 +0200 (EET) Message-ID: <52FE305E.5050104@ericsson.com> Date: Fri, 14 Feb 2014 17:03:58 +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.3.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> <52EA38C9.4070003@ericsson.com> <37A6AA83-867F-4DD1-A79D-081ECFA23B22@cisco.com> <52FD0A60.2040909@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+JvjW68wb8gg84mPYupyx+zWLy/vpLF 4sTubYwOzB5Tfm9k9Viy5CdTAFMUl01Kak5mWWqRvl0CV8bDpZvYCp4pV5xvXsDUwDhbuouR g0NCwETiz6OMLkZOIFNM4sK99WxdjFwcQgKHGCXaPj1ghnA2MEp0TbvFDlIlJLCHUeLpTl2I xFpGiUcvL7BAOMsZJe5N3MACUsUroC2x7s8VNhCbRUBVonf/bUYQm03AUeL2w5esILaoQLLE p0WdjBD1ghInZz4B6xURMJZoPnIUbBuzQJDEo80XmEFsYYF4ie4H2xghlp1illjZ8xGsgVPA VuLzhrPMIP8wC9hLPNhaBtErL9G8dTYzxG9qElfPbWKG+EBV4uq/V4wTGEVnIVk9C6F7FpLu BYzMqxjZcxMzc9LLjTYxAsP/4JbfqjsY75wTOcQozcGiJM774a1zkJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQZG11+mkpvF+GvKbM7FhdtvDLKVYmq3MlrMfjppw43TVwz9r9hEa0o9OPZV 9u+cJ2XPeD9ekl8+RyPh9JM3qeJnn5i95DHTtmd4aly9drvczzrOHAvNhbOvbPq6K7Up4l3/ 12Urj5YXPLxlouJQH39UiJ+F4/Ed1/OKj1x0Ni3h5X3Yfr5j/satSizFGYmGWsxFxYkABJAD KE0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vuo2_FBwlq48itjSwauVjeTcd6Y 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, 14 Feb 2014 15:04:04 -0000 On 14/02/14 11:36, Pal Martinsen (palmarti) wrote: > > On 13 Feb 2014, at 19:09 pm, Ari Keränen wrote: > >> On 31/01/14 15:44, Pal Martinsen (palmarti) wrote: >>> On 30 Jan 2014, at 12:34 pm, Ari Keränen wrote: >>>> On 28/01/14 15:49, Pal Martinsen (palmarti) wrote: >> [...] >>>> 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. >>>> >>> >>> As I do believe in running code, I wrote a simple implementation of the algorithm described below. >> >> That's very nice, but unfortunately that didn't compile on my Mac so I >> couldn't give it a try. > > Runs fine on my mac. (Famous last words..) But I have ports installed with gcc and the usual *NIX toolchain. > Have not yet figured out to create a x-code project. If time permits.. > > I should probably have written it in phyton, but my skills in that language is limited. I have ports and gcc too, but probably missing something then. Will have to have a closer look at this later. >> >>>> 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. >>>> >>> 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-> >>> >>> >>> The local preference can be calculated by the given formula: >>> >>> >>> local_preference = 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. >>> >> >> Could you give an example how this algorithm and some priority values, >> e.g., from your program, result in the candidate pairs and order of >> checks? Especially the pairing part with respect to different types of >> candidates and IP families is where I'm afraid things may go wrong. >> > > I am struggling a bit with the RFC format, trying to create an readable list that is of any use to the reader. I didn't mean (necessarily) for the draft, but just on an e-mail, or what ever works for you, would be sufficient for now. > The generated checklist will depend largely on what values the remote side have chosen. If he the remote side for some reason gave all his candidates a local_preference in the range 64000-65000 the above formula would have no effect. If he chooses more “normal” values we should see an effect. Is this something that should be advised about in the draft? > But the most important thing is that this does not break anything as the ICE spec allows us to play with this value. That sounds good, but I'm still not 100% sure it works, and hence an example of the whole procedure with some realistic values would be nice. > My biggest concern now is how the unfrezing works. Reading 7.1.3.2.3 in the ICE spec I realise that some of the sorting of the candidates regarding component might not be optimal, but not sure. Will mark this as an open question in the draft (Will post in a few hrs, so will not attempt to solve this problem now.) OK. Cheers, Ari From nobody Fri Feb 14 09:34: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 0FE801A034D for ; Fri, 14 Feb 2014 09:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 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, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=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 j1u2MMiVnERg for ; Fri, 14 Feb 2014 09:34:03 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 24BA21A034F for ; Fri, 14 Feb 2014 09:34:03 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id SEK81n0070vyq2s55Ha1uh; Fri, 14 Feb 2014 17:34:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id SHa11n0093ZTu2S3RHa142; Fri, 14 Feb 2014 17:34:01 +0000 Message-ID: <52FE5389.40509@alum.mit.edu> Date: Fri, 14 Feb 2014 12:34:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> <52FD59F3.7030306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17213B@ESESSMB209.ericsson.se> <52FDDC5B.40900@nteczone.com> In-Reply-To: <52FDDC5B.40900@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392399241; bh=1+hDLSTy2/jz65168XLbdFhXNaWXNUxfGp8xygD4U9A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HkQXbNj1FBoPY2KPtar4QEuTfkmAk+J4a/4UFyuJl/7Yfe3RpOrO2yMTDS6ksQwO3 ZscyXmmwNjXasDo7j0GU4n9OXMXPrpJC8DzNyEEFp8txgIq5AfXqYLbhCFxOGKuXHu ul0R4Pz5d6veGAuarPzB7SMC11KEWD9Iaxc28u2W4leEGaYDd79zq3MMmCBJNXVHeE GT/xVx7gKo5PJuRcXP7PhebAa8jy81dRLDHeUQx4ZssfM86GFLnY3Quks2NUhcllMw PogyBb/zOOFeyz4p6LMDHyq9s/Zofg/LDPzmXW/f6feBAzo6StL+wDu3e9CGzt0qRZ 78tjoQBV83xNQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xdh6RhNn6B2SuxFQqXy-jXGx1fM Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 14 Feb 2014 17:34:06 -0000 On 2/14/14 4:05 AM, Christian Groves wrote: > Hello Christer, > > I'm not assuming the use of webrtc-data channel. The issue would apply > to any "app" being used multiple times in an SCTP association. > > Are you suggesting any time that you want to use multiple instances of > an "app" that you must use "webrtc-datachannel" even if there are no web > browsers involved? How do we *know* there won't be browsers involved? IMO we have a problem because the "webrtc-datachannel" suggests it necessarily has something to do with webrtc, when it need not. I'd like to see that name changed. The webrtc data channel just adds another layer of abstraction on top of SCTP, building bidirectional channels out of pairs of unidirectional streams. It also comes with an (optional) associated in-band protocol for dynamically establishing new channels over the sctp association, and with a defined javascript API that allows it to be used by browsers. The a=sctpmap attribute is used to negotiate a particular "usage" for the entire SCTP association - including all the streams within it. There may indeed be cases where an application has a specialized need for that. But in many cases it will be particular channels that the application needs, and it can use generic mechanisms, such as come with "webrtc-datachannel" to manage the individual channels. Certainly that is the vision in rtcweb (where the lower layer mechanisms aren't exposed). In the case of CLUE, we need one channel. It is fine with clue if the sctp association also carries other channels that it doesn't know about. If we were to use: a=sctpmap:5000 clue ... then we would be claiming the entire association for clue. The other channels wouldn't be available for anything else. And the clue channel wouldn't be accessible from a browser via webrtc. Thanks, Paul > Regards, Christian > > On 14/02/2014 5:56 PM, Christer Holmberg wrote: >> Hi Christian, >> >> A comment, based on your example. I don't think we would indicate >> "clue" in the sctpmap attribute. We would indicate >> "webrtc-datachannel", in order to be able to interwork with browsers. >> Then, on that webrtc-datachannel, we would run the CLUE protocol >> (which we would negotiate e.g. using the DCP, Richard's draft, or some >> other mechanism). >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian >> Groves >> Sent: 14. helmikuuta 2014 1:49 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - >> Christer's initial comments >> >> Hello, >> >> Some further comments: >> >> Section 11.1 (Editorial) - 11.1 The first paragraph regarding 'sctpmap' >> attribute appears to be repeated. >> >> Section 4.1 (Technical): I see the draft has removed the using using >> "bfcp" and "t38" as values for the "App" field under one m-line. >> However that also removes any hint about multiple a=sctpmaps being >> used under one m-line. For example should there be one a=sctpmap per >> 'fmt' or could there be zero or more a=sctpmaps per 'fmt' in the >> m-line? If think this should be clarified. >> >> General: There was a discussion on the CLUE mailing list whether there >> could be multiple CLUE protocol instances per SCTP association. We >> couldn't identify a use case but couldn't rule it out either. I assume >> this would apply to other "apps" also. >> For example something like: >> m=application 54111 DTLS/SCTP 5000 >> c=IN IP4 79.97.215.79 >> a=sctpmap:5000 clue max-message-size=100000 streams=1 >> a=sctpmap:5000 clue max-message-size=100000 streams=1 >> a=sctpmap:5000 clue max-message-size=100000 streams=1 Do we need a >> "label" to uniquely identify a particular 'app' instance? >> i.e. Similar to the optional label that >> draft-ietf-rtcweb-data-protocol uses. >> e.g. a=sctpmap:5000 clue max-message-size=100000 streams=1 label1 >> a=sctpmap:5000 clue max-message-size=100000 streams=1 label2 >> a=sctpmap:5000 clue max-message-size=100000 streams=1 label3 >> >> Regards, Christian >> >> >> On 14/02/2014 7:57 AM, Christer Holmberg wrote: >>> Hi, >>> I gave some comments off-line to Salvatore, which have been addressed >>> in the new version. >>> Some additional comments. I do realize some are pure editorial, but >>> rather to write then down in some notes I put them directly into the >>> e-mail J *Section 1:* >>> *------------* >>> *Q1**(EDITORIAL)**:* >>> The text says: >>> "Since >>> no-one so far has implemented SCTP over TLS, due to some serious >>> limitations described in [RFC6083], this document does not make use of >>> TLS over SCTP as described in RFC3436 [RFC3436]." >>> I suggest to simply say something like: >>> "As described in [RFC6083], there are limitations associated with >>> implementing SCTP over TLS. For that reason, SCTP over TLS is outside >>> the scope of this document." >>> *Q2**(EDITORIAL)**:* >>> The text says: >>> "Additionally, this document specifies the use of the 'setup' and >>> 'connection' SDP attributes to establish SCTP associations. These >>> attributes were defined in RFC4145 [RFC4145] for TCP. This document >>> discusses their use with SCTP." >>> I suggest to remove the last sentence, as it only repeats what is said >>> in the first sentence. >>> *Section 3:* >>> *------------* >>> *Q3 (EDITORIAL):* >>> The text says: >>> "This document defines three new values for the 'proto' field: 'SCTP', >>> 'SCTP/DTLS' and 'DTLS/SCTP'." >>> I would suggest to say: >>> "This document defines three new *protocol identifier* values for the >>> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." >>> .because, you use "protocol identifier" terminology later. >>> *Q4 (CLARIFICATION):* >>> The text says: >>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST >>> further qualify the application-layer protocol using an fmt >>> identifier." >>> I do understand what you are trying to say, but I think the "qualify" >>> word is a little confusing. >>> Maybe something like: >>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST >>> further include an fmt value that identifies the application-layer >>> protocol carried on top of the SCTP association." >>> *Section 4.1:* >>> *--------------* >>> *Q5 (TECHNICAL):* >>> The text says: >>> "For the payload type assignments the "a=sctpmap:" >>> attribute (see Section 5.1) SHOULD be used to map from a port number >>> to a media encoding name that identifies the payload format >>> transported by the association or the actual application protocol >>> running on top of it." >>> It is very difficult for me to parse this, and figure out the >>> semantics of the sctpmap attribute. >>> First, what do you mean by "media encoding name"? >>> Second, when you talk about "application protocol", I assume you refer >>> to the SCTP protocol? >>> Third, the text say SHOULD. When is it ok to not use the sctpmap >>> attribute? >>> *Section **5**:* >>> *------------* >>> *Q6 (EDITORIAL):* >>> I suggest to rename section 5 to "SDP sctpmap attribute", rename >>> section 5.1 to "General", and add a new section 5.2 named "ABNF". >>> *Q7 (TECHNICAL):* >>> The text says: >>> "The sctpmap MUST include the app parameter indicating the application >>> running on top of the association." >>> This is fine if the sctpmap attribute maps to an application. But, >>> what if the sctpmap attribute maps to a "media encoding" or "payload"? >>> *Q8 **(EDITORIAL):* >>> The text says: >>> "The sctpmap line should also contain the max-message-size parameter >>> indicating the maximum message size, in bytes, the endpoint is willing >>> to accept." >>> I suggest to replace "accept" with "receive on the associated SCTP >>> association". >>> *Q9 (EDITORIAL):* >>> The text says: >>> "The peer should assume that larger message will be rejected by the >>> endpoint, though it is up to the endpoint decide the appropriate >>> behaviour." >>> I suggest to either remove this paragraph, OR replace it with a >>> sentence saying that a peer must/should not send messages bigger than >>> the indicated max value. >>> *Q10 (CLARIFICATION):* >>> The text says: >>> "If the parameter is not present, the implementation should provide a >>> default, with a suggested value of 64K." >>> I don't understand "suggested". If the default value is 64K the text >>> should specify (rather than suggest) that. >>> The same comment applies to the stream parameter, described later in >>> the section. >>> *Q11 (CLARIFICATION):* >>> The text says: >>> "It may also provide the stream parameter to specify the initial >>> number of incoming streams to be supported by each side of the >>> association." >>> First, to be consistent with previous text, I suggest to replace "It >>> may also provide" with "The sctpmap line may also contain" >>> Second, I don't understand "incoming streams to be supported by each >>> side of the association". Doesn't each peer indicate the number of >>> streams it is willing to receive? Then, we can always recommend that >>> the peer indicates the same number of streams, if possible. >>> *Q12 (EDITORIAL):* >>> The text that follows the ABNF should be put into a separate "SDP >>> Offer/Answer Procedures" section. >>> *Section 7:* >>> *------------* >>> *Q13 (EDITORIAL):* >>> Please don't talk about re-INVITEs, or other SIP messages. Simply talk >>> about offers and answers. >>> *Q14 (EDITORIAL):* >>> The text says: >>> "It is worth to underline that when using SCTP on top of DTLS,.." >>> To have consistent terminology, please say "SCTP over DTLS". >>> That's all for now! :) >>> Regards, >>> Christer >>> -----Alkuperäinen viesti----- >>> Lähettäjä: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta >>> internet-drafts@ietf.org >>> Lähetetty: 13. helmikuuta 2014 16:21 >>> Vastaanottaja: i-d-announce@ietf.org >>> Kopio: mmusic@ietf.org >>> Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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 : Stream Control Transmission Protocol (SCTP)-Based Media >>> Transport in the Session Description Protocol (SDP) Authors : >>> Salvatore Loreto Gonzalo Camarillo Filename : >>> draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13 >>> Abstract: >>> SCTP (Stream Control Transmission Protocol) is a transport protocol >>> used to establish associations between two endpoints. This document >>> describes how to express media transport over SCTP in SDP (Session >>> Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' >>> and 'DTLS/SCTP' protocol identifiers for SDP. >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-06 >>> 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 >> _______________________________________________ >> 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 nobody Fri Feb 14 10:40: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 762621A0214 for ; Fri, 14 Feb 2014 10:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.5 X-Spam-Level: X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=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 X51ZuxLlvLXj for ; Fri, 14 Feb 2014 10:40:10 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8575E1A0063 for ; Fri, 14 Feb 2014 10:40:10 -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 s1EIe42b023756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 12:40:06 -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 s1EIe3pD000698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 19:40:03 +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; Fri, 14 Feb 2014 19:40:03 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Christian Groves , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments Thread-Index: Ac8o/jG9d4h50B84TBauKcEd8AH/LQAD5tmAABD2C2AAAniQgAACJpFAABLXDmA= Date: Fri, 14 Feb 2014 18:40:03 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1329A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> <52FD59F3.7030306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17213B@ESESSMB209.ericsson.se> <52FDDC5B.40900@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17278E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D17278E@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.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/F4l-RnGQ6YSiP_jn0DELqpKX0co Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 14 Feb 2014 18:40:14 -0000 Would agree to changing webrtc-data channel to something more generic. Keith > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Christer Holmberg > Sent: 14 February 2014 09:21 > To: Christian Groves; mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action:=20 > draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments >=20 > Hi Christian, >=20 > > I'm not assuming the use of webrtc-data channel. The issue=20 > would apply to any "app" being used multiple times in an SCTP=20 > association. >=20 > Correct.=20 >=20 > My comment was not on multiple apps per SCTP association=20 > (which I agree was the main focus of your e-mail), but simply=20 > on the example :) >=20 > > Are you suggesting any time that you want to use multiple=20 > instances of an "app" that you must use "webrtc-datachannel"=20 > even if there are no web browsers involved? >=20 > No. Only if you want interoperability with a browser. >=20 > BUT, even if there are no browser involved, you can still use=20 > the webrtc-datachannel if you want. The name should probably=20 > be changed to something more generic, though. >=20 > Regards, >=20 > Christer >=20 >=20 > On 14/02/2014 5:56 PM, Christer Holmberg wrote: > > Hi Christian, > > > > A comment, based on your example. I don't think we would=20 > indicate "clue" in the sctpmap attribute. We would indicate=20 > "webrtc-datachannel", in order to be able to interwork with=20 > browsers. Then, on that webrtc-datachannel, we would run the=20 > CLUE protocol (which we would negotiate e.g. using the DCP,=20 > Richard's draft, or some other mechanism). > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Christian=20 > > Groves > > Sent: 14. helmikuuta 2014 1:49 > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] I-D Action:=20 > draft-ietf-mmusic-sctp-sdp-06.txt -=20 > > Christer's initial comments > > > > Hello, > > > > Some further comments: > > > > Section 11.1 (Editorial) - 11.1 The first paragraph=20 > regarding 'sctpmap' > > attribute appears to be repeated. > > > > Section 4.1 (Technical): I see the draft has removed the=20 > using using "bfcp" and "t38" as values for the "App" field=20 > under one m-line. However that also removes any hint about=20 > multiple a=3Dsctpmaps being used under one m-line. For example=20 > should there be one a=3Dsctpmap per 'fmt' or could there be=20 > zero or more a=3Dsctpmaps per 'fmt' in the m-line? If think=20 > this should be clarified. > > > > General: There was a discussion on the CLUE mailing list=20 > whether there could be multiple CLUE protocol instances per=20 > SCTP association. We couldn't identify a use case but=20 > couldn't rule it out either. I assume this would apply to=20 > other "apps" also. > > For example something like: > > m=3Dapplication 54111 DTLS/SCTP 5000 > > c=3DIN IP4 79.97.215.79 > > a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1=20 > a=3Dsctpmap:5000=20 > > clue max-message-size=3D100000 streams=3D1 a=3Dsctpmap:5000 clue=20 > > max-message-size=3D100000 streams=3D1 Do we need a "label" to=20 > uniquely identify a particular 'app' instance? > > i.e. Similar to the optional label that=20 > draft-ietf-rtcweb-data-protocol uses. > > e.g. a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label1= =20 > > a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label2=20 > > a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label3 > > > > Regards, Christian > > > > > > On 14/02/2014 7:57 AM, Christer Holmberg wrote: > >> Hi, > >> I gave some comments off-line to Salvatore, which have=20 > been addressed=20 > >> in the new version. > >> Some additional comments. I do realize some are pure=20 > editorial, but=20 > >> rather to write then down in some notes I put them=20 > directly into the=20 > >> e-mail J *Section 1:* > >> *------------* > >> *Q1**(EDITORIAL)**:* > >> The text says: > >> "Since > >> no-one so far has implemented SCTP over TLS, due to some serious=20 > >> limitations described in [RFC6083], this document does not=20 > make use=20 > >> of TLS over SCTP as described in RFC3436 [RFC3436]." > >> I suggest to simply say something like: > >> "As described in [RFC6083], there are limitations associated with=20 > >> implementing SCTP over TLS. For that reason, SCTP over TLS=20 > is outside=20 > >> the scope of this document." > >> *Q2**(EDITORIAL)**:* > >> The text says: > >> "Additionally, this document specifies the use of the 'setup' and=20 > >> 'connection' SDP attributes to establish SCTP associations. These=20 > >> attributes were defined in RFC4145 [RFC4145] for TCP. This=20 > document=20 > >> discusses their use with SCTP." > >> I suggest to remove the last sentence, as it only repeats what is=20 > >> said in the first sentence. > >> *Section 3:* > >> *------------* > >> *Q3 (EDITORIAL):* > >> The text says: > >> "This document defines three new values for the 'proto' field:=20 > >> 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." > >> I would suggest to say: > >> "This document defines three new *protocol identifier*=20 > values for the=20 > >> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." > >> .because, you use "protocol identifier" terminology later. > >> *Q4 (CLARIFICATION):* > >> The text says: > >> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or=20 > 'DTLS/SCTP' MUST=20 > >> further qualify the application-layer protocol using an fmt=20 > >> identifier." > >> I do understand what you are trying to say, but I think=20 > the "qualify" > >> word is a little confusing. > >> Maybe something like: > >> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or=20 > 'DTLS/SCTP' MUST=20 > >> further include an fmt value that identifies the application-layer=20 > >> protocol carried on top of the SCTP association." > >> *Section 4.1:* > >> *--------------* > >> *Q5 (TECHNICAL):* > >> The text says: > >> "For the payload type assignments the "a=3Dsctpmap:" > >> attribute (see Section 5.1) SHOULD be used to map from a=20 > port number=20 > >> to a media encoding name that identifies the payload format=20 > >> transported by the association or the actual application protocol=20 > >> running on top of it." > >> It is very difficult for me to parse this, and figure out the=20 > >> semantics of the sctpmap attribute. > >> First, what do you mean by "media encoding name"? > >> Second, when you talk about "application protocol", I assume you=20 > >> refer to the SCTP protocol? > >> Third, the text say SHOULD. When is it ok to not use the sctpmap=20 > >> attribute? > >> *Section **5**:* > >> *------------* > >> *Q6 (EDITORIAL):* > >> I suggest to rename section 5 to "SDP sctpmap attribute", rename=20 > >> section 5.1 to "General", and add a new section 5.2 named "ABNF". > >> *Q7 (TECHNICAL):* > >> The text says: > >> "The sctpmap MUST include the app parameter indicating the=20 > >> application running on top of the association." > >> This is fine if the sctpmap attribute maps to an application. But,=20 > >> what if the sctpmap attribute maps to a "media encoding"=20 > or "payload"? > >> *Q8 **(EDITORIAL):* > >> The text says: > >> "The sctpmap line should also contain the max-message-size=20 > parameter=20 > >> indicating the maximum message size, in bytes, the endpoint is=20 > >> willing to accept." > >> I suggest to replace "accept" with "receive on the associated SCTP=20 > >> association". > >> *Q9 (EDITORIAL):* > >> The text says: > >> "The peer should assume that larger message will be=20 > rejected by the=20 > >> endpoint, though it is up to the endpoint decide the appropriate=20 > >> behaviour." > >> I suggest to either remove this paragraph, OR replace it with a=20 > >> sentence saying that a peer must/should not send messages=20 > bigger than=20 > >> the indicated max value. > >> *Q10 (CLARIFICATION):* > >> The text says: > >> "If the parameter is not present, the implementation=20 > should provide a=20 > >> default, with a suggested value of 64K." > >> I don't understand "suggested". If the default value is=20 > 64K the text=20 > >> should specify (rather than suggest) that. > >> The same comment applies to the stream parameter,=20 > described later in=20 > >> the section. > >> *Q11 (CLARIFICATION):* > >> The text says: > >> "It may also provide the stream parameter to specify the initial=20 > >> number of incoming streams to be supported by each side of the=20 > >> association." > >> First, to be consistent with previous text, I suggest to=20 > replace "It=20 > >> may also provide" with "The sctpmap line may also contain" > >> Second, I don't understand "incoming streams to be=20 > supported by each=20 > >> side of the association". Doesn't each peer indicate the number of=20 > >> streams it is willing to receive? Then, we can always=20 > recommend that=20 > >> the peer indicates the same number of streams, if possible. > >> *Q12 (EDITORIAL):* > >> The text that follows the ABNF should be put into a separate "SDP=20 > >> Offer/Answer Procedures" section. > >> *Section 7:* > >> *------------* > >> *Q13 (EDITORIAL):* > >> Please don't talk about re-INVITEs, or other SIP messages. Simply=20 > >> talk about offers and answers. > >> *Q14 (EDITORIAL):* > >> The text says: > >> "It is worth to underline that when using SCTP on top of DTLS,.." > >> To have consistent terminology, please say "SCTP over DTLS". > >> That's all for now! :) > >> Regards, > >> Christer > >> -----Alkuper=E4inen viesti----- > >> L=E4hett=E4j=E4: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta=20 > >> internet-drafts@ietf.org > >> L=E4hetetty: 13. helmikuuta 2014 16:21 > >> Vastaanottaja: i-d-announce@ietf.org > >> Kopio: mmusic@ietf.org > >> Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt A New=20 > >> Internet-Draft is available from the on-line Internet-Drafts=20 > >> directories. > >> This draft is a work item of the Multiparty Multimedia Session=20 > >> Control Working Group of the IETF. > >> Title : Stream Control Transmission Protocol (SCTP)-Based Media=20 > >> Transport in the Session Description Protocol (SDP) Authors : > >> Salvatore Loreto Gonzalo Camarillo Filename : > >> draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13 > >> Abstract: > >> SCTP (Stream Control Transmission Protocol) is a transport=20 > protocol=20 > >> used to establish associations between two endpoints. This=20 > document=20 > >> describes how to express media transport over SCTP in SDP (Session=20 > >> Description Protocol). This document defines the 'SCTP',=20 > 'SCTP/DTLS' > >> and 'DTLS/SCTP' protocol identifiers for SDP. > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-06 > >> Please note that it may take a couple of minutes from the time of=20 > >> submission until the htmlized version and diff are available at=20 > >> tools.ietf.org. > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org =20 > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From nobody Fri Feb 14 11:47:05 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 118DB1A0375 for ; Fri, 14 Feb 2014 11:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 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, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=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 MLX1eerHukWL for ; Fri, 14 Feb 2014 11:47:00 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id ADB921A03F1 for ; Fri, 14 Feb 2014 11:42:24 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id SKCL1n0011YDfWL58KiNka; Fri, 14 Feb 2014 19:42:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id SKiN1n00g3ZTu2S3gKiN7C; Fri, 14 Feb 2014 19:42:22 +0000 Message-ID: <52FE719E.70209@alum.mit.edu> Date: Fri, 14 Feb 2014 14:42:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> <52FD59F3.7030306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17213B@ESESSMB209.ericsson.se> <52FDDC5B.40900@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17278E@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B1329A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1329A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392406942; bh=qQ9ZGCQbVF80HiVM2X36HULGg8Z9BGh/xEmVjtfCm+A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JxUHm/ywNBdvXCl419Wtao2rchPtB73cyVlzO686ENJGYJNuCJBI7xa9P/bGqQKuK p0nTpWxnbjL4RZv/ewLyMq4Ekz9gSAfKhqshPjnAq05uY6REODmTqYfrkWXkxgf1pZ kQrkPyQuQOxwgf5dl+teWsznwkIPxhNRCFlyI7a0WfUz2AuumuuBV/P8f8mE2Ql8gI qBZdS8sU4pl7my6PwMrpYPIj4qzc79idG4SFSQXNR5rmMLKY8kJzLkTLn88P9rLerw +M66qF9FeFK3FGix3y0PXQ5oA/84KaKAEsrY0b/M94vmOQN4PatatLwbGkABr/BIBo uRWEdTMttKmNw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/n-YANn23XPmkLQHlb2nOJAqcGos Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 14 Feb 2014 19:47:02 -0000 On 2/14/14 1:40 PM, DRAGE, Keith (Keith) wrote: > Would agree to changing webrtc-data channel to something more generic. A couple of possibilities that would WFM: - sctp-data-channel (or sctp-datachannel) - data-channel (or datachannel) The latter is appealing, but may be *too* generic. Thanks, Paul > Keith > >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of >> Christer Holmberg >> Sent: 14 February 2014 09:21 >> To: Christian Groves; mmusic@ietf.org >> Subject: Re: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments >> >> Hi Christian, >> >>> I'm not assuming the use of webrtc-data channel. The issue >> would apply to any "app" being used multiple times in an SCTP >> association. >> >> Correct. >> >> My comment was not on multiple apps per SCTP association >> (which I agree was the main focus of your e-mail), but simply >> on the example :) >> >>> Are you suggesting any time that you want to use multiple >> instances of an "app" that you must use "webrtc-datachannel" >> even if there are no web browsers involved? >> >> No. Only if you want interoperability with a browser. >> >> BUT, even if there are no browser involved, you can still use >> the webrtc-datachannel if you want. The name should probably >> be changed to something more generic, though. >> >> Regards, >> >> Christer >> >> >> On 14/02/2014 5:56 PM, Christer Holmberg wrote: >>> Hi Christian, >>> >>> A comment, based on your example. I don't think we would >> indicate "clue" in the sctpmap attribute. We would indicate >> "webrtc-datachannel", in order to be able to interwork with >> browsers. Then, on that webrtc-datachannel, we would run the >> CLUE protocol (which we would negotiate e.g. using the DCP, >> Richard's draft, or some other mechanism). >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of >> Christian >>> Groves >>> Sent: 14. helmikuuta 2014 1:49 >>> To: mmusic@ietf.org >>> Subject: Re: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sctp-sdp-06.txt - >>> Christer's initial comments >>> >>> Hello, >>> >>> Some further comments: >>> >>> Section 11.1 (Editorial) - 11.1 The first paragraph >> regarding 'sctpmap' >>> attribute appears to be repeated. >>> >>> Section 4.1 (Technical): I see the draft has removed the >> using using "bfcp" and "t38" as values for the "App" field >> under one m-line. However that also removes any hint about >> multiple a=sctpmaps being used under one m-line. For example >> should there be one a=sctpmap per 'fmt' or could there be >> zero or more a=sctpmaps per 'fmt' in the m-line? If think >> this should be clarified. >>> >>> General: There was a discussion on the CLUE mailing list >> whether there could be multiple CLUE protocol instances per >> SCTP association. We couldn't identify a use case but >> couldn't rule it out either. I assume this would apply to >> other "apps" also. >>> For example something like: >>> m=application 54111 DTLS/SCTP 5000 >>> c=IN IP4 79.97.215.79 >>> a=sctpmap:5000 clue max-message-size=100000 streams=1 >> a=sctpmap:5000 >>> clue max-message-size=100000 streams=1 a=sctpmap:5000 clue >>> max-message-size=100000 streams=1 Do we need a "label" to >> uniquely identify a particular 'app' instance? >>> i.e. Similar to the optional label that >> draft-ietf-rtcweb-data-protocol uses. >>> e.g. a=sctpmap:5000 clue max-message-size=100000 streams=1 label1 >>> a=sctpmap:5000 clue max-message-size=100000 streams=1 label2 >>> a=sctpmap:5000 clue max-message-size=100000 streams=1 label3 >>> >>> Regards, Christian >>> >>> >>> On 14/02/2014 7:57 AM, Christer Holmberg wrote: >>>> Hi, >>>> I gave some comments off-line to Salvatore, which have >> been addressed >>>> in the new version. >>>> Some additional comments. I do realize some are pure >> editorial, but >>>> rather to write then down in some notes I put them >> directly into the >>>> e-mail J *Section 1:* >>>> *------------* >>>> *Q1**(EDITORIAL)**:* >>>> The text says: >>>> "Since >>>> no-one so far has implemented SCTP over TLS, due to some serious >>>> limitations described in [RFC6083], this document does not >> make use >>>> of TLS over SCTP as described in RFC3436 [RFC3436]." >>>> I suggest to simply say something like: >>>> "As described in [RFC6083], there are limitations associated with >>>> implementing SCTP over TLS. For that reason, SCTP over TLS >> is outside >>>> the scope of this document." >>>> *Q2**(EDITORIAL)**:* >>>> The text says: >>>> "Additionally, this document specifies the use of the 'setup' and >>>> 'connection' SDP attributes to establish SCTP associations. These >>>> attributes were defined in RFC4145 [RFC4145] for TCP. This >> document >>>> discusses their use with SCTP." >>>> I suggest to remove the last sentence, as it only repeats what is >>>> said in the first sentence. >>>> *Section 3:* >>>> *------------* >>>> *Q3 (EDITORIAL):* >>>> The text says: >>>> "This document defines three new values for the 'proto' field: >>>> 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." >>>> I would suggest to say: >>>> "This document defines three new *protocol identifier* >> values for the >>>> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." >>>> .because, you use "protocol identifier" terminology later. >>>> *Q4 (CLARIFICATION):* >>>> The text says: >>>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or >> 'DTLS/SCTP' MUST >>>> further qualify the application-layer protocol using an fmt >>>> identifier." >>>> I do understand what you are trying to say, but I think >> the "qualify" >>>> word is a little confusing. >>>> Maybe something like: >>>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or >> 'DTLS/SCTP' MUST >>>> further include an fmt value that identifies the application-layer >>>> protocol carried on top of the SCTP association." >>>> *Section 4.1:* >>>> *--------------* >>>> *Q5 (TECHNICAL):* >>>> The text says: >>>> "For the payload type assignments the "a=sctpmap:" >>>> attribute (see Section 5.1) SHOULD be used to map from a >> port number >>>> to a media encoding name that identifies the payload format >>>> transported by the association or the actual application protocol >>>> running on top of it." >>>> It is very difficult for me to parse this, and figure out the >>>> semantics of the sctpmap attribute. >>>> First, what do you mean by "media encoding name"? >>>> Second, when you talk about "application protocol", I assume you >>>> refer to the SCTP protocol? >>>> Third, the text say SHOULD. When is it ok to not use the sctpmap >>>> attribute? >>>> *Section **5**:* >>>> *------------* >>>> *Q6 (EDITORIAL):* >>>> I suggest to rename section 5 to "SDP sctpmap attribute", rename >>>> section 5.1 to "General", and add a new section 5.2 named "ABNF". >>>> *Q7 (TECHNICAL):* >>>> The text says: >>>> "The sctpmap MUST include the app parameter indicating the >>>> application running on top of the association." >>>> This is fine if the sctpmap attribute maps to an application. But, >>>> what if the sctpmap attribute maps to a "media encoding" >> or "payload"? >>>> *Q8 **(EDITORIAL):* >>>> The text says: >>>> "The sctpmap line should also contain the max-message-size >> parameter >>>> indicating the maximum message size, in bytes, the endpoint is >>>> willing to accept." >>>> I suggest to replace "accept" with "receive on the associated SCTP >>>> association". >>>> *Q9 (EDITORIAL):* >>>> The text says: >>>> "The peer should assume that larger message will be >> rejected by the >>>> endpoint, though it is up to the endpoint decide the appropriate >>>> behaviour." >>>> I suggest to either remove this paragraph, OR replace it with a >>>> sentence saying that a peer must/should not send messages >> bigger than >>>> the indicated max value. >>>> *Q10 (CLARIFICATION):* >>>> The text says: >>>> "If the parameter is not present, the implementation >> should provide a >>>> default, with a suggested value of 64K." >>>> I don't understand "suggested". If the default value is >> 64K the text >>>> should specify (rather than suggest) that. >>>> The same comment applies to the stream parameter, >> described later in >>>> the section. >>>> *Q11 (CLARIFICATION):* >>>> The text says: >>>> "It may also provide the stream parameter to specify the initial >>>> number of incoming streams to be supported by each side of the >>>> association." >>>> First, to be consistent with previous text, I suggest to >> replace "It >>>> may also provide" with "The sctpmap line may also contain" >>>> Second, I don't understand "incoming streams to be >> supported by each >>>> side of the association". Doesn't each peer indicate the number of >>>> streams it is willing to receive? Then, we can always >> recommend that >>>> the peer indicates the same number of streams, if possible. >>>> *Q12 (EDITORIAL):* >>>> The text that follows the ABNF should be put into a separate "SDP >>>> Offer/Answer Procedures" section. >>>> *Section 7:* >>>> *------------* >>>> *Q13 (EDITORIAL):* >>>> Please don't talk about re-INVITEs, or other SIP messages. Simply >>>> talk about offers and answers. >>>> *Q14 (EDITORIAL):* >>>> The text says: >>>> "It is worth to underline that when using SCTP on top of DTLS,.." >>>> To have consistent terminology, please say "SCTP over DTLS". >>>> That's all for now! :) >>>> Regards, >>>> Christer >>>> -----Alkuperäinen viesti----- >>>> Lähettäjä: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta >>>> internet-drafts@ietf.org >>>> Lähetetty: 13. helmikuuta 2014 16:21 >>>> Vastaanottaja: i-d-announce@ietf.org >>>> Kopio: mmusic@ietf.org >>>> Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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 : Stream Control Transmission Protocol (SCTP)-Based Media >>>> Transport in the Session Description Protocol (SDP) Authors : >>>> Salvatore Loreto Gonzalo Camarillo Filename : >>>> draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13 >>>> Abstract: >>>> SCTP (Stream Control Transmission Protocol) is a transport >> protocol >>>> used to establish associations between two endpoints. This >> document >>>> describes how to express media transport over SCTP in SDP (Session >>>> Description Protocol). This document defines the 'SCTP', >> 'SCTP/DTLS' >>>> and 'DTLS/SCTP' protocol identifiers for SDP. >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-06 >>>> 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 >>> _______________________________________________ >>> 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 nobody Fri Feb 14 11:47: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 262F51A03AC; Fri, 14 Feb 2014 11:47:45 -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 S53_7OhcD04O; Fri, 14 Feb 2014 11:47:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A31A91A040D; Fri, 14 Feb 2014 11:43:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214194344.27285.26438.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 11:43:44 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/WsmwykABkFy_ajqt1adBA2leKpI Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-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, 14 Feb 2014 19:47:45 -0000 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 Framework for SDP Attributes when Multiplexing Author : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-01.txt Pages : 60 Date : 2014-02-14 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. The specification also categorizes existing attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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 nobody Fri Feb 14 13:00:10 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 053551A0388; Fri, 14 Feb 2014 13:00:04 -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_14=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 K7W_CPq1bqb9; Fri, 14 Feb 2014 13:00:00 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CB6D41A02C0; Fri, 14 Feb 2014 13:00:00 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1EKxwCB009688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 14:59:59 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s1EKxvVO032725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 15:59:58 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 15:59:58 -0500 From: "Makaraju, Maridi Raju (Raju)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt Thread-Index: AQHPKMcNA14JXusW30OXPTGL3fJhS5q1OZ+w Date: Fri, 14 Feb 2014 20:59:57 +0000 Message-ID: References: <20140213142037.9494.98174.idtracker@ietfa.amsl.com> In-Reply-To: <20140213142037.9494.98174.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3siGt1eG5IcL1sY8SXQfui8cLKE Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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, 14 Feb 2014 21:00:04 -0000 >4.1 a=3Dsctpmap:5000 webrtc-datachannel max-message-size=3D100000 s= treams=3D16 >9.3 a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 s= treams=3D16 >11.1 'app' parameter and register as first value "webrtc-datachannel" fo= r [Raju] Above three types of representations of "webrtc-datachannel" should use a s= ingle value; The value may be based on the outcome from discussion that is going on a di= fferent thread. > a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 streams=3D1= 6 [Raju] Instead of putting webrtc data channel attributes on the same line (= which gets long),=20 how about using existing a=3Dfmtp? as in: a=3Dfmtp:5000 max-message-size=3D100000 streams=3D16 or how about even further shortening it to? a=3Dfmtp:5000 mms=3D100000; streams=3D16 Then these attributes of 'app' protocol can be defined either in rtcweb-dat= a-channel and then IANA (section 11.1) will have a reference to it. Any such attribut= es defined=20 for this or any generic 'app' protocol are carried in a=3Dfmtp line transpa= rently. Regards Raju > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, February 13, 2014 8:21 AM > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt >=20 >=20 > 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. >=20 > Title : Stream Control Transmission Protocol (SCTP)-Bas= ed > Media Transport in the Session Description Protocol (SDP) > Authors : Salvatore Loreto > Gonzalo Camarillo > Filename : draft-ietf-mmusic-sctp-sdp-06.txt > Pages : 14 > Date : 2014-02-13 >=20 > Abstract: > SCTP (Stream Control Transmission Protocol) is a transport protocol > used to establish associations between two endpoints. This document > describes how to express media transport over SCTP in SDP (Session > Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' > and 'DTLS/SCTP' protocol identifiers for SDP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Feb 14 13:07: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 350381A0408 for ; Fri, 14 Feb 2014 13:07:56 -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 laEjum0YsuHP for ; Fri, 14 Feb 2014 13:07:54 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 766D01A03FE for ; Fri, 14 Feb 2014 13:07:51 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1EL7mb5022494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 15:07:48 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s1EL7lt8032662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 16:07:47 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 16:07:47 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments Thread-Index: AQHPKbzgdLGEXsSfQESRpyGCHNa63Jq1NDUg Date: Fri, 14 Feb 2014 21:07:47 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> <52FD59F3.7030306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17213B@ESESSMB209.ericsson.se> <52FDDC5B.40900@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17278E@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B1329A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52FE719E.70209@alum.mit.edu> In-Reply-To: <52FE719E.70209@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DaJOdQw4bIBJZ2QeC3ZdwA2SRzI Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 14 Feb 2014 21:07:56 -0000 > On 2/14/14 1:40 PM, DRAGE, Keith (Keith) wrote: > > Would agree to changing webrtc-data channel to something more generic. >=20 > A couple of possibilities that would WFM: >=20 > - sctp-data-channel (or sctp-datachannel) > - data-channel (or datachannel) >=20 > The latter is appealing, but may be *too* generic. [Raju] I am ok with either options.=20 However, "sctp-datachannel" probably more appropriate as for external negot= iation=20 point of view, datachannel provides a bidrectional communication channel wi= th=20 one SCTP stream, using same stream id, in both the directions. "sctp-datach= annel" name captures that well. Regards Raju From nobody Fri Feb 14 15:43: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 4A49B1A051C for ; Fri, 14 Feb 2014 15:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77] 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 1KezmgB9UQcF for ; Fri, 14 Feb 2014 15:43:27 -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 A5DAD1A0517 for ; Fri, 14 Feb 2014 15:43:27 -0800 (PST) Received: from host-7-31.mv.mozilla.com (corp-240.mv.mozilla.com [63.245.220.240]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1ENhOOp058427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 14 Feb 2014 17:43:25 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52FEAA17.9070406@nostrum.com> Date: Fri, 14 Feb 2014 15:43:19 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="------------080603090805070302040501" Received-SPF: pass (shaman.nostrum.com: 63.245.220.240 is authenticated by a trusted mechanism) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/54cPEFaKR6O4WYfhP_OyWqt6IQ4 Subject: [MMUSIC] POF/PAN draft update 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, 14 Feb 2014 23:43:29 -0000 This is a multi-part message in MIME format. --------------080603090805070302040501 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I've updated the partial offer/partial answer draft to reflect the conversations we had in Vancouver: http://tools.ietf.org/html/draft-roach-mmusic-pof-pan-02 Diffs: http://tools.ietf.org/rfcdiff?url2=draft-roach-mmusic-pof-pan-02.txt Note that this relies on the following draft for group membership manipulation: http://tools.ietf.org/html/draft-roach-mmusic-groupid Please point out whether you think I've missed any of the Vancouver discussions or other feedback. Thanks! /a --------------080603090805070302040501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit I've updated the partial offer/partial answer draft to reflect the conversations we had in Vancouver:
http://tools.ietf.org/html/draft-roach-mmusic-pof-pan-02

Diffs: http://tools.ietf.org/rfcdiff?url2=draft-roach-mmusic-pof-pan-02.txt

Note that this relies on the following draft for group membership manipulation:
http://tools.ietf.org/html/draft-roach-mmusic-groupid

Please point out whether you think I've missed any of the Vancouver discussions or other feedback. Thanks!

/a
--------------080603090805070302040501-- From nobody Fri Feb 14 18:10: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 D33341A02A4 for ; Fri, 14 Feb 2014 18:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.5 X-Spam-Level: X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=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 cICnVw_2HWgf for ; Fri, 14 Feb 2014 18:10:12 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC361A001F for ; Fri, 14 Feb 2014 18:10:12 -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 s1F2A7vv016920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 20:10:08 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1F2A6Ho030488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Feb 2014 03:10:06 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sat, 15 Feb 2014 03:10:06 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments Thread-Index: AQHPKbzgd4h50B84TBauKcEd8AH/LZq1khaA Date: Sat, 15 Feb 2014 02:10:05 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B132FA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D17183E@ESESSMB209.ericsson.se> <52FD59F3.7030306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17213B@ESESSMB209.ericsson.se> <52FDDC5B.40900@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D17278E@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B1329A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52FE719E.70209@alum.mit.edu> In-Reply-To: <52FE719E.70209@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/wyUa0Yiny-480TLUOtwJkDpvGMk Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments 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, 15 Feb 2014 02:10:16 -0000 I'd be happy with either. I've just submitted draft-ejzak-mmusic-data-channel-sdpneg using the term "= data channel" in the text, but the SDP is still aligned with the sctp-sdp d= raft. Keith=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Paul Kyzivat > Sent: 14 February 2014 19:42 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action:=20 > draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments >=20 > On 2/14/14 1:40 PM, DRAGE, Keith (Keith) wrote: > > Would agree to changing webrtc-data channel to something=20 > more generic. >=20 > A couple of possibilities that would WFM: >=20 > - sctp-data-channel (or sctp-datachannel) > - data-channel (or datachannel) >=20 > The latter is appealing, but may be *too* generic. >=20 > Thanks, > Paul >=20 > > Keith > > > >> -----Original Message----- > >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Christer=20 > >> Holmberg > >> Sent: 14 February 2014 09:21 > >> To: Christian Groves; mmusic@ietf.org > >> Subject: Re: [MMUSIC] I-D Action: > >> draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments > >> > >> Hi Christian, > >> > >>> I'm not assuming the use of webrtc-data channel. The issue > >> would apply to any "app" being used multiple times in an SCTP=20 > >> association. > >> > >> Correct. > >> > >> My comment was not on multiple apps per SCTP association (which I=20 > >> agree was the main focus of your e-mail), but simply on=20 > the example=20 > >> :) > >> > >>> Are you suggesting any time that you want to use multiple > >> instances of an "app" that you must use "webrtc-datachannel" > >> even if there are no web browsers involved? > >> > >> No. Only if you want interoperability with a browser. > >> > >> BUT, even if there are no browser involved, you can still use the=20 > >> webrtc-datachannel if you want. The name should probably=20 > be changed=20 > >> to something more generic, though. > >> > >> Regards, > >> > >> Christer > >> > >> > >> On 14/02/2014 5:56 PM, Christer Holmberg wrote: > >>> Hi Christian, > >>> > >>> A comment, based on your example. I don't think we would > >> indicate "clue" in the sctpmap attribute. We would indicate=20 > >> "webrtc-datachannel", in order to be able to interwork=20 > with browsers.=20 > >> Then, on that webrtc-datachannel, we would run the CLUE protocol=20 > >> (which we would negotiate e.g. using the DCP, Richard's draft, or=20 > >> some other mechanism). > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> -----Original Message----- > >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of > >> Christian > >>> Groves > >>> Sent: 14. helmikuuta 2014 1:49 > >>> To: mmusic@ietf.org > >>> Subject: Re: [MMUSIC] I-D Action: > >> draft-ietf-mmusic-sctp-sdp-06.txt - > >>> Christer's initial comments > >>> > >>> Hello, > >>> > >>> Some further comments: > >>> > >>> Section 11.1 (Editorial) - 11.1 The first paragraph > >> regarding 'sctpmap' > >>> attribute appears to be repeated. > >>> > >>> Section 4.1 (Technical): I see the draft has removed the > >> using using "bfcp" and "t38" as values for the "App" field=20 > under one=20 > >> m-line. However that also removes any hint about multiple=20 > a=3Dsctpmaps=20 > >> being used under one m-line. For example should there be one=20 > >> a=3Dsctpmap per 'fmt' or could there be zero or more a=3Dsctpmaps per= =20 > >> 'fmt' in the m-line? If think this should be clarified. > >>> > >>> General: There was a discussion on the CLUE mailing list > >> whether there could be multiple CLUE protocol instances per SCTP=20 > >> association. We couldn't identify a use case but couldn't=20 > rule it out=20 > >> either. I assume this would apply to other "apps" also. > >>> For example something like: > >>> m=3Dapplication 54111 DTLS/SCTP 5000 > >>> c=3DIN IP4 79.97.215.79 > >>> a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 > >> a=3Dsctpmap:5000 > >>> clue max-message-size=3D100000 streams=3D1 a=3Dsctpmap:5000 clue=20 > >>> max-message-size=3D100000 streams=3D1 Do we need a "label" to > >> uniquely identify a particular 'app' instance? > >>> i.e. Similar to the optional label that > >> draft-ietf-rtcweb-data-protocol uses. > >>> e.g. a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 labe= l1=20 > >>> a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label2=20 > >>> a=3Dsctpmap:5000 clue max-message-size=3D100000 streams=3D1 label3 > >>> > >>> Regards, Christian > >>> > >>> > >>> On 14/02/2014 7:57 AM, Christer Holmberg wrote: > >>>> Hi, > >>>> I gave some comments off-line to Salvatore, which have > >> been addressed > >>>> in the new version. > >>>> Some additional comments. I do realize some are pure > >> editorial, but > >>>> rather to write then down in some notes I put them > >> directly into the > >>>> e-mail J *Section 1:* > >>>> *------------* > >>>> *Q1**(EDITORIAL)**:* > >>>> The text says: > >>>> "Since > >>>> no-one so far has implemented SCTP over TLS, due to some serious=20 > >>>> limitations described in [RFC6083], this document does not > >> make use > >>>> of TLS over SCTP as described in RFC3436 [RFC3436]." > >>>> I suggest to simply say something like: > >>>> "As described in [RFC6083], there are limitations=20 > associated with=20 > >>>> implementing SCTP over TLS. For that reason, SCTP over TLS > >> is outside > >>>> the scope of this document." > >>>> *Q2**(EDITORIAL)**:* > >>>> The text says: > >>>> "Additionally, this document specifies the use of the=20 > 'setup' and=20 > >>>> 'connection' SDP attributes to establish SCTP=20 > associations. These=20 > >>>> attributes were defined in RFC4145 [RFC4145] for TCP. This > >> document > >>>> discusses their use with SCTP." > >>>> I suggest to remove the last sentence, as it only=20 > repeats what is=20 > >>>> said in the first sentence. > >>>> *Section 3:* > >>>> *------------* > >>>> *Q3 (EDITORIAL):* > >>>> The text says: > >>>> "This document defines three new values for the 'proto' field: > >>>> 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." > >>>> I would suggest to say: > >>>> "This document defines three new *protocol identifier* > >> values for the > >>>> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'." > >>>> .because, you use "protocol identifier" terminology later. > >>>> *Q4 (CLARIFICATION):* > >>>> The text says: > >>>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or > >> 'DTLS/SCTP' MUST > >>>> further qualify the application-layer protocol using an fmt=20 > >>>> identifier." > >>>> I do understand what you are trying to say, but I think > >> the "qualify" > >>>> word is a little confusing. > >>>> Maybe something like: > >>>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or > >> 'DTLS/SCTP' MUST > >>>> further include an fmt value that identifies the=20 > application-layer=20 > >>>> protocol carried on top of the SCTP association." > >>>> *Section 4.1:* > >>>> *--------------* > >>>> *Q5 (TECHNICAL):* > >>>> The text says: > >>>> "For the payload type assignments the "a=3Dsctpmap:" > >>>> attribute (see Section 5.1) SHOULD be used to map from a > >> port number > >>>> to a media encoding name that identifies the payload format=20 > >>>> transported by the association or the actual application=20 > protocol=20 > >>>> running on top of it." > >>>> It is very difficult for me to parse this, and figure out the=20 > >>>> semantics of the sctpmap attribute. > >>>> First, what do you mean by "media encoding name"? > >>>> Second, when you talk about "application protocol", I assume you=20 > >>>> refer to the SCTP protocol? > >>>> Third, the text say SHOULD. When is it ok to not use the sctpmap=20 > >>>> attribute? > >>>> *Section **5**:* > >>>> *------------* > >>>> *Q6 (EDITORIAL):* > >>>> I suggest to rename section 5 to "SDP sctpmap attribute", rename=20 > >>>> section 5.1 to "General", and add a new section 5.2 named "ABNF". > >>>> *Q7 (TECHNICAL):* > >>>> The text says: > >>>> "The sctpmap MUST include the app parameter indicating the=20 > >>>> application running on top of the association." > >>>> This is fine if the sctpmap attribute maps to an=20 > application. But,=20 > >>>> what if the sctpmap attribute maps to a "media encoding" > >> or "payload"? > >>>> *Q8 **(EDITORIAL):* > >>>> The text says: > >>>> "The sctpmap line should also contain the max-message-size > >> parameter > >>>> indicating the maximum message size, in bytes, the endpoint is=20 > >>>> willing to accept." > >>>> I suggest to replace "accept" with "receive on the=20 > associated SCTP=20 > >>>> association". > >>>> *Q9 (EDITORIAL):* > >>>> The text says: > >>>> "The peer should assume that larger message will be > >> rejected by the > >>>> endpoint, though it is up to the endpoint decide the appropriate=20 > >>>> behaviour." > >>>> I suggest to either remove this paragraph, OR replace it with a=20 > >>>> sentence saying that a peer must/should not send messages > >> bigger than > >>>> the indicated max value. > >>>> *Q10 (CLARIFICATION):* > >>>> The text says: > >>>> "If the parameter is not present, the implementation > >> should provide a > >>>> default, with a suggested value of 64K." > >>>> I don't understand "suggested". If the default value is > >> 64K the text > >>>> should specify (rather than suggest) that. > >>>> The same comment applies to the stream parameter, > >> described later in > >>>> the section. > >>>> *Q11 (CLARIFICATION):* > >>>> The text says: > >>>> "It may also provide the stream parameter to specify the initial=20 > >>>> number of incoming streams to be supported by each side of the=20 > >>>> association." > >>>> First, to be consistent with previous text, I suggest to > >> replace "It > >>>> may also provide" with "The sctpmap line may also contain" > >>>> Second, I don't understand "incoming streams to be > >> supported by each > >>>> side of the association". Doesn't each peer indicate the=20 > number of=20 > >>>> streams it is willing to receive? Then, we can always > >> recommend that > >>>> the peer indicates the same number of streams, if possible. > >>>> *Q12 (EDITORIAL):* > >>>> The text that follows the ABNF should be put into a=20 > separate "SDP=20 > >>>> Offer/Answer Procedures" section. > >>>> *Section 7:* > >>>> *------------* > >>>> *Q13 (EDITORIAL):* > >>>> Please don't talk about re-INVITEs, or other SIP=20 > messages. Simply=20 > >>>> talk about offers and answers. > >>>> *Q14 (EDITORIAL):* > >>>> The text says: > >>>> "It is worth to underline that when using SCTP on top of DTLS,.." > >>>> To have consistent terminology, please say "SCTP over DTLS". > >>>> That's all for now! :) > >>>> Regards, > >>>> Christer > >>>> -----Alkuper=E4inen viesti----- > >>>> L=E4hett=E4j=E4: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta=20 > >>>> internet-drafts@ietf.org > >>>> L=E4hetetty: 13. helmikuuta 2014 16:21 > >>>> Vastaanottaja: i-d-announce@ietf.org > >>>> Kopio: mmusic@ietf.org > >>>> Aihe: [MMUSIC] I-D Action:=20 > draft-ietf-mmusic-sctp-sdp-06.txt A New=20 > >>>> Internet-Draft is available from the on-line Internet-Drafts=20 > >>>> directories. > >>>> This draft is a work item of the Multiparty Multimedia Session=20 > >>>> Control Working Group of the IETF. > >>>> Title : Stream Control Transmission Protocol (SCTP)-Based Media=20 > >>>> Transport in the Session Description Protocol (SDP) Authors : > >>>> Salvatore Loreto Gonzalo Camarillo Filename : > >>>> draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13 > >>>> Abstract: > >>>> SCTP (Stream Control Transmission Protocol) is a transport > >> protocol > >>>> used to establish associations between two endpoints. This > >> document > >>>> describes how to express media transport over SCTP in=20 > SDP (Session=20 > >>>> Description Protocol). This document defines the 'SCTP', > >> 'SCTP/DTLS' > >>>> and 'DTLS/SCTP' protocol identifiers for SDP. > >>>> The IETF datatracker status page for this draft is: > >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ > >>>> There's also a htmlized version available at: > >>>> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 > >>>> A diff from the previous version is available at: > >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-06 > >>>> Please note that it may take a couple of minutes from=20 > the time of=20 > >>>> submission until the htmlized version and diff are available at=20 > >>>> tools.ietf.org. > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> _______________________________________________ > >>>> mmusic mailing list > >>>> mmusic@ietf.org =20 > >>>> https://www.ietf.org/mailman/listinfo/mmusic > >>>> > >>>> > >>>> _______________________________________________ > >>>> mmusic mailing list > >>>> mmusic@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mmusic > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >>> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From nobody Sun Feb 16 15:35: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 5819B1A0168 for ; Sun, 16 Feb 2014 15:35:07 -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 tuL_VIdb1mt2 for ; Sun, 16 Feb 2014 15:35:05 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3061A00BB for ; Sun, 16 Feb 2014 15:35:05 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta15.westchester.pa.mail.comcast.net with comcast id TAoW1n0040EZKEL5FBb2KW; Sun, 16 Feb 2014 23:35:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id TBb21n00A3ZTu2S3MBb2Tf; Sun, 16 Feb 2014 23:35:02 +0000 Message-ID: <53014B26.40203@alum.mit.edu> Date: Sun, 16 Feb 2014 18:35:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <52FEAA17.9070406@nostrum.com> In-Reply-To: <52FEAA17.9070406@nostrum.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=1392593702; bh=HwLScBG3jHoTw9R8DANYNNbPEQoLOVPtTylKwojBtUw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UE6TEmeAKBIyc3JBql53boGvJJeKoDlo073S4+k9+cvMgKK7wT0OWDarzCnafUehq x60nMzLFkh57LzqZgNgFSeCX7TgUh3P13sG5wultL3YXQSHqXBDA0BPAYxjH6vQ9+a aJqssNW1aS2qksDLlD3zQQBX5g4C3Nm2itnaRVcW0vkjFUFZdp3k+p00hF2t12mmyo w2yyuyMbgIeFLwrIMzNflYUrKHP9dTFtJLCNlMo0jtZXa7mxP2FKjhzTNB6sz9uPVL sjr0apQ9b/5Ce0GEOw02H51Usuweljo0WT/PqIJgDtWuzzXQDSLWpg3DCQvUjyyu4h sabnlNYWsUb+Q== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/h744-K9ti0Qog7CBV_OmFqFthZk Subject: Re: [MMUSIC] POF/PAN draft update - what is the state model? 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: Sun, 16 Feb 2014 23:35:07 -0000 This is one comment about this draft. I've separated it out to keep conversation threads distinct. Many places in this draft refer to attributes of "the SDP". For instance, in section 3.2: ... Assuming the recipient does not have an outstanding, unanswered partial offer that also modifies that exact same stream, this media section is treated as an independent renegotiation of that stream. The SDP version is increased, and an answering media section is created for inclusion in the resulting partial answer. ... In this paragraph, what does "the SDP version is increased" mean? Presumably the recipient is retaining some state about the history of O/A exchanges, and this means that the state is to be updated. But AFAIK this is not explicitly documented. That state might include: - the last full local SDP sent in an O/A exchange - the last full remote SDP received in an O/A exchange - a "current" full local SDP, including PANs sent and POFs sent that received good PANs, since the last full local SDP was sent - a "current" full remote SDP, including PANs received and POFs received for which good PANs were sent, since the last full remote SDP was received - some state of POFs outstanding that have not yet received PANs. Some saved SDP state is identified in rfc3264. There is "previous SDP" (of self), and also "previous SDP of the offerer". A more complex state model is needed to support use of POF/PAN, in the procedures of several sections. (I didn't use "previous" in my list above. In order to dovetail with 3264 I suspect that what I have called "current full local SDP" should correspond to "previous SDP" of self, and "current full remote SDP" should correspond to "previous SDP of offerer" when a full offer is received.) I think it is important to make a state model explicit, to properly support what the procedures are referring to, though the one I sketch may not be quite right. Thanks, Paul On 2/14/14 6:43 PM, Adam Roach wrote: > I've updated the partial offer/partial answer draft to reflect the > conversations we had in Vancouver: > http://tools.ietf.org/html/draft-roach-mmusic-pof-pan-02 > > Diffs: http://tools.ietf.org/rfcdiff?url2=draft-roach-mmusic-pof-pan-02.txt > > Note that this relies on the following draft for group membership > manipulation: > http://tools.ietf.org/html/draft-roach-mmusic-groupid > > Please point out whether you think I've missed any of the Vancouver > discussions or other feedback. Thanks! > > /a > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Sun Feb 16 15:38:41 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 D65D41A0427 for ; Sun, 16 Feb 2014 15:38:40 -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 3FOsVDYb39lo for ; Sun, 16 Feb 2014 15:38:39 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id E513E1A029D for ; Sun, 16 Feb 2014 15:38:38 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id TAfK1n0020bG4ec5DBec2L; Sun, 16 Feb 2014 23:38:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id TBec1n0043ZTu2S3PBecrr; Sun, 16 Feb 2014 23:38:36 +0000 Message-ID: <53014BFC.3070406@alum.mit.edu> Date: Sun, 16 Feb 2014 18:38:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <52FEAA17.9070406@nostrum.com> In-Reply-To: <52FEAA17.9070406@nostrum.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=1392593916; bh=yQYEzC/LObAl0R8KELYdRskaUy9OwzZVzQKM5Cq5ac0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RER2CzNHNCiiCGr93sWQRNZ3GHPAwaKsJzHbkn2AWFJR16ffYDBvgJ9UgABTDgUtb Bq/65O+LlKJQAXdyENWOmYskAQH+Cj5Rb0GiuQc4wsWB9KFlxsQ/vcVka42aqRHlqQ ZVZHERe+5SDxbXj6VNg974Ps7LzgYsbd7IP5IqNMPwJg+2JIo1s0ZEvYlvJ4lrXc83 o/1hzz19bm0XAlRYXDzXVe7XipNKRJAfeBsfnRdhmjrN1N3uaqSLxhL56yDm+r0ROn L3SVazWVXQoCBiWvKn5w+ZEdvUKSGVSqJzVtED+PlRaJ+BCOq2tsnWk4n9nsr0YFCr lD++wprlLxLXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Nuog5spHGVOE7LPCBl52kGgI2vI Subject: Re: [MMUSIC] POF/PAN draft update - move BUNDLE-specific stuff to bundle 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: Sun, 16 Feb 2014 23:38:41 -0000 Another comment on this draft: While the mechanism described in this draft is strongly motivated by BUNDLE, it is conceptually independent of BUNDLE. IMO all the BUNDLE-specific behavior should be removed from this draft, and instead placed into the BUNDLE draft. I realize there is a chicken/egg thing here. It would make sense to keep the bundle-specifics here, so they don't get forgotten, until they are incorporated into the bundle draft. Thanks, Paul On 2/14/14 6:43 PM, Adam Roach wrote: > I've updated the partial offer/partial answer draft to reflect the > conversations we had in Vancouver: > http://tools.ietf.org/html/draft-roach-mmusic-pof-pan-02 > > Diffs: http://tools.ietf.org/rfcdiff?url2=draft-roach-mmusic-pof-pan-02.txt > > Note that this relies on the following draft for group membership > manipulation: > http://tools.ietf.org/html/draft-roach-mmusic-groupid > > Please point out whether you think I've missed any of the Vancouver > discussions or other feedback. Thanks! > > /a > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Sun Feb 16 20:49: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 604ED1A0348 for ; Sun, 16 Feb 2014 20:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=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 fthxjh0CAu7t for ; Sun, 16 Feb 2014 20:49:18 -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 91ED81A033C for ; Sun, 16 Feb 2014 20:49:18 -0800 (PST) Received: from orochi.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 s1H4nDUi077953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 16 Feb 2014 22:49:14 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <530194C7.5070002@nostrum.com> Date: Sun, 16 Feb 2014 20:49:11 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Kyzivat , mmusic@ietf.org References: <52FEAA17.9070406@nostrum.com> <53014B26.40203@alum.mit.edu> In-Reply-To: <53014B26.40203@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------040408050708020603080208" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/zc9zVv6Yu80D0XD4MUXCI-ALGgo Subject: Re: [MMUSIC] POF/PAN draft update - what is the state model? 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, 17 Feb 2014 04:49:20 -0000 This is a multi-part message in MIME format. --------------040408050708020603080208 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/16/14 15:35, Paul Kyzivat wrote: > what does "the SDP version is increased" mean? Sorry, I mean the from the "o=" line: is a version number for this session description. Its usage is up to the creating tool, so long as is increased when a modification is made to the session data. I'll make this more explicit in the next version. > I think it is important to make a state model explicit, to properly > support what the procedures are referring to That's a very good point, since it will help us identify where we might have some holes in how things need to be handled. I'll make a run at defining a state diagram for POF/PAN. /a --------------040408050708020603080208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 2/16/14 15:35, Paul Kyzivat wrote:
what does "the SDP version is increased" mean?

Sorry, I mean the <sess-version> from the "o=" line:

   <sess-version> is a version number for this session description.  Its
      usage is up to the creating tool, so long as <sess-version> is
      increased when a modification is made to the session data.

I'll make this more explicit in the next version.

I think it is important to make a state model explicit, to properly support what the procedures are referring to

That's a very good point, since it will help us identify where we might have some holes in how things need to be handled. I'll make a run at defining a state diagram for POF/PAN.

/a
--------------040408050708020603080208-- From nobody Mon Feb 17 07:31: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 43E631A0470 for ; Mon, 17 Feb 2014 07:31:20 -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 jwZfSQ7-plCg for ; Mon, 17 Feb 2014 07:31:18 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3EA1A023A for ; Mon, 17 Feb 2014 07:31:18 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-36-53022b43056a Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 2F.B8.04249.34B22035; Mon, 17 Feb 2014 16:31:15 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.210]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 16:31:14 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: mmusic Thread-Topic: MMUSIC draft agenda for IETF 89 Thread-Index: AQHPK/VL7avUBbosqUCMF5lyIidSxA== Date: Mon, 17 Feb 2014 15:31:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja6zNlOwwZ5bMhbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgythz4CBTwXfGivm7nrM1MB5j7GLk5JAQMJH4 9Gc+M4QtJnHh3nq2LkYuDiGBI4wS21vusEA4SxglZnW8B6tiE7CXmLzmI1i3iICMxN5Nm8Hi zALaErPvzGICsYUFNCRmzOxnh6jRlejZBbFBREBPouPlCdYuRg4OFgFViVnbzUDCvEAjl/5Y AlbOCHTE91NrmCBGikvcejKfCeI4AYkle85DHSoq8fLxP1YIW0li0e3PUPV6EjemTmGDsK0l Ltx5zApz2rKFr5khdglKnJz5hGUCo+gsJCtmIWmfhaR9FpL2WUjaFzCyrmLkKE4tTspNNzLY xAiMkYNbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFs8 fjRyzJlednbaq6jWiCThO72rVGZkqvLeFj20V0cksXGWzva/vl83e8gmR1le85JVXq3pvN9U ZYHETPnckMdJ6w93L5r2m52PN954wZ8k1cvsJhc5doYlhPuu9zy7/ebMf8FPjbUeS85cn/A0 8U7oXbs1ugqsfWvjNx96+4s7SOjm48uTLJVYijMSDbWYi4oTAQWBhsdfAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/wZnIvmNQ6BPJIUicofWzPb8RRKc Cc: Flemming Andreasen Subject: [MMUSIC] MMUSIC draft agenda for IETF 89 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, 17 Feb 2014 15:31:20 -0000 Hi all, The draft agenda for the MMUSIC meeting at IETF 89 is now available: http://www.ietf.org/proceedings/89/agenda/agenda-89-mmusic Please have a look and let us know if you have any questions or comments. Thanks, Ari & Flemming From nobody Mon Feb 17 09:08: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 A49FB1A050E for ; Mon, 17 Feb 2014 09:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 EoqA35ixTROw for ; Mon, 17 Feb 2014 09:08:43 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2871A050C for ; Mon, 17 Feb 2014 09:08:43 -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 s1HH8aOW001616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Feb 2014 11:08:37 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1HH8ZBe015302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 18:08:35 +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; Mon, 17 Feb 2014 18:08:36 +0100 From: "DRAGE, Keith (Keith)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: MMUSIC draft agenda for IETF 89 Thread-Index: AQHPK/VL7avUBbosqUCMF5lyIidSxJq5rZGQ Date: Mon, 17 Feb 2014 17:08:34 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B13419B@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vGkzj6eMi2grgEpKD804w-HRJHs Cc: Flemming Andreasen Subject: Re: [MMUSIC] MMUSIC draft agenda for IETF 89 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, 17 Feb 2014 17:08:46 -0000 The drafts I will be presenting are: draft-ejzak-mmusic-data-channel-sdpneg-00 draft-ejzak-dispatch-msrp-data-channel-00 i.e. in this order and the sdpneg draft has changed to be mmusic with the o= mission of webrtc. Regards Keith=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen > Sent: 17 February 2014 15:31 > To: mmusic > Cc: Flemming Andreasen > Subject: [MMUSIC] MMUSIC draft agenda for IETF 89 >=20 > Hi all, >=20 > The draft agenda for the MMUSIC meeting at IETF 89 is now available: > http://www.ietf.org/proceedings/89/agenda/agenda-89-mmusic >=20 > Please have a look and let us know if you have any questions=20 > or comments. >=20 >=20 > Thanks, > Ari & Flemming >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From nobody Mon Feb 17 10:23: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 C95901A0407 for ; Mon, 17 Feb 2014 10:23:29 -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 Qo9iHuIHBeAX for ; Mon, 17 Feb 2014 10:23:27 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 26CD91A034B for ; Mon, 17 Feb 2014 10:23:26 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-14-5302539b58cd Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9D.95.10875.B9352035; Mon, 17 Feb 2014 19:23:23 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.210]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 19:23:23 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "DRAGE, Keith (Keith)" Thread-Topic: MMUSIC draft agenda for IETF 89 Thread-Index: AQHPK/VL7avUBbosqUCMF5lyIidSxJq5rZGQgAAEeYA= Date: Mon, 17 Feb 2014 18:23:22 +0000 Message-ID: <14B2CE4C-F356-4DF3-923E-3EF1DDC6429D@ericsson.com> References: <949EF20990823C4C85C18D59AA11AD8B13419B@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B13419B@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.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje7sYKZgg/7L1hbvL+haPG08y2gx dfljFgdmj9Zne1k9pvzeyOqxZMlPpgDmKC6blNSczLLUIn27BK6MfctcC05wVCztmMbawPiX rYuRk0NCwESi+9gedghbTOLCvfVgcSGBQ4wSTw8kdDFyAdlLGCXubOhgBEmwCdhLTF7zEcwW EbCWePV4C1gDs4CrxKpds5lBbGEBHYkT+5uZIGp0JXp2zWeGsK0kpm64ANbLIqAq8fDoR7A4 L9DM0zOesEAsm8AosXD1CaChHBycAtESPS26IDWMQMd9P7WGCWKXuMStJ/OZII4WkFiy5zwz hC0q8fLxP1YIW0li7eHtLBD1ehI3pk6ButNa4lvfdyhbW2LZwtdQNwhKnJz5hGUCo/gsJCtm IWmfhaR9FpL2WUjaFzCyrmJkz03MzEkvN9zECIyxg1t+6+5gPHVO5BCjNAeLkjjvh7fOQUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYKxReen3YecR8xYKNP3pajx6ockh7sTSqcGbhi8TM W17fNPuOh6xTyVfzFrFJidfs5iuOs7VPvHNOQXGOzsbte8PWcTA+jNq1Y3amcGW4eN97KTuB Pg3N+9lpp2+tqNrFa/ZB3VR82nUOlSWT15f82rvTXDb9btr59klmrbcC7h4xL+yten5ViaU4 I9FQi7moOBEAbXgten8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8CBbMe7jSLSNSykQC2FSDX8fUtM Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC draft agenda for IETF 89 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, 17 Feb 2014 18:23:30 -0000 OK, thanks for the info Keith. Fixed now. Cheers, Ari On Feb 17, 2014, at 7:08 PM, DRAGE, Keith (Keith) wrote: > The drafts I will be presenting are: >=20 > draft-ejzak-mmusic-data-channel-sdpneg-00 > draft-ejzak-dispatch-msrp-data-channel-00 >=20 > i.e. in this order and the sdpneg draft has changed to be mmusic with the= omission of webrtc. >=20 > Regards >=20 > Keith=20 >=20 >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen >> Sent: 17 February 2014 15:31 >> To: mmusic >> Cc: Flemming Andreasen >> Subject: [MMUSIC] MMUSIC draft agenda for IETF 89 >>=20 >> Hi all, >>=20 >> The draft agenda for the MMUSIC meeting at IETF 89 is now available: >> http://www.ietf.org/proceedings/89/agenda/agenda-89-mmusic >>=20 >> Please have a look and let us know if you have any questions=20 >> or comments. >>=20 >>=20 >> Thanks, >> Ari & Flemming >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Feb 17 10:24: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 43EF91A03DE for ; Mon, 17 Feb 2014 10:24:52 -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 UpeLHDwh3Ukp for ; Mon, 17 Feb 2014 10:24:50 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DF5E71A034B for ; Mon, 17 Feb 2014 10:24:49 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-06-530253eed57f Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E6.FC.23809.EE352035; Mon, 17 Feb 2014 19:24:46 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.210]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 19:24:46 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "DRAGE, Keith (Keith)" Thread-Topic: MMUSIC draft agenda for IETF 89 Thread-Index: AQHPK/VL7avUBbosqUCMF5lyIidSxJq5rZGQgAAE6YA= Date: Mon, 17 Feb 2014 18:24:45 +0000 Message-ID: <454D2EB3-1621-4AA7-A998-E31BE751DE02@ericsson.com> References: <949EF20990823C4C85C18D59AA11AD8B13419B@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B13419B@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.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje67YKZgg+/dJhbvL+haPG08y2gx dfljFgdmj9Zne1k9pvzeyOqxZMlPpgDmKC6blNSczLLUIn27BK6MfctcC05wVCztmMbawPiX rYuRk0NCwERi4ZfVTBC2mMSFe+uB4lwcQgKHGCU+f7rADJIQEljCKHG+yQLEZhOwl5i85iMj iC0iYC3x6vEWsEHMAq4Sq3bNBqsXFtCROLG/mQmiRleiZ9d8oDgHkG0l8fmjC0iYRUBV4uCp vawgNi/QyM9LNzND7J3AKLFw9Qk2kHpOgWiJnhZdkBpGoNu+n1rDBLFKXOLWk/lQNwtILNlz nhnCFpV4+fgfK4StJLH28HYWiHo9iRtTp0CdaS3xbFcbO4StLbFs4WtmiBsEJU7OfMIygVF8 FpIVs5C0z0LSPgtJ+ywk7QsYWVcxsucmZuaklxttYgRG2MEtv1V3MN45J3KIUZqDRUmc98Nb 5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBN6NsnzinVLOcg84lsW07qHMamxtscsYUGt kpmDpXPd1sNqK3bbip3b/XxFp0LofrfiWffvvEhb/9P9yvGLfPk38ze7r1kll/jpVMqkn0ZR euXujMK7ZstNvJYVvChW61rm/Ek2YpefKYp6y7V29LgK7fLqO+cVPtHv3pN2xdWyoSvy1nrF KLEUZyQaajEXFScCADGqLmp+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ukaRwYfcAjJbhtMRPf4JOg5rHkw Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC draft agenda for IETF 89 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, 17 Feb 2014 18:24:52 -0000 OK, thanks for the info Keith. Fixed now. Cheers, Ari On Feb 17, 2014, at 7:08 PM, DRAGE, Keith (Keith) wrote: > The drafts I will be presenting are: >=20 > draft-ejzak-mmusic-data-channel-sdpneg-00 > draft-ejzak-dispatch-msrp-data-channel-00 >=20 > i.e. in this order and the sdpneg draft has changed to be mmusic with the= omission of webrtc. >=20 > Regards >=20 > Keith=20 >=20 >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen >> Sent: 17 February 2014 15:31 >> To: mmusic >> Cc: Flemming Andreasen >> Subject: [MMUSIC] MMUSIC draft agenda for IETF 89 >>=20 >> Hi all, >>=20 >> The draft agenda for the MMUSIC meeting at IETF 89 is now available: >> http://www.ietf.org/proceedings/89/agenda/agenda-89-mmusic >>=20 >> Please have a look and let us know if you have any questions=20 >> or comments. >>=20 >>=20 >> Thanks, >> Ari & Flemming >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Feb 17 11:09:10 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 F17C41A052B for ; Mon, 17 Feb 2014 11:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=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 fI24ZEL3cFj4 for ; Mon, 17 Feb 2014 11:09:03 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1A1A01DB for ; Mon, 17 Feb 2014 11:08:49 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1HJ8ksn000118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Feb 2014 13:08:47 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s1HJ8jlI022523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Feb 2014 14:08:45 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 17 Feb 2014 14:08:45 -0500 From: "Makaraju, Maridi Raju (Raju)" To: "mmusic@ietf.org" Thread-Topic: RE: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06.txt Thread-Index: Ac8sE6rAL3ZEGjbiSbSXIxi9o1wKTg== Date: Mon, 17 Feb 2014 19:08:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFE6431US70UWXCHMBA02z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_HPODY04vL9dVvOHOCEYT-rVjkY Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06.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, 17 Feb 2014 19:09:07 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826DFE6431US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Sorry for the duplicate post. Posting this again as this post did not get = any response probably due to posting issues!) >4.1 a=3Dsctpmap:5000 webrtc-datachannel max-message-size=3D100000 s= treams=3D16 >9.3 a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 s= treams=3D16 >11.1 'app' parameter and register as first value "webrtc-datachannel" fo= r [Raju] Above three types of representations of "webrtc-datachannel" should use a s= ingle value; The value may be based on the outcome from discussion that is going on a di= fferent thread. >4.1 a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 streams= =3D16 [Raju] Instead of putting webrtc data channel attributes on the same line (= which gets long too), How about reusing existing a=3Dfmtp? as in: a=3Dfmtp:5000 max-message-size=3D100000 streams=3D16 or how about even further shortening it to? a=3Dfmtp:5000 mms=3D100000; streams=3D16 Then these attributes of 'app' protocol can be defined either in rtcweb-dat= a-channel and then IANA (section 11.1) will have a reference to it. Any such attribut= es defined for this or any generic 'app' protocol are carried in a=3Dfmtp line transpa= rently. Regards Raju > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, February 13, 2014 8:21 AM > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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 : Stream Control Transmission Protocol (SCTP)-Bas= ed > Media Transport in the Session Description Protocol (SDP) > Authors : Salvatore Loreto > Gonzalo Camarillo > Filename : draft-ietf-mmusic-sctp-sdp-06.txt > Pages : 14 > Date : 2014-02-13 > > Abstract: > SCTP (Stream Control Transmission Protocol) is a transport protocol > used to establish associations between two endpoints. This document > describes how to express media transport over SCTP in SDP (Session > Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' > and 'DTLS/SCTP' protocol identifiers for SDP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-06 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 --_000_E1FE4C082A89A246A11D7F32A95A17826DFE6431US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Sorry for the duplicate post. Posting this again= as this post did not get any response probably due to posting issues!)

 

>4.1       = a=3Dsctpmap:5000 webrtc-datachannel max-message-size=3D100000 streams=3D16=

>9.3       = a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 streams=3D16=

>11.1   'app' parameter and register= as first value "webrtc-datachannel" for

 

[Raju]

Above three types of representations of "web= rtc-datachannel" should use a single value;

The value may be based on the outcome from discus= sion that is going on a different thread.

 

 

>4.1 a=3Dsctpmap:5000 webrtc-DataChannel max-m= essage-size=3D100000 streams=3D16

 

[Raju] Instead of putting webrtc data channel att= ributes on the same line (which gets long too), How about reusing existing = a=3Dfmtp? as in:

a=3Dfmtp:5000 max-message-size=3D100000 streams= =3D16

or how about even further shortening it to?<= /o:p>

a=3Dfmtp:5000 mms=3D100000; streams=3D16

 

Then these attributes of 'app' protocol can be de= fined either in rtcweb-data-channel

and then IANA (section 11.1) will have a referenc= e to it. Any such attributes defined

for this or any generic 'app' protocol are carrie= d in a=3Dfmtp line transparently.

 

Regards

Raju

 

> -----Original Message-----

> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-

> drafts@ie= tf.org

> Sent: Thursday, February 13, 2014 8:21 AM

> To: i-d-announce@ietf.org

> Cc: mmusi= c@ietf.org

> Subject: [MMUSIC] I-D Action: draft-ietf-mmu= sic-sctp-sdp-06.txt

>

>

> A New Internet-Draft is available from the o= n-line Internet-Drafts

> directories.

>  This draft is a work item of the Multi= party Multimedia Session Control

> Working Group of the IETF.

>

>       &nb= sp; Title           : Str= eam Control Transmission Protocol (SCTP)-Based

> Media Transport in the Session Description P= rotocol (SDP)

>       &nb= sp; Authors         : Salvatore Lor= eto

>       &nb= sp;            =        Gonzalo Camarillo

>     Filename   = ;     : draft-ietf-mmusic-sctp-sdp-06.txt

>     Pages   &n= bsp;       : 14

>     Date   &nb= sp;        : 2014-02-13

>

> Abstract:

>    SCTP (Stream Control Trans= mission Protocol) is a transport protocol

>    used to establish associat= ions between two endpoints.  This document

>    describes how to express m= edia transport over SCTP in SDP (Session

>    Description Protocol).&nbs= p; This document defines the 'SCTP', 'SCTP/DTLS'

>    and 'DTLS/SCTP' protocol i= dentifiers for SDP.

>

>

> The IETF datatracker status page for this dr= aft is:

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/=

>

> There's also a htmlized version available at= :

> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06

>

> A diff from the previous version is availabl= e at:

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-06

>

>

> Please note that it may take a couple of min= utes from the time of submission

> until the htmlized version and diff are avai= lable at tools.ietf.org.

>

> Internet-Drafts are also available by anonym= ous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

>

> ____________________________________________= ___

> mmusic mailing list

> mmusic@ie= tf.org

> https://www.ietf.org/mailman/listinfo/mmusic

 

--_000_E1FE4C082A89A246A11D7F32A95A17826DFE6431US70UWXCHMBA02z_-- From nobody Mon Feb 17 13:26: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 080D51A028A for ; Mon, 17 Feb 2014 13:26: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 xc4LVpk8VSQU for ; Mon, 17 Feb 2014 13:26:18 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 808BF1A0289 for ; Mon, 17 Feb 2014 13:26:18 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta09.westchester.pa.mail.comcast.net with comcast id TYVn1n0020ldTLk59ZSFc7; Mon, 17 Feb 2014 21:26:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id TZSF1n00P3ZTu2S01ZSFX0; Mon, 17 Feb 2014 21:26:15 +0000 Message-ID: <53027E77.2060208@alum.mit.edu> Date: Mon, 17 Feb 2014 16:26:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Adam Roach , mmusic@ietf.org References: <52FEAA17.9070406@nostrum.com> <53014B26.40203@alum.mit.edu> <530194C7.5070002@nostrum.com> In-Reply-To: <530194C7.5070002@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392672375; bh=TUXM2gTjQmQgOwiMnPlZSt6dv1uGqWZmDKG8JtCqQ7I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CsaP0AbTpB7UD24x3O6Qcno5qBNXO9huL4vThknqaeV+xxWrWKQQ6BRIV7iO/bc86 I1iGIlEBCZA1itERmXwodfndXdTclD+rO9m3iipDlKBpNrQsJ2T9rpmULe8Qye1n/t 5uUPmRGhMAbzZBH4Top5A5GAkkhSeFgWrGLpD5wpLKKxXV955oZe/5QygLc4imq7FK hNuYioQ5dZ74TTtYTihqiUbU55+jqkWRw6khhe9IG2gtaCKT0lXWDVKtTKizVSL5H5 /SYSPJhf1k59DBeo7M2/TMieggINfUKGLACJri391mZYpjLuubS+PFocigM1oqORJ/ 89CiPMnj8zi7A== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/w0djy9qgpX3lkUZrvOvskverxQw Subject: Re: [MMUSIC] POF/PAN draft update - what is the state model? 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, 17 Feb 2014 21:26:20 -0000 On 2/16/14 11:49 PM, Adam Roach wrote: > On 2/16/14 15:35, Paul Kyzivat wrote: >> what does "the SDP version is increased" mean? > > Sorry, I mean the from the "o=" line: > > is a version number for this session description. Its > usage is up to the creating tool, so long as is > increased when a modification is made to the session data. > > > I'll make this more explicit in the next version. > >> I think it is important to make a state model explicit, to properly >> support what the procedures are referring to > > That's a very good point, since it will help us identify where we might > have some holes in how things need to be handled. I'll make a run at > defining a state diagram for POF/PAN. I'm less concerned with a state *diagram* than I am in specifying what state must be retained and which of it is used for each step. But both may be useful. Thanks, Paul From nobody Tue Feb 18 06:11: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 F20591A0673; Tue, 18 Feb 2014 06:11:29 -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 ZBU0wCsk5ZU7; Tue, 18 Feb 2014 06:11:22 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 396721A0491; Tue, 18 Feb 2014 06:11:22 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id q8so12298300lbi.14 for ; Tue, 18 Feb 2014 06:11:18 -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=+iRDEqmjrAdkGMw2OqGEqPq+ve2QuSJBbmQGHGJxiyI=; b=cS8/mWvwMmtBn5aWqhitlxdanjG1LsmbuMYZbQ51YTwkdt/lbd5hy216/QZCM+ttJY LH3uVOlsIEu2qcrMUihX4b5wDjaS6AMqPPaCElOteVi/38wzHRQN8x9DhYGpXlB9V7Dh qq3NziP16FDhQ2AecE74x0C8wUjoZeVQc0eqEhehmHqZ/PL6iN1fQ1ttXbcGuEUrCL5h oMfX0TLRR0zAHytnPS90dG7+yrrUzGu8cGiGYDsDdKv5USgqDnfrAdScXFCqwZZKWdeF YK1bPLU+Ob/3EltgYR3yw/utb7DJiHXhiLcR1w4gAWBihIWvTmjLgiVsNZ8wmB2LTWv2 ZwDQ== MIME-Version: 1.0 X-Received: by 10.152.1.3 with SMTP id 3mr1632700lai.58.1392732678668; Tue, 18 Feb 2014 06:11:18 -0800 (PST) Received: by 10.112.98.162 with HTTP; Tue, 18 Feb 2014 06:11:18 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> Date: Tue, 18 Feb 2014 08:11:18 -0600 Message-ID: From: Richard Ejzak To: "Liuyan (Scarlett)" Content-Type: multipart/alternative; boundary=089e013c6ae494471104f2aed8b7 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GQmjpJ7JZMYwiHEAzowSl2JEJ54 Cc: "rtcweb@ietf.org" , mmusic@ietf.org Subject: Re: [MMUSIC] [rtcweb] I-D Action: draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt - the data channel's state and the SCTP association 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, 18 Feb 2014 14:11:30 -0000 --089e013c6ae494471104f2aed8b7 Content-Type: text/plain; charset=ISO-8859-1 Hi Scarlett, Please note that this document has been replaced by draft-ejzak-mmusic-data-channel-sdpneg-00 (this is noted in datatracker) and that discussion of the topic should be directed to the mmusic list (although there is some obvious overlap with the data channel discussion regarding external negotiation). I copied both groups for this email only - please respond only to mmusic. " It is not clear that if the SCTP association is failed to establish, how to we deal with the newly created data channels. Furthermore, how long the valid duration of the connecting state of the newly created data channels are before the SCTP association has not yet established ?" This issue is common to all forms of data channel negotiation and should be addressed by the core documents rather than this one. It appears that a data channel can be in the connecting state indefinitely until the peer connection is closed. "When there are multiple data channels with different sub-protocol per a SCTP association, Maybe it needs to identify how to close a single data channel, how to close all data channels with the same sub-protocol and how to close a SCTP association. Of course, closing a SCTP association can just set SCTP port number zero.:-) " The procedure describes how to close a single data channel. We did not see a need to have a special way to close all data channels with the same sub-protocol since they can just be closed individually. I don't see a compelling use case for this, but perhaps you have one? The document should point out that data channels terminate with the SCTP association and peer connection. Sometimes we forget to state the most obvious things! BR, Richard On Mon, Feb 17, 2014 at 5:30 AM, Liuyan (Scarlett) < scarlett.liuyan@huawei.com> wrote: > Hi, > > Section 5.5.2 does say: > > "o As described in Section 4.2.2, if the SCTP association is not > yet > established, then the newly created data channels are in the > Connecting state, else if the SCTP association is already > established, then the newly created data channels are in the Open > state." > ..... > It is not clear that if the SCTP association is failed to establish, how > to we deal with the newly created data channels. > Furthermore, how long the valid duration of the connecting state of the > newly created data channels are before the SCTP association has not yet > established ? > > Section 5.5.3 does say: > "5.2.3. Closing a data channel > > When the application requests the closing of a data channel that was > externally negotiated, the browser always performs an in-band SSN > reset for this channel. > > It is specific to the sub-protocol whether this closing must in > addition be signaled to the peer via a new SDP offer/answer exchange. > > The application must also close any data channel that was externally > negotiated, for which the stream identifiers are not listed in an > incoming SDP offer." > ... > When there are multiple data channels with different sub-protocol per a > SCTP association, > Maybe it needs to identify how to close a single data channel, how to > close all data channels with the same sub-protocol and how to close a SCTP > association. > Of course, closing a SCTP association can just set SCTP port number > zero.:-) > > Regards, > Scarlett > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e013c6ae494471104f2aed8b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Scarlett,
Please note that this document has been r= eplaced by draft-ejzak-mmusic-data-channel-sdpneg-00 (this is noted in data= tracker) and that discussion of the topic should be directed to the mmusic = list (although there is some obvious overlap with the data channel discussi= on regarding external negotiation). =A0I copied both groups for this email = only - please respond only to mmusic.

"=A0It is not clear that if the SCTP association is failed to establish, = how to we deal with the newly created data channels.
=A0 Furthe= rmore, how long the valid duration of the connecting state of the newly cre= ated data channels are before the SCTP association has not yet established = ?"

This issue is common to all forms of data channel negot= iation and should be addressed by the core documents rather than this one. = =A0It appears that a data channel can be in the connecting state indefinite= ly until the peer connection is closed.

"When there are multiple data channels with different sub-protoco= l per a SCTP association,
Maybe it needs to identify how to close a single dat= a channel, how to close all data channels with the same sub-protocol and ho= w to close a SCTP association.
Of course,= closing a SCTP association can just set SCTP port number zero.:-)&q= uot;

The procedure describes how to close a single= data channel. =A0We did not see a need to have a special way to close all = data channels with the same sub-protocol since they can just be closed indi= vidually. =A0I don't see a compelling use case for this, but perhaps yo= u have one? =A0The document should point out that data channels terminate w= ith the SCTP association and peer connection. =A0Sometimes we forget to sta= te the most obvious things!

BR, Richard=A0

On Mon, Feb 17, 2014 at 5:30 AM, Liuyan (S= carlett) <scarlett.liuyan@huawei.com> wrote:
Hi,

Section 5.5.2 does say:

=A0 =A0 =A0 =A0 "o =A0As described in Section 4.2.2, if the SCTP assoc= iation is not yet
=A0 =A0 =A0 established, then the newly created data channels are in the =A0 =A0 =A0 Connecting state, else if the SCTP association is already
=A0 =A0 =A0 established, then the newly created data channels are in the Op= en
=A0 =A0 =A0 state."
=A0 .....
=A0 It is not clear that if the SCTP association is failed to establish, ho= w to we deal with the newly created data channels.
=A0 Furthermore, how long the valid duration of the connecting state of the= newly created data channels are before the SCTP association has not yet es= tablished ?

Section 5.5.3 does say:
=A0 =A0 =A0 =A0"5.2.3. =A0Closing a data channel

=A0 =A0 =A0 When the application requests the closing of a data channel tha= t was
=A0 =A0 =A0 externally negotiated, the browser always performs an in-band S= SN
=A0 =A0 =A0 reset for this channel.

=A0 =A0 =A0 It is specific to the sub-protocol whether this closing must in=
=A0 =A0 =A0 addition be signaled to the peer via a new SDP offer/answer exc= hange.

=A0 =A0 =A0 The application must also close any data channel that was exter= nally
=A0 =A0 =A0 negotiated, for which the stream identifiers are not listed in = an
=A0 =A0 =A0 incoming SDP offer."
=A0 =A0...
=A0 =A0When there are multiple data channels with different sub-protocol pe= r a SCTP association,
Maybe it needs to identify how to close a single data channel, how to close= all data channels with the same sub-protocol and how to close a SCTP assoc= iation.
Of course, closing a SCTP association can just set SCTP port number zero.:-= )

Regards,
Scarlett
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

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

--089e013c6ae494471104f2aed8b7-- From nobody Tue Feb 18 08:23: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 3AF681A0688 for ; Tue, 18 Feb 2014 08:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 eB5piqZXXiqP for ; Tue, 18 Feb 2014 08:23:05 -0800 (PST) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 658EB1A0504 for ; Tue, 18 Feb 2014 08:23:05 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id c13so7943188eek.3 for ; Tue, 18 Feb 2014 08:23:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=OGVIllv7dByUtvA0w6umQTxO/8V3yHyLl14WRSrPjAM=; b=TqepADjLckQ2qc8OU0E16fCsrBYN6MfUcP9OD3OZf1x6gg4onbrfs8f6K3NrgpZ/xj 7IfU2rM17fFfJtA4o13wMhjLlu/piIBiTBvgJjq64oWqh/vUZYngucgLXykcSmuKks9w O1QHZbvhsK5nz0/dPJqdT2spapVx+a+BG7YNjiYKpYSMUtNmhwoJP6GU2zjuD3arvKmU OL04CXoOiqJgPjGRtQYU/bpiDWZqWISaqxl1qD+kh3ppIS7qMu+eSPnOtnrvP+UOJZc5 Od3YCnXm4LkHsnGm72mMazCA6//dfm/SKIlWxEoaFWcLGBXo+lqXz59N4uUt4wKfDUDc YmSg== X-Received: by 10.14.225.195 with SMTP id z43mr34898817eep.19.1392740582082; Tue, 18 Feb 2014 08:23:02 -0800 (PST) Received: from RoniE ([109.67.98.212]) by mx.google.com with ESMTPSA id v6sm71718927eef.2.2014.02.18.08.23.00 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Feb 2014 08:23:01 -0800 (PST) From: "Roni Even" To: "'Jonathan Lennox'" , "'mmusic'" References: <10C8325A-F234-4034-BD05-D0D24C0B562B@vidyo.com> In-Reply-To: <10C8325A-F234-4034-BD05-D0D24C0B562B@vidyo.com> Date: Tue, 18 Feb 2014 18:22:58 +0200 Message-ID: <038b01cf2cc5$b1528b30$13f7a190$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHFDhpOYfQJxXnvgQNLMJhaT2Z+h5rPbhPA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lmi4aMvA9OGiaMm37hPwmieLfI8 Subject: Re: [MMUSIC] MSID and AppID: solving different problems 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, 18 Feb 2014 16:23:07 -0000 Hi, I agree with Jonathan description about where appId will be used and the difference from MSID. I think that a major advantage of appId is not only when the SSRC is not known in the SDP but it is useful even if can be known in order to define the SSRC in at the RTP level and not in the SDP level. For the SSRC collision case it is simpler to change the SSRC without a need for re-invite to update the SDP since the appId does not hange but points to the new SSRC Roni Even > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan > Lennox > Sent: 13 February, 2014 8:09 PM > To: mmusic > Subject: [MMUSIC] MSID and AppID: solving different problems > > The chairs asked that the authors of the MSID and AppID drafts discuss the > relationship between the two documents. > > My personal opinion (which I mentioned in the RTCWeb Rejecting > MediaStreamTracks thread, but folks might not have seen) is that they're > solving different problems, and so are non-conflicting. > > MSID provides an identifier for SDP m= lines. Its primary use case is providing > a Javascript-level handle in WebRTC. > > AppID -- which needs a better name, suggestions welcome -- provides an > indirection label for identifying individual RTP packet streams in SDP, in > scenarios where the SSRC is unavailable to the signaling. > > The scenarios we've identified so far for AppID where an SSRC might be > unavailable are: "early media" race conditions where media outraces an SDP > answer; SSRC collisions; applications which wish to dynamically switch which > SSRC is fulfilling a higher-level application role; and architectures where the > signaling stack can't control/doesn't have visibility onto the SSRC selection. > > AppID should be applicable to anything using BUNDLE, I think, and certainly > anything using it with a vaguely Unified-style semantic. (I think it would apply > to a "Plan B"-style semantic, as well, which I know some people are still > advocating for some non-WebRTC contexts; however, I'm not positive all the > syntax necessary for that is currently complete.) > > The difference between AppID and MSID should be most clear in scenarios > where an m= line group has more than one packet stream (my canonical > example is a primary stream and a retransmission stream). In this case, the > m= line group has one msid attribute, but multiple appid attributes. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Feb 18 10:04: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 77BC11A0504 for ; Tue, 18 Feb 2014 10:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 UC6TSFFd5c3X for ; Tue, 18 Feb 2014 10:04:22 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B176B1A020C for ; Tue, 18 Feb 2014 10:04:21 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id l18so3514440wgh.0 for ; Tue, 18 Feb 2014 10:04:18 -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=EB+SiiF2tJNNgYqKYFEOZ+eFxhj3jqmsc/hah1OyuY0=; b=Gmv/7RAb3FHkDrqfdbP+tUTYOLKEVwWgMlhGPkSm63/6VDRn2IkWjlWllyMmE3DHM+ 0rfj9KyaFVWTa32x6iccHlHovxbay0yl4O8UKYVwQLNOFyeMOV7CZ7rBknFMLxvLNgB7 f9eKFBtEvnNYwfm7QkPo3A1bgSs8bAu35Vyiiz8ft0LDfRSVs6wK5cVND1pluOGuV3jI 6usWZEuzwHx0zh1GWJqfGzmuUlv7iX1Hbq1r+qWzFtPaaVjRv5njxw1jHOwl7VCA8GHL OoxbUJVe7paMoO79xNZebrmY0b0AtEnhOeBNc7RPTOPGNjwYbpOfOZ7gn1lKGYMmNr4h yjow== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr19156353wiw.56.1392746658260; Tue, 18 Feb 2014 10:04:18 -0800 (PST) Received: by 10.227.10.196 with HTTP; Tue, 18 Feb 2014 10:04:18 -0800 (PST) In-Reply-To: References: <10C8325A-F234-4034-BD05-D0D24C0B562B@vidyo.com> Date: Tue, 18 Feb 2014 10:04:18 -0800 Message-ID: From: Martin Thomson To: Suhas Nandakumar Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/eO9ChrW2G6mD4AaVh_2_QoT5yjM Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] MSID and AppID: solving different problems 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, 18 Feb 2014 18:04:23 -0000 On 13 February 2014 14:43, Suhas Nandakumar wrote: > [Suhas] How about the name SSID (Source Stream ID) to identify the > individual RTP packet streams I was thinking that the really useful feature was the label applied by the receiver, not the source. Maybe something like "receiver SSRC ID" (or "receiver SSRC label"). I think that hits the mark. From nobody Wed Feb 19 08:11:14 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 A26221A021B for ; Wed, 19 Feb 2014 08:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.548, 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 Ira_--8BORfz for ; Wed, 19 Feb 2014 08:11:10 -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 E6E631A0209 for ; Wed, 19 Feb 2014 08:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7756; q=dns/txt; s=iport; t=1392826267; x=1394035867; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NZVW3nI6V1JvK2jltznsZR05R1a/jtHkIMNLAXlh3Wc=; b=BspOpYPoNfy4Rv+tBGzqkcCSojN4FKTS8ee4NFSabVhutRUVhvuxLIR7 7A6drGbW9OYPYQyuLjbOhOo83eqSNjKKrP0Ft36G1TukK2bYcPAf78Yjr e0/vBQBv6wmX3G5j1SqkKk+zSvaAyQI09VE1Og1P3WiDYS6FgZb+JRzRq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFALLWBFOtJXG//2dsb2JhbABZgkJEgQ+/eYEXFnSCJQEBAQR5EAIBCA4DAwECKAchERQJCAIEDgWHcQMRxX8Nh34XjE+CBBEHhDgElkSBbIxehUaDLYIq X-IronPort-AV: E=Sophos; i="4.97,506,1389744000"; d="scan'208,217"; a="21593012" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-1.cisco.com with ESMTP; 19 Feb 2014 16:11:04 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1JGB3d3018683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 16:11:03 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 10:11:03 -0600 From: "Charles Eckel (eckelcu)" To: Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08 Thread-Index: AQHO/YcWZ2DzntYTsE+pusHe8am5zZp+TQkAgABw7wCABL+ZAIAwa9+AgAkUVYA= Date: Wed, 19 Feb 2014 16:11:03 +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.74.217] Content-Type: multipart/alternative; boundary="_000_CF2A162F1F4C5eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7ZgFxCQVbOsX6LSE5-qOXJfujG8 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: Wed, 19 Feb 2014 16:11:12 -0000 --_000_CF2A162F1F4C5eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tom, The proposed changes look good. One question inline with the rest of the te= xt omitted. From: Tom Kristensen <2mkristensen@gmail.com= > Date: Thursday, February 13, 2014 at 5:31 AM To: Charles Eckel > Cc: "Ali C. Begen (abegen)" >, To= m Kristensen >, "bfcpbis-chai= rs@tools.ietf.org" >, "draft-ietf-bfcpbis-rf= c4583bis@tools.ietf.org" >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583= bis-08 On 14 January 2014 03:05, Charles Eckel (eckelcu) > wrote: I am afraid Ali is right. Let's take the SHOULDs 1 by 1 and see how to deal with them. 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. True, and as proposed in the accompanying BFCPbis WG PROTO review thread me= rging in this requirement for implementations of the upcoming RFCXXX of thi= s draft. The paragraph will then read: "Endpoints that use the offer/answer model to establish BFCP connections SHOULD support the 'bfcpver' attribute. A floor control server acting as an offerer or as an answerer SHOULD include this attribute in its session descriptions. However, endpoints that support RFCXXXX, and not only the RFC 4583 subset, are REQUIRED to support and, when acting as a floor control server to use the 'bfcpver' attribute. [...]" Why is the condition ", when acting as a floor control server=94 relevant h= ere? Cheers, Charles --_000_CF2A162F1F4C5eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0E7ED644338636418BBF70FA7232DD25@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Tom,

The proposed changes look good. One question inline with the rest of the te= xt omitted.

From: Tom Kristensen <2mkristensen@gmail.com>
Date: Thursday, February 13, 2014 a= t 5:31 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: "Ali C. Begen (abegen)&quo= t; <abegen@cisco.com>, Tom Kr= istensen <tomkrist@cisco.com&g= t;, "bfcpbis-chairs@t= ools.ietf.org" <bfcpbis-chairs@tools.= ietf.org>, "draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org" <draft-ietf-bfc= pbis-rfc4583bis@tools.ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] SDP Directora= te: Review of draft-ietf-bfcpbis-rfc4583bis-08

On 14 January 2014 03:05, Charles Eckel (eckelcu) <eckelcu@cisco.co= m> wrote:
I am afraid Ali is right. Let's take the SHOULDs 1 by 1 and see how to
deal with them.

<snip>
 
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.

True, and as proposed in the accompanying BFCPbis WG PROTO = review thread merging in this requirement for implementations of the upcomi= ng RFCXXX of this draft. The paragraph will then read:

  "Endpoints that use the offer/answer model to e= stablish BFCP
   connections SHOULD support the 'bfcpver' attri= bute. A floor control
   server acting as an offerer or as an answerer = SHOULD include
   this attribute in its session descriptions. &n= bsp; However, endpoints that
   support RFCXXXX, and not only the RFC 4583 sub= set, are
   REQUIRED to support and, when acting as a floo= r control server
   to use the 'bfcpver' attribute.  [...]&qu= ot;

Why is the condition ", = when acting as a floor control server=94 relevant here?

Cheers,
Charles
--_000_CF2A162F1F4C5eckelcuciscocom_-- From nobody Sat Feb 22 12:05: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 D86141A0171 for ; Sat, 22 Feb 2014 12:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_17=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 pjDhXaps_2Oe for ; Sat, 22 Feb 2014 12:05:18 -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 A9FA91A0166 for ; Sat, 22 Feb 2014 12:05:18 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id VY591n0030cZkys53Y5Eyr; Sat, 22 Feb 2014 20:05:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id VY5D1n00d3ZTu2S3WY5E2A; Sat, 22 Feb 2014 20:05:14 +0000 Message-ID: <530902F8.3020905@alum.mit.edu> Date: Sat, 22 Feb 2014 15:05:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <526D51D1.3090106@alum.mit.edu> <03FBA798AC24E3498B74F47FD082A92F3D86D026@US70UWXCHMBA04.zam.alcatel-lucent.com> <526E8BF5.7080206@alum.mit.edu> <52F11C71.7020103@alum.mit.edu> In-Reply-To: <52F11C71.7020103@alum.mit.edu> 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=1393099514; bh=avNaGJcq9iCmfxQoTSuth8wUDTFrsAHGURAznxWe9KY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=U3V/cBbvBg9JsHsfBzPLk2EocsZukIKnJpEPDSiRBqlty3nyg/G5GO2726Iyq+mwI rLx0sf408MJFBIxVKy5sxtLXoagf1MPxAYxnz7rWG48pPr9tq0HkDLDnfx3ygan5zh RJZIXpLvk2Zs3XH4UB49IDpeQLZyL5VKSfqhC/0Qh1JJX4D/pQzcWvnmRTe49bbs1P 1HeAdk8UfMnGfORY71xt/eD5eG63Z1tZzTxmgn57izcarYbCjydpOOhLL3W7kAAadT SNdNGBIgpTFYvjd4OHkJQFegbNiVdk3i3g+34c5JsnFlcgl67kctw0glzWV7vUX9iQ 72/o0ROgnBoOA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rUIJ5f5eamumXrx8s-dy9DnQfso Subject: Re: [MMUSIC] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-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: Sat, 22 Feb 2014 20:05:21 -0000 Long ago I made some comments on an earlier version. At least some of those were adopted in this version. Now I'm reviewing it again. Here are new thoughts: * General comment about document organization: IMO there is a muddling of responsibilities among several drafts. I suggest that it could be improved, as follows. (This isn't a big change from the current situation, but rationalizes the layering.): - draft-ietf-mmusic-sctp-sdp SDP for declaration/negotiation of SCTP associations. Defines a=sctpmap and establishes registry for "app" values. Defines what the registration of an app must specify. (This is currently deficient.) (Shouldn't register any - the registration of "webrtc-datachannel should be removed.) - draft-ietf-rtcweb-data-channel Should register an "app" name for data channels. (Preferably a more generic name than "webrtc-datachannel".) Should define (or reference an existing) IANA registry for data channel protocols. (This currently isn't done anywhere I can find.) As now, defines internal and external negotiation of data channels. (Should probably have what is now section 4 of this (ejzak) draft.) As now, specifies that "webrtc-datachannel" implies support for internal negotiation via rtcweb-data-protocol. - this draft (draft-ejzak-dispatch-webrtc-data-channel-sdpneg) Make it clear that it just specifies a way to do external negotiation of data channels for "webrtc-datachannel" SCTP associations. Shouldn't cover any other kinds of SCTP associations. (Except to explain how external negotiation of channels can replace use of multiple sctp associations.) * Section 4 This section should probably be moved to draft-ietf-rtcweb-data-channel. Section 5.1.1: The 'maxretr', 'maxtime', and 'unordered' parameters are presumably intended to correspond to the Channel Type and Reliability Parameter elements in section 5.1 of draft-ietf-rtcweb-data-protocol. This should be made clear. (And are all Channel Types covered?) The 'subprotocol' parameter is presumably intended to be the same thing that is called "protocol" in sections 5.1 and 8.4 of draft-ietf-rtcweb-data-protocol. These ought to be linked and be consistent about naming. Also, then syntax is: subprotocol-attr = "subprotocol=" labelstring labelstring = text text = byte-string (Where labelstring and text are the same as in the syntax of the label parameter.) This is misleading. It should probably be: subprotocol-attr = "subprotocol=" protocol-string protocol-string = text text = byte-string Thanks, Paul From nobody Sat Feb 22 15:07: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 A089F1A01E6 for ; Sat, 22 Feb 2014 15:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 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, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=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 Lsv0DCpD_NBl for ; Sat, 22 Feb 2014 15:07:12 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 966061A01E2 for ; Sat, 22 Feb 2014 15:07:12 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta06.westchester.pa.mail.comcast.net with comcast id Vamg1n0011ei1Bg56b77Qk; Sat, 22 Feb 2014 23:07:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id Vb771n00G3ZTu2S3kb77ww; Sat, 22 Feb 2014 23:07:07 +0000 Message-ID: <53092D9B.80904@alum.mit.edu> Date: Sat, 22 Feb 2014 18:07:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IETF MMUSIC WG 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=1393110427; bh=a3l4JMhlrp2hLvZwjgHI5QnckZetC9dZLekdEzKFwIA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FdbWMPsA0978egDn4KnCMS9T45hr0TN29NS5b10rU2/Jqv1RxZx5bgCFiE3AIA9VG W538a6UcsgTk5hem2a/Z1n7XjFXL6tG3DFoBFZO1JO3w6CkcP8MV1QztiMyxNWXdeA j7kCxJNY6lfQXx/8ItrkZJdbiRUv02l9dvHGC9Z8MencKL/n36OF6Da+RTzbKl9IlA 8XVcaQjYTRcvqC29icozwDOfZiHqHEjyvp8ATtKh+v5VfKPfP8Lcu+qwnrbiDpLdeC ISPIdEWijacIdSwCJAFWV+qOUYIAN0VG0JdAEuWRzWKnUVyPdOFDj/1GfSxwQk57P5 0nt2A7rWrgDfA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/slEY_is-I4XC6FPway_EahQLDZ8 Subject: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06 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, 22 Feb 2014 23:07:14 -0000 I've commented earlier on some threads about this draft. Now I'm going through it carefully again, and have new comments: * Section 4: This covers media descriptions using three different fields: 'SCTP', 'SCTP/DTLS', and 'DTLS/SCTP'. For both 'SCTP' and 'SCTP/DTLS' the "bottom" of the protocol stack is SCTP, and the identifier of one end for an association consists of an IP address and an SCTP port. This fits with m-line syntax - the SCTP port number can be carried in the field. For 'DTLS/SCTP', the "bottom" of the protocol stack is UDP, with SCTP over it. In this case the identifier for one end of an association consists of an IP address, an SCTP port, and a UDP port. This doesn't fit well into the syntax of an m-line. Because the *UDP* port is carried in the field, for a single m-line there can be multiple DTLS/SCTP associations, one per SCTP port number. The field is repurposed to carry the SCTP port numbers. Then, the problems caused by DTLS/SCTP are propagated to 'SCTP' and 'SCTP/DTLS' usages, by also placing the SCTP port number in the field in these usages. (For these protos it is redundant.) Because is used this way, it was necessary to introduce a=sctpmap to specify what otherwise could have been specified using the field. IMO this could be made much clearer by making the following changes: - an m-line with of 'SCTP', 'SCTP/DTLS', or 'DTLS/SCTP' always describes a *single* SCTP association. - define the usage of for these protos so that it can be used to carry the info currently in sctpmap, and in the DTLS/SCTP the SCTP port number. - use BUNDLE for the (unlikely) case of multiple SCTP associations over a single UDP port. It is a little difficult, but possible, to fit they necessary info into the restricted syntax of . Here is an example of one possibility: m=application 12345 DTLS/SCTP webrtc-datachannel \ sctp-port#1 streams#16 max-message-size#100000 The following is a syntax that does does that: sctp-m-line = %x6d "=" ("application" SP sctp-port SP "SCTP" SP sctp-fmt CRLF) / ("application" SP sctp-port SP "SCTP/DTLS" SP sctp-fmt CRLF) / ("application" SP udp-port SP "DTLS/SCTP" SP sctp-fmt CRLF) sctp-port = port udp-port = port sctp-fmt = sctp-app *(SP sctp-param) sctp-app = token sctp-param = maxmsg-param / streams-param / sctp-port-param maxmsg-param = "max-message-size#" port streams-param = "streams#" 1*DIGIT sctp-port-param = "sctp-port#" sctp-port (The use of "#" as separator isn't ideal, but it is the best choice of what is permitted in a token, and it seems to read reasonably well. If people hate this there are other ways to get the same effect.) Of course sctp-port-param is only meaningful with DTLS/SCTP. It and the other sctp-params can be optional, with suitable defaults defined. (For normal use, with only one association per UDP port everyone would probably take the default sctp port, and so the parameter could be omitted.) This then also allows a=fmtp to be used with these - most likely only with sctp-app. E.g., m=application 12345 DTLS/SCTP webrtc-datachannel \ sctp-port#1 streams#16 max-message-size#100000 c=IN IP4 example.com a=fmtp:webrtc-datachannel At the moment nothing webrtc-datachannel specific has been defined that needs to be declared in SDP, so this may not be needed. It *could* be used as a replacement for "a=dcmap" in draft-ejzak-mmusic-data-channel-sdpneg. Bundling would apply in a case such as in section 10.1 of draft-ietf-mmusic-sdp-bundle-negotiation-05. That example would be rewritten as follows: a=group:BUNDLE dc bfcp t38 m=application 12345 DTLS/SCTP webrtc-datachannel \ sctp-port#5000 streams#16 max-message-size#100000 c=IN IP4 example.com a=mid:dc m=application 12345 DTLS/SCTP bfcp \ sctp-port#5001 streams#1 max-message-size#16384 c=IN IP4 example.com a=mid:bfcp m=application 12345 DTLS/SCTP t38 \ sctp-port#5002 streams#1 max-message-size#65536 c=IN IP4 example.com a=mid:t38 * Section 5.1: This section starts out with: The sctpmap attribute maps from a port number (as used in an "m=" line) to an encoding name denoting the payload format to be used on top of the SCTP association or the actual protocol running on top of it. This is just wrong. It doesn't really map to an encoding name denoted a payload format. Immediately following the above is: The sctpmap MUST include the app parameter indicating the application running on top of the association. And the syntax defines an app parameter, instead of an encoding name. And as best I can tell the app parameter doesn't denote a payload format. (Payload formats can vary from stream to stream.) The app seems to denote the overall set of conventions that are used to ascribe meaning and format to the streams. (This needs better definition. Section 11.1 has an open issue to define a new IANA registry for this. But there is also need to say more about the semantics - what a new value must specify.) Later in this section: Any offered association MAY be rejected in the answer, for any reason. If an association offer is rejected, the offerer and answerer MUST NOT establish an SCTP association for it. To reject an SCTP association, the SCTP port number in the "a=sctpmap:" attribute line in the answer MUST be set to zero. In the case of DTLS/SCTP there are two ports - the udp port and the sctp port. Either can be set to zero, with different consequences. Something should be said about the behavior when the udp port is set to zero. (Of course my suggestion to revamp the m-line renders this moot.) * Section 7: What if the c= line contains a DNS name rather than an IP address? Can that cause the initialization of more than one IP address? * Section 8: This contains the following statements: ... Therefore, this specification does not define how to describe SCTP-over-UDP streams in SDP or how to establish and maintain SCTP associations using ICE. Should these features be specified for SCTP in the future, there will be a need to specify how to use them in an SDP environment as well. Doesn't the definition of DTLS/SCTP render the above incorrect? Thanks, Paul From nobody Sat Feb 22 19:03: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 E1C991A0281 for ; Sat, 22 Feb 2014 19:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_17=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 WoYAfIGSsab0 for ; Sat, 22 Feb 2014 19:03:23 -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 A9AA71A027E for ; Sat, 22 Feb 2014 19:03:22 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id VexA1n00317dt5G5Af3HQZ; Sun, 23 Feb 2014 03:03:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Vf3H1n00B3ZTu2S3Zf3H64; Sun, 23 Feb 2014 03:03:17 +0000 Message-ID: <530964F5.8030004@alum.mit.edu> Date: Sat, 22 Feb 2014 22:03:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <526D51D1.3090106@alum.mit.edu> <03FBA798AC24E3498B74F47FD082A92F3D86D026@US70UWXCHMBA04.zam.alcatel-lucent.com> <526E8BF5.7080206@alum.mit.edu> <52F11C71.7020103@alum.mit.edu> <530902F8.3020905@alum.mit.edu> In-Reply-To: <530902F8.3020905@alum.mit.edu> 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=1393124597; bh=Nv3moG7UXOOTiI/oCizR0mXePCwJLC8ton4gHDcQip8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y+XDzWmgxbLiVIM2UsPOYWPGd1WmrtzMov8GMgf9vS3jEqx35UiLWM55hktPM+e+O AGllTuBt3ccCrQijWAYhnwHXGuzznkDz6GOVqeGpv6P1MhctZ1RBo8X5W49BAjl9zI y9VOvhFQ3qrfxXhM3/tcWPTn7hPcsEwTDjDjrvBQRf/gWLA7NMJbkeBt7fyjaLfvyu COU8zlFNRpWZIXJV7UqQaSIlgyXbS+r27jD0NHkuXW3qOwuegfLwpQBp/+DtGBtH/x tMsXh42GSDDpRafcfsT9SPd2/50FfLjB8aukEpIAglOJKc0j79sDfCCFzfPT7Rmjcn ShtAhz72EvrEA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UbNSTpyoL87Fgbs1-r1gou17bUM Subject: Re: [MMUSIC] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-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: Sun, 23 Feb 2014 03:03:25 -0000 On 2/22/14 3:05 PM, Paul Kyzivat wrote: > Long ago I made some comments on an earlier version. At least some of > those were adopted in this version. Now I'm reviewing it again. Here are > new thoughts: > > * General comment about document organization: > > IMO there is a muddling of responsibilities among several drafts. I > suggest that it could be improved, as follows. (This isn't a big change > from the current situation, but rationalizes the layering.): > > - draft-ietf-mmusic-sctp-sdp > > SDP for declaration/negotiation of SCTP associations. > Defines a=sctpmap and establishes registry for "app" values. > > Defines what the registration of an app must specify. (This is currently > deficient.) > > (Shouldn't register any - the registration of "webrtc-datachannel should > be removed.) > > - draft-ietf-rtcweb-data-channel > > Should register an "app" name for data channels. (Preferably a more > generic name than "webrtc-datachannel".) > > Should define (or reference an existing) IANA registry for data channel > protocols. (This currently isn't done anywhere I can find.) My mistake - is currently done by draft-ietf-rtcweb-data-protocol-03. But I think it would make more sense to define the registry in draft-ietf-rtcweb-data-channel so that it is known to also be applicable to externally negotiated channels. > As now, defines internal and external negotiation of data channels. > (Should probably have what is now section 4 of this (ejzak) draft.) > > As now, specifies that "webrtc-datachannel" implies support for internal > negotiation via rtcweb-data-protocol. > > - this draft (draft-ejzak-dispatch-webrtc-data-channel-sdpneg) > > Make it clear that it just specifies a way to do external negotiation of > data channels for "webrtc-datachannel" SCTP associations. > > Shouldn't cover any other kinds of SCTP associations. (Except to explain > how external negotiation of channels can replace use of multiple sctp > associations.) > > * Section 4 > > This section should probably be moved to draft-ietf-rtcweb-data-channel. > > Section 5.1.1: > > The 'maxretr', 'maxtime', and 'unordered' parameters are presumably > intended to correspond to the Channel Type and Reliability Parameter > elements in section 5.1 of draft-ietf-rtcweb-data-protocol. This should > be made clear. (And are all Channel Types covered?) > > The 'subprotocol' parameter is presumably intended to be the same thing > that is called "protocol" in sections 5.1 and 8.4 of > draft-ietf-rtcweb-data-protocol. These ought to be linked and be > consistent about naming. > > Also, then syntax is: > > subprotocol-attr = "subprotocol=" labelstring > labelstring = text > text = byte-string > > (Where labelstring and text are the same as in the syntax of the label > parameter.) This is misleading. It should probably be: > > subprotocol-attr = "subprotocol=" protocol-string > protocol-string = text > text = byte-string > > Thanks, > Paul > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Sun Feb 23 15:13: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 CC1E61A0765 for ; Sun, 23 Feb 2014 15:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Wm5EY4qIW31B for ; Sun, 23 Feb 2014 15:13:29 -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 860A31A01D2 for ; Sun, 23 Feb 2014 15:13:29 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id Vytc1n0041ZXKqc54zDUaE; Sun, 23 Feb 2014 23:13:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id VzDU1n00u3ZTu2S3hzDUr9; Sun, 23 Feb 2014 23:13:28 +0000 Message-ID: <530A8098.50309@alum.mit.edu> Date: Sun, 23 Feb 2014 18:13:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IETF MMUSIC WG 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=1393197208; bh=oUhy1mATPWtifYWLbKJiKVRyeLxm8VejNRRuRnNQGXw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m0OBJmSh8t1EJx+1K6ccDxncih6r8aVZ/0adoxHAEhKI8G/53NCal/+QSBq3YM/Gz jcieQB+IJaflKFvm3WyOyoo6pOgSin0ca1wGuqYfWwWP41RB92EMf9i1IdpaEQmY4Y Ue35jGBzn8Y5mgedXDm7Soa2T0ccZnriBFdKprjTRMph19KpjKTCbhgS80BQm5GXEM HhnAmjh8nKJ4lfZb0FB2eKeQsnwE6k5gvwNhshXjGyemZjETYLYZMQ1+54rbdGeaH8 Kj4VNjVop92BIxV3wnQXVL5+1XjB1AGOxffuhE1JgO+9a5s3MA4SDVrsyePa0jdoEa byzFnj1fz1wNw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xXDhxe9UcAa8vOqSpvMbn5LV0rE Subject: [MMUSIC] Comments on draft-ejzak-dispatch-msrp-data-channel-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: Sun, 23 Feb 2014 23:13:31 -0000 A few comments/questions on this draft: Section 5.1.1.2 says: The msrp-cema attribute shall be assumed to be present for every MSRP session using data channel transport, so the inclusion of the msrp- cema attribute is optional. This ensures that the data channel transport for the MSRP session is established without using the path attribute. Why is use of cema mandatory? RGC6714 has fallback rules for an endpoint that supports cema to interoperate with one that does not. That requires removing the indication of cema support. How does an msrp data channel endpoint do that? Section 5.1.3 says: Each text-based MSRP message is sent on the corresponding SCTP stream using standard MSRP framing and chunking procedures, as defined in [RFC4975], with each MSRP chunk delivered in a single SCTP user message. I think it would be better to say: Each text-based MSRP message is sent on the corresponding SCTP stream using standard MSRP framing and chunking procedures, as defined in [RFC4975], with each MSRP chunk delivered in a single Data Channel user message. While data channel user messages map directly onto SCTP user messages, they are conceptually distinct. Section 6 says: o The endpoint establishing an MSRP session using data channel transport shall not request inclusion of any relays, although it may interoperate with a peer that signals the use of relays. Why must relays not be requested? That seems the most natural thing to do if the goal is to talk to a peer that doesn't support data channels. In any case, some explanation of how things work with relays would be appreciated. Thanks, Paul From nobody Sun Feb 23 17:13: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 B02A71A078D for ; Sun, 23 Feb 2014 17:13:11 -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_80=2, 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=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 XFdVFYAXng5j for ; Sun, 23 Feb 2014 17:13:09 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id ECBFB1A06FD for ; Sun, 23 Feb 2014 17:13:08 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id gl10so1816671lab.0 for ; Sun, 23 Feb 2014 17:13:08 -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=IFhryLvZKbAS98Y/TZFCDb4TQ6yfq436g42jMOxR/yI=; b=pHu/YxE3MO9NG9WHdZsLwEGZ2TSnzRyT8AiKc6GW2Y1B6ZNe+7imQ3bgcTiLRjkTaK CxcWWQ6I3zxHffbDxndEbyHHD79oWiiQGa29amuFkwobFMpy1jbS/nXwgP8ek3I13FxM 7aJ4FOYcm4S5lZVlIMvjmDyxCdpRY6Gk7ywLt4duaUKLlfIokVCvIP2nUEZN4xytzfs8 qD2j39N6XztqZpUCHiYZeEs6CW5PxnpLAGpZ+UFdzJYAlM+FCCFjU5hDAyuUTf6PEzj3 LaFFo+X4Z6qkuMTCtne/muX3ag2NzEDc/2gLIZgKUjnuIhDXP/CzMVS+kjNZt8uDbYA/ m0ew== MIME-Version: 1.0 X-Received: by 10.152.36.8 with SMTP id m8mr10703656laj.24.1393204387912; Sun, 23 Feb 2014 17:13:07 -0800 (PST) Received: by 10.112.98.132 with HTTP; Sun, 23 Feb 2014 17:13:07 -0800 (PST) In-Reply-To: <530A8098.50309@alum.mit.edu> References: <530A8098.50309@alum.mit.edu> Date: Sun, 23 Feb 2014 19:13:07 -0600 Message-ID: From: Richard Ejzak To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e0160c16ca41ee304f31cacf7 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/v2uwMdrl70lwFfmjsC2N7-RJuhg Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ejzak-dispatch-msrp-data-channel-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: Mon, 24 Feb 2014 01:13:12 -0000 --089e0160c16ca41ee304f31cacf7 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 23, 2014 at 5:13 PM, Paul Kyzivat wrote: > A few comments/questions on this draft: > > Section 5.1.1.2 says: > > The msrp-cema attribute shall be assumed to be present for every MSRP > session using data channel transport, so the inclusion of the msrp- > cema attribute is optional. This ensures that the data channel > transport for the MSRP session is established without using the path > attribute. > > Why is use of cema mandatory? > Existing MSRP procedures (without CEMA) are based on using the Path attribute to establish the transport connection (and essentially ignore the connection information associated with the m line). If you are going to use a data channel, then you have no choice but to use the one established by the peer connection, so the existing MSRP procedure will NOT WORK. CEMA allows you to set up a tls or tcp connection based on the connection information in the m line rather than in the path attribute, but this is still not everything needed to make it work with data channels. But it's a start. > RGC6714 has fallback rules for an endpoint that supports cema to > interoperate with one that does not. That requires removing the indication > of cema support. How does an msrp data channel endpoint do that? > Interoperating with an endpoint that does not support data channel will require going through a gateway that does. This gateway will have to do something to provide a tls or tcp transport connection suitable for the other peer. If the gateway can't do the enhanced CEMA procedures described here, it will have to perform as an MSRP B2BUA. > > Section 5.1.3 says: > > Each text-based MSRP message is sent on the corresponding SCTP stream > using standard MSRP framing and chunking procedures, as defined in > [RFC4975], with each MSRP chunk delivered in a single SCTP user > message. > > I think it would be better to say: > > Each text-based MSRP message is sent on the corresponding SCTP stream > using standard MSRP framing and chunking procedures, as defined in > [RFC4975], with each MSRP chunk delivered in a single Data Channel > user message. > > While data channel user messages map directly onto SCTP user messages, > they are conceptually distinct. > Agreed. > > Section 6 says: > > o The endpoint establishing an MSRP session using data channel > transport shall not request inclusion of any relays, although it > may interoperate with a peer that signals the use of relays. > > Why must relays not be requested? That seems the most natural thing to do > if the goal is to talk to a peer that doesn't support data channels. > The MSRP relay is not typically on the signaling path, so is an unlikely data channel endpoint unless a separate peer connection and data channel is established just for MSRP. This would be silly to do. We want a gateway that is on the signaling path to perform any necessary conversion. The CEMA gateway model is a much better fit and makes the use of relays unnecessary (at least on the side of the user using a data channel for MSRP). > > In any case, some explanation of how things work with relays would be > appreciated. > I must say that CEMA is confusing, and I agree that the CEMA parts of the document are not easy to follow without a thorough understanding of CEMA. Since the CEMA RFC already explains all the confusing bits, I'm reluctant to repeat all of that here... Perhaps a note that a thorough understanding of CEMA is necessary background for the CEMA stuff here? Richard > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --089e0160c16ca41ee304f31cacf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Feb 23, 2014 at 5:13 PM, Paul Kyzivat <= ;pkyzivat@alum.m= it.edu> wrote:
A few comments/questions on this draft:

Section 5.1.1.2 says:

=A0 =A0The msrp-cema attribute shall be assumed to be present for every MSR= P
=A0 =A0session using data channel transport, so the inclusion of the msrp-<= br> =A0 =A0cema attribute is optional. =A0This ensures that the data channel =A0 =A0transport for the MSRP session is established without using the path=
=A0 =A0attribute.

Why is use of cema mandatory?

Existing = MSRP procedures (without CEMA) are based on using the Path attribute to est= ablish the transport connection (and essentially ignore the connection info= rmation associated with the m line). =A0If you are going to use a data chan= nel, then you have no choice but to use the one established by the peer con= nection, so the existing MSRP procedure will NOT WORK. =A0CEMA allows you t= o set up a tls or tcp connection based on the connection information in the= m line rather than in the path attribute, but this is still not everything= needed to make it work with data channels. =A0But it's a start.


RGC6714 has fallback rules for an endpoint that supports cema to interopera= te with one that does not. That requires removing the indication of cema su= pport. How does an msrp data channel endpoint do that?

Interoperating with an endpoint that does not support d= ata channel will require going through a gateway that does. =A0This gateway= will have to do something to provide a tls or tcp transport connection sui= table for the other peer. =A0If the gateway can't do the enhanced CEMA = procedures described here, it will have to perform as an MSRP B2BUA.
=A0

Section 5.1.3 says:

=A0 =A0Each text-based MSRP message is sent on the corresponding SCTP strea= m
=A0 =A0using standard MSRP framing and chunking procedures, as defined in =A0 =A0[RFC4975], with each MSRP chunk delivered in a single SCTP user
=A0 =A0message.

I think it would be better to say:

=A0 =A0Each text-based MSRP message is sent on the corresponding SCTP strea= m
=A0 =A0using standard MSRP framing and chunking procedures, as defined in =A0 =A0[RFC4975], with each MSRP chunk delivered in a single Data Channel =A0 =A0user message.

While data channel user messages map directly onto SCTP user messages, they= are conceptually distinct.

Agreed.
=A0

Section 6 says:

=A0 =A0o =A0The endpoint establishing an MSRP session using data channel =A0 =A0 =A0 transport shall not request inclusion of any relays, although i= t
=A0 =A0 =A0 may interoperate with a peer that signals the use of relays.
Why must relays not be requested? That seems the most natural thing to do i= f the goal is to talk to a peer that doesn't support data channels.
=

The MSRP relay is not typically on the sig= naling path, so is an unlikely data channel endpoint unless a separate peer= connection and data channel is established just for MSRP. =A0This would be= silly to do. =A0We want a gateway that is on the signaling path to perform= any necessary conversion. =A0The CEMA gateway model is a much better fit a= nd makes the use of relays unnecessary (at least on the side of the user us= ing a data channel for MSRP).
=A0

In any case, some explanation of how things work with relays would be appre= ciated.

I must say that CEMA is confusi= ng, and I agree that the CEMA parts of the document are not easy to follow = without a thorough understanding of CEMA. =A0Since the CEMA RFC already exp= lains all the confusing bits, I'm reluctant to repeat all of that here.= .. =A0Perhaps a note that a thorough understanding of CEMA is necessary bac= kground for the CEMA stuff here?

Richard



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

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

--089e0160c16ca41ee304f31cacf7-- From nobody Mon Feb 24 09:36: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 7C5C11A0189; Mon, 24 Feb 2014 09:36: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] 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 DtTD2wI-xnq1; Mon, 24 Feb 2014 09:36:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE54A1A0250; Mon, 24 Feb 2014 09:36:06 -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: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140224173606.5255.90098.idtracker@ietfa.amsl.com> Date: Mon, 24 Feb 2014 09:36:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hErZOHqXEcqeDPBNM_dQmuPAFww Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-23.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, 24 Feb 2014 17:36:11 -0000 The IESG has approved the following document: - 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' (draft-ietf-mmusic-sdp-cs-23.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-sdp-cs/ *Technical Summary * The document 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 Publich Switched Telephone Network (PSTN) *Working Group Summary * The WG had some discussion around the format to use for E.164 numbers and whether to align this with the existing definition in RFC 3108. The RFC 3108 definition was seen as deficient and the WG agreed it was better to align with relevant parts of the tel URI format defined in RFC 3966, not least since SDP address types are defined in the context of a particular network type, and hence RFC 3108 compatibility is not a concern (the implication is that the "E164" address type may differ between network types in SDP). *Document Quality * There are currently no known implementations of the draft, however the draft is a dependency for 3GPP, so future implementations are expected. The document has received good overall review in the WG, some of which resulted in changes to the detailed specification. The document has been reviewed in detail several times, including of the last few versions. The major contributors to these as well as earlier discussions are listed in the Acknowledgements section of the document. *Personnel * Document Shepherd: Flemming Andreasen Responsible AD: Gonzalo Camarillo From nobody Mon Feb 24 11:51: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 241F01A0184 for ; Mon, 24 Feb 2014 11:51:20 -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_14=0.6, J_CHICKENPOX_17=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 NUaG3EK1NRb4 for ; Mon, 24 Feb 2014 11:51:18 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 04B5F1A0234 for ; Mon, 24 Feb 2014 11:51:16 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-bf-530ba2b37d5c Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 34.8F.04853.3B2AB035; Mon, 24 Feb 2014 20:51:15 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 20:51:15 +0100 From: Salvatore Loreto To: "Makaraju, Maridi Raju (Raju)" Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06.txt Thread-Index: Ac8sE6rAL3ZEGjbiSbSXIxi9o1wKTgFfbrAA Date: Mon, 24 Feb 2014 19:51:14 +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: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_FC95563C0BB6487892625D4E8AA15F8Dericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RnfzIu5ggw17VSymLn/MYtGw8Qqr A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mrout/OUvBzNWPFq9szWRoYl01l7GLk5JAQ MJH4332TGcIWk7hwbz1bFyMXh5DACUaJHf82sUA4Sxgljr+5zwZSxSZgJvH84RawDhEBV4mL y14A2RwczALqElcXB4GEhQWcJbo+LWKDKHGRuP3/PjuEbSRxrf0wK4jNIqAqcXvrQjCbV8Be YvLLWSwgtpBAjMSWfYfAjuMUiJXYc/MLE4jNCHTc91NrwGxmAXGJW0/mM0EcLSCxZM95qAdE JV4+/scKYStJLLr9Gao+WeLrxvNsELsEJU7OfMIygVF0FpJRs5CUzUJSBhE3kHh/bj4zhK0t sWzhayhbX2Ljl7OMELa1xLVbixiR1Sxg5FjFKFmcWlycm25koJebnluil1qUmVxcnJ+nV5y6 iREYkwe3/DbawXhyj/0hRmkOFiVx3uusNUFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGP2v Zy/0YtN1W8tQfoT5mkalxPaDJpO2P0j/e57pwp+OrH9lfM+PH+Y4eUv33I3TRtynHO+o3NF9 Kqsqyrjb727fFd7MpRvFsn/t0tqYcebyz0eqNzUFGi4/+N1r6szX07/W+UF6r7GYP6dbweRP CnFr18u4sfO9eXLlfffljr1vn3JcULBbvEaJpTgj0VCLuag4EQCxjVeSlwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VuLv7ZUO2EPXE7xq83MdEnEqnRQ Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06.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, 24 Feb 2014 19:51:20 -0000 --_000_FC95563C0BB6487892625D4E8AA15F8Dericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Feb 17, 2014, at 9:08 PM, "Makaraju, Maridi Raju (Raju)" > wrote: (Sorry for the duplicate post. Posting this again as this post did not get = any response probably due to posting issues!) >4.1 a=3Dsctpmap:5000 webrtc-datachannel max-message-size=3D100000 s= treams=3D16 >9.3 a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 s= treams=3D16 >11.1 'app' parameter and register as first value "webrtc-datachannel" fo= r [Raju] Above three types of representations of "webrtc-datachannel" should use a s= ingle value; The value may be based on the outcome from discussion that is going on a di= fferent thread. you are absolutely right, those are editorial typo I will address in the next version of the document >4.1 a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 streams= =3D16 [Raju] Instead of putting webrtc data channel attributes on the same line (= which gets long too), How about reusing existing a=3Dfmtp? as in: a=3Dfmtp:5000 max-message-size=3D100000 streams=3D16 or how about even further shortening it to? a=3Dfmtp:5000 mms=3D100000; streams=3D16 I have receive a similar comment before however my reading of RFC4566 is that a=3Dfmtp is defined only for specifyi= ng format parameter for a=3Drtpmap: if we want to use the same a=3Dfmtp for the a=3Dsctpmap it is necessary to = to specify this usage within the draft-ietf-mmusic-sctp-sdp-05, I don't have any problem to do so=85 if I see consensus on doing so. br Salvatore Then these attributes of 'app' protocol can be defined either in rtcweb-dat= a-channel and then IANA (section 11.1) will have a reference to it. Any such attribut= es defined for this or any generic 'app' protocol are carried in a=3Dfmtp line transpa= rently. Regards Raju > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, February 13, 2014 8:21 AM > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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 : Stream Control Transmission Protocol (SCTP)-Bas= ed > Media Transport in the Session Description Protocol (SDP) > Authors : Salvatore Loreto > Gonzalo Camarillo > Filename : draft-ietf-mmusic-sctp-sdp-06.txt > Pages : 14 > Date : 2014-02-13 > > Abstract: > SCTP (Stream Control Transmission Protocol) is a transport protocol > used to establish associations between two endpoints. This document > describes how to express media transport over SCTP in SDP (Session > Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' > and 'DTLS/SCTP' protocol identifiers for SDP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-06 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 --_000_FC95563C0BB6487892625D4E8AA15F8Dericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9D4DEECF5BF16D468A6EE5ED29747165@ericsson.com> Content-Transfer-Encoding: quoted-printable
On Feb 17, 2014, at 9:08 PM, "Makaraju, Maridi Raju (Raju)" = <Raju.Makaraju@alcat= el-lucent.com> wrote:

(Sorry for the duplicate post. Posting this again as this post did not get = any response probably due to posting issues!)
 
>4.1        a=3Dsctpmap:5000 webrtc-d= atachannel max-message-size=3D100000 streams=3D16
>9.3        a=3Dsctpmap:5000 webrtc-D= ataChannel max-message-size=3D100000 streams=3D16
>11.1   'app' parameter and register as first value "webr= tc-datachannel" for
 
[Raju]
Above three types of representations of "webrtc-datachannel" shou= ld use a single value;
The value may be based on the outcome from discussion that is going on a di= fferent thread.

you are absolutely right, 
those are editorial typo I will address in the next version of the doc= ument

 
 
>4.1 a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 strea= ms=3D16
 
[Raju] Instead of putting webrtc data channel attributes on the same line (= which gets long too), How about reusing existing a=3Dfmtp? as in:
a=3Dfmtp:5000 max-message-size=3D100000 streams=3D16
or how about even further shortening it to?
a=3Dfmtp:5000 mms=3D100000; streams=3D16

I have receive a similar comment before
however my reading of RFC4566 is that a=3Dfmtp is defined only for spe= cifying format parameter for a=3Drtpmap:

if we want to use the same a=3Dfmtp for the a=3Dsctpmap it is necessar= y to to specify this usage within the draft-ietf-mmusic-sctp= -sdp-05,
I don't have any problem to do so=85 if I see consensus on doing so.

br
Salvatore

 
Then these attributes of 'app' protocol can be defined either in rtcweb-dat= a-channel
and then IANA (section 11.1) will have a reference to it. Any such attribut= es defined
for this or any generic 'app' protocol are carried in a=3Dfmtp line transpa= rently.
 
Regards
Raju
 
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org= ] On Behalf Of internet-
> Sent: Thursday, February 13, 2014 8:21 AM
> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.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 C= ontrol
> Working Group of the IETF.
>
>         Title   = ;        : Stream Control Transmission P= rotocol (SCTP)-Based
> Media Transport in the Session Description Protocol (SDP)
>         Authors  &nb= sp;      : Salvatore Loreto
>            = ;            &n= bsp;  Gonzalo Camarillo
>     Filename        = : draft-ietf-mmusic-sctp-sdp-06.txt
>     Pages       &nbs= p;   : 14
>     Date        = ;    : 2014-02-13
>
> Abstract:
>    SCTP (Stream Control Transmission Protocol) is a tra= nsport protocol
>    used to establish associations between two endpoints= .  This document
>    describes how to express media transport over SCTP i= n SDP (Session
>    Description Protocol).  This document defines t= he 'SCTP', 'SCTP/DTLS'
>    and 'DTLS/SCTP' protocol identifiers for SDP.
>
>
> The IETF datatracker status page for this draft is:
>
> There's also a htmlized version available at:
>
> A diff from the previous version is available at:
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
>
> _______________________________________________
> mmusic mailing list
 
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/m= music

--_000_FC95563C0BB6487892625D4E8AA15F8Dericssoncom_-- From nobody Mon Feb 24 12:14:05 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 932691A024D for ; Mon, 24 Feb 2014 12:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=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 3YZkzY0B9s1z for ; Mon, 24 Feb 2014 12:13:59 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A9AE51A02BF for ; Mon, 24 Feb 2014 12:13:47 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1OKDi4l005866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 14:13:44 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s1OKDi9G032761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 15:13:44 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 15:13:44 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Salvatore Loreto Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06.txt Thread-Index: AQHPMZzq9igBjInaCEe2RJ4JfN69yQ== Date: Mon, 24 Feb 2014 20:13:43 +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: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFF5C02US70UWXCHMBA02z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hoqpWJzklgzu6y0_OQQb1iye8QA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06.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, 24 Feb 2014 20:14:02 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826DFF5C02US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >4.1 a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 streams= =3D16 [Raju] Instead of putting webrtc data channel attributes on the same line (= which gets long too), How about reusing existing a=3Dfmtp? as in: a=3Dfmtp:5000 max-message-size=3D100000 streams=3D16 or how about even further shortening it to? a=3Dfmtp:5000 mms=3D100000; streams=3D16 I have receive a similar comment before however my reading of RFC4566 is that a=3Dfmtp is defined only for specifyi= ng format parameter for a=3Drtpmap: if we want to use the same a=3Dfmtp for the a=3Dsctpmap it is necessary to = to specify this usage within the draft-ietf-mmusic-sctp-sdp-05, I don't have any problem to do so... if I see consensus on doing so. [Raju] This draft followed same m=3D line syntax for SCTP. Similr to RTP co= dec formats, SCTP has "port #s" as formats. SDP RFC 4566 Section 6 http://tools.ietf.org/html/rfc4566#se= ction-6 does allow additional attributes to be specified for these formats.= The text there does not say they are for RTP only. So, IMHO, we can use a= =3Dfmtp for data channel attributes. http://to= ols.ietf.org/html/rfc4566#section-6> m=3D ... ... a=3Dfmtp: This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. At most one instance of this attribute is allowed for each format. http://t= ools.ietf.org/html/rfc4566#section-6> Resulting example look like this; which seem to fit very naturally and same= look and feel as RTP case with the only difference being "rtpmap" is repla= ced, appropriately, with "sctpmap". m=3Dapplication 54111 DTLS/SCTP 5000 c=3DIN IP4 79.97.215.79 a=3Dsctpmap:5000 webrtc-datachannel a=3Dfmtp:5000 max-message-size=3D100000 streams=3D16 -Raju --_000_E1FE4C082A89A246A11D7F32A95A17826DFF5C02US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

>4.1 a=3Dsctpmap:5000 webrtc-DataChannel max-message-size=3D100000 str= eams=3D16

 

[Raju] Instead of putting webrtc data channel attributes on the same line= (which gets long too), How about reusing existing a=3Dfmtp? as in:

a=3Dfmtp:5000 max-message-size=3D100000 streams=3D16

or how about even further shortening it to?

a=3Dfmtp:5000 mms=3D100000; streams=3D16

 

I have receive a similar comment before

however my reading of RFC4566 is that a=3Dfmtp is de= fined only for specifying format parameter for a=3Drtpmap:

 

if we want to use the same a=3Dfmtp for the a=3Dsctp= map it is necessary to to specify this usage within the draf= t-ietf-mmusic-sctp-sdp-05,

I don't have any problem to do so… if I see co= nsensus on doing so.

[Raju] This draft f= ollowed same m=3D line syntax for SCTP. Similr to RTP codec formats, SCTP h= as “port #s” as formats. SDP RFC 4566 Section 6= http://tools.ietf.org/html/rfc4566#section-6 does allow additional attr= ibutes to be specified for these formats. The text there does not say they = are for RTP only. So, IMHO, we can use a=3Dfmtp for data channel attributes= .

 

<RFC 4566 Section 6 http://tools.ietf.= org/html/rfc4566#section-6>

 

    m=3D<media> <port> <proto> &= lt;fmt> ...

…<= /span>

      a=3Dfmtp:<= format 

         This attribute a= llows parameters that are specific to a

         particular forma= t to be conveyed in a way that SDP does not

         have to understa= nd them.  The format must be one of the formats<= /b>

         specified for th= e media.  Format-specific parameters may be any<= /b>

      set of parameters required to be c= onveyed by SDP and given

<= i>   unchanged to the media tool = that will use this format.  At most

      one instance of this attribute is = allowed for each format.

 

</RFC 4566 Section 6 http://tools.ietf.= org/html/rfc4566#section-6>

 

Resulting example l= ook like this; which seem to fit very naturally and same look and feel as R= TP case with the only difference being “rtpmap” is replaced, appropriately, with “sctpmap”.

 

m=3Dapplication 54111 DTLS/SCTP 5000

c=3DIN IP4 79.97.215.79

a=3Dsctpmap:5000 webrtc-datachannel

a=3Dfmtp:5000 max-message-size=3D100000 streams=3D16

 = ;

-Raj= u

 <= /p>

 

 

--_000_E1FE4C082A89A246A11D7F32A95A17826DFF5C02US70UWXCHMBA02z_-- From nobody Mon Feb 24 15:02: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 5A64D1A030A for ; Mon, 24 Feb 2014 15:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 dr6UejB8MeZX for ; Mon, 24 Feb 2014 15:02:01 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 442D71A01CB for ; Mon, 24 Feb 2014 15:02:01 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA11.westchester.pa.mail.comcast.net with comcast id WC391n0041HzFnQ5BP2035; Mon, 24 Feb 2014 23:02:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id WP1z1n00Y3ZTu2S3aP20dc; Mon, 24 Feb 2014 23:02:00 +0000 Message-ID: <530BCF67.40909@alum.mit.edu> Date: Mon, 24 Feb 2014 18:01:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Roni Even , Jonathan Lennox 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=1393282920; bh=nfRCwjw1oK9kBm9UmoJzl5kFhKeLxyY8OYHtQpjVmHM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bpj0RIcQHQWj/Y72X13JGcUR7TMQp7KkeMfrqEdYiKaUbmbot+ArwiXCBXEXN7yl5 oxxEEohABuXylP3ltKDwfqBFZ7y4pCod6DX3NIs1diEzFzqlwcUwYtBO6G7Lcx9a5K oiE8BL6lbKCf3FsKFF8szLFiv/+cU9ARYMSQg6YKYJO1hdBppxzG6boXpQlIPnHxMa 4wF/ETN3sjWTRWI4xfgD/wTIlZY5+8dZreEePKZoCtxCG2yBIa/Ep2AD+rENqi9LQf 5DxEm92gYFw40ngsQS5WYjQET3m5dO4Izt7Ssmt0Sr6POBn5+99nXxlYBqv59p7KHb zI0yPTHscEhIA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/dn6jJTuPdR2KVWqS13erh9yiCmU Cc: IETF MMUSIC WG Subject: [MMUSIC] Comments on draft-even-mmusic-application-token-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, 24 Feb 2014 23:02:02 -0000 This is much improved from prior versions I reviewed!!! General comments: I think this would be easier to read if in examples mnemonic values were used for appID tokes, rather than numbers. Now that recv-appId is being proposed, I think it would read better if there was symmetry in the names for the two directions. Also this mixing of hyphenated names with camelCase names is pretty ugly. So how about: app-id-send, app-id-recv? Section 3.1: The definition is a=appId:token a=appId:token a=appId:token : The formal representation of the appId token is: appId-attribute = "appId:" token *[WSP attribute] attribute =/ appId-attr ; The base definition of "attribute" is in [RFC4566]. ; (It is the content of "a=" lines.) ; WSP and DIGIT defined in [RFC5234] ; token defined in [RFC4566] The examples above are a bit misleading because the definition of 'attribute' includes the value. Also the above defines appId-attribute but then uses appId-attr. I think the following would be clearer: The definition is a=appId:token a=appId:token a=appId:token : The formal representation of the appId token is: appId-attribute = "appId:" token *[WSP attribute] attribute =/ appId-attribute ; The base definition of "attribute" is in [RFC4566]. ; (It is the content of "a=" lines.) ; WSP and DIGIT defined in [RFC5234] ; token defined in [RFC4566] ; att-field and att-value defined in [RFC4566] Section 3.1.3: The syntax here is messed up. I think you mean: The formal representation of recv-appId is: recv-appId-attribute = "recv-appId:" token attribute =/ appId-attr ; The base definition of "attribute" is in [RFC4566]. ; (It is the content of "a=" lines.) ; token defined in [RFC4566] Also, if there will be multiple appIds per m-line, with different roles, then won't the receiver care which role is assigned to each of the appIds it requests? How can that be specified? (Maybe the pt attribute specified later, but then this needs to be extended to allow that.) Section 3.2: Editor note: Since the appId is unique in an SDP session the app-Id group can be used also at the session level - do we want it? You say that an appID is unique to an SDP session. But must it not also be unique to an RTP session? If so, that seems like it could present problems - the two constraints might conflict for certain types of RTP middle boxes. Section 3.3.1: I'm confused. IIUC the appId attribute in an offer or answer defines the appIds that will be *sent* by the end sending that offer or answer. But the pt numbers in the corresponding m-line define the PTs that it will *receive*. Section 4: This is just an example of O/A. More is expected. Clear normative specifications, e.g.: Generating the Initial Offer Receiving the Initial Offer Generating the Initial Answer Receiving the Initial Answer Subsequent Offer/Answer Exchanges: Generating the Offer Receiving the Offer Generating the Answer Receiving the Answer Some things that need explanation: If recv-appId is used in an offer, that can lead to an answer that uses the same values in an appId. But can recv-appId be used in an answer? If so, what does that mean? What about the *next* O/A? Should the recv-appId from the prior O/A be repeated in the new one? For that matter, what is the meaning if the the token in an appId attribute changes from one O/A to the next? Thanks, Paul From nobody Tue Feb 25 07:25: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 8CA831A004E for ; Tue, 25 Feb 2014 07:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Om7LO4tw2gEq for ; Tue, 25 Feb 2014 07:25:01 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id B29531A0037 for ; Tue, 25 Feb 2014 07:25:00 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id WcGg1n0011vXlb856fQzud; Tue, 25 Feb 2014 15:24:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id WfQz1n0013ZTu2S3dfQzqt; Tue, 25 Feb 2014 15:24:59 +0000 Message-ID: <530CB5CA.708@alum.mit.edu> Date: Tue, 25 Feb 2014 10:24:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Richard Ejzak References: <530A8098.50309@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=1393341899; bh=iD5KdufGivAg1Z4qecJM1sgNnAcwAILfOpr4tmYvZ8s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SpaiId3McYRFzjfXfV9h8jO1nXxW8dhAQvLcLXlzNN6uXshdnMKYvVVsSLI0JgwNA LJaaI0sWYgiRrzb+ChFp7RRQl1c+J5NkltfC5uElgn+zaqJXBYHDzClF4EwKwo1kdN GUrQbH3vlDjHDG7pe3KY74iodtI5TaQzt+MHbcj0RFnqbLyBjF/I+kBIydgyE0GKOX FV/Bvst2l/rJi+FWNFTv3f5Tv5/2R29pVBY5eBLdIKT3LG4CVNPwyqdlAtssLyq2H+ YxEydDfL4QSAegqYgp/jlIe+hTR2OEDWjvo+m2DDJevRBZMf85jwQ/83nitUb3YiK2 DtmVSRInGoUcg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/x2xx-BJBPk7hNNUN3duTIa11ldI Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ejzak-dispatch-msrp-data-channel-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: Tue, 25 Feb 2014 15:25:02 -0000 On 2/23/14 8:13 PM, Richard Ejzak wrote: > > > > On Sun, Feb 23, 2014 at 5:13 PM, Paul Kyzivat > wrote: > > A few comments/questions on this draft: > > Section 5.1.1.2 says: > > The msrp-cema attribute shall be assumed to be present for every > MSRP > session using data channel transport, so the inclusion of the msrp- > cema attribute is optional. This ensures that the data channel > transport for the MSRP session is established without using the path > attribute. > > Why is use of cema mandatory? > > > Existing MSRP procedures (without CEMA) are based on using the Path > attribute to establish the transport connection (and essentially ignore > the connection information associated with the m line). If you are > going to use a data channel, then you have no choice but to use the one > established by the peer connection, so the existing MSRP procedure will > NOT WORK. Ahh! Of course. > CEMA allows you to set up a tls or tcp connection based on > the connection information in the m line rather than in the path > attribute, but this is still not everything needed to make it work with > data channels. But it's a start. > > > RGC6714 has fallback rules for an endpoint that supports cema to > interoperate with one that does not. That requires removing the > indication of cema support. How does an msrp data channel endpoint > do that? > > > Interoperating with an endpoint that does not support data channel will > require going through a gateway that does. This gateway will have to do > something to provide a tls or tcp transport connection suitable for the > other peer. If the gateway can't do the enhanced CEMA procedures > described here, it will have to perform as an MSRP B2BUA. I gather you are thinking that this gateway won't be an MSRP relay? > Section 5.1.3 says: > > Each text-based MSRP message is sent on the corresponding SCTP > stream > using standard MSRP framing and chunking procedures, as defined in > [RFC4975], with each MSRP chunk delivered in a single SCTP user > message. > > I think it would be better to say: > > Each text-based MSRP message is sent on the corresponding SCTP > stream > using standard MSRP framing and chunking procedures, as defined in > [RFC4975], with each MSRP chunk delivered in a single Data Channel > user message. > > While data channel user messages map directly onto SCTP user > messages, they are conceptually distinct. > > > Agreed. > > > Section 6 says: > > o The endpoint establishing an MSRP session using data channel > transport shall not request inclusion of any relays, although it > may interoperate with a peer that signals the use of relays. > > Why must relays not be requested? That seems the most natural thing > to do if the goal is to talk to a peer that doesn't support data > channels. > > > The MSRP relay is not typically on the signaling path, so is an unlikely > data channel endpoint unless a separate peer connection and data channel > is established just for MSRP. This would be silly to do. We want a > gateway that is on the signaling path to perform any necessary > conversion. The CEMA gateway model is a much better fit and makes the > use of relays unnecessary (at least on the side of the user using a data > channel for MSRP). ISTM there are lots of layers here. With webrtc the "signaling path" is pretty much out of scope, so it is unclear exactly what you mean in that case. (Usually there will be a web server on the signaling path between the two peers. Potentially that web server could have a relationship with an MSRP gw, that could have relay capabilities.) I guess I'm mostly just confused on how this all hangs together. > In any case, some explanation of how things work with relays would > be appreciated. > > > I must say that CEMA is confusing, and I agree that the CEMA parts of > the document are not easy to follow without a thorough understanding of > CEMA. Since the CEMA RFC already explains all the confusing bits, I'm > reluctant to repeat all of that here... Perhaps a note that a thorough > understanding of CEMA is necessary background for the CEMA stuff here? Maybe. Obviously *I* need to study CEMA more carefully. Thanks, Paul > Richard > > > > Thanks, > Paul > > _________________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/__listinfo/mmusic > > > From nobody Wed Feb 26 05:04:47 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 E0E801A00A2 for ; Wed, 26 Feb 2014 05:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 5t-6nQaqkFc3 for ; Wed, 26 Feb 2014 05:04:37 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 288BF1A02B6 for ; Wed, 26 Feb 2014 05:04:18 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-92-530de6510c34 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 99.74.04249.156ED035; Wed, 26 Feb 2014 14:04:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 14:04:16 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: draft-ejzak-mmusic-data-channel-sdpneg: Allignment with draft-ietf-mmusic-sctp-sdp-06 Thread-Index: Ac8y7cAS6dY38hPvTOKDNescE/oruQ== Date: Wed, 26 Feb 2014 13:04:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BC3EF@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1BC3EFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+JvjW7gM95ggwtvhS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOn7jzEVXNKtmHNnIXMD43/1LkZODgkBE4mFSx8zQdhiEhfu rWfrYuTiEBI4wiix69cVKGcJo0T/tc1AVRwcbAIWEt3/tEEaRATUJb7u7WEGsYUFEiS279jC ChFPlbg5uZkRpFxEQE+i55YtiMkioCrRMiUQpIJXwFfi7snFjCA2I9Da76fWgJ3ALCAucevJ fKhzBCSW7DnPDGGLSrx8/I8VwlaU+PhqH9h0ZoF8iW+92RAjBSVOznzCMoFRaBaSSbMQqmYh qYIo0ZFYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMXIUpxYn5aYbGWxiBAb8wS2/LXYwXv5r c4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MWtfiErjvnrD0+3BrD9fO q4pCLJ6V0R/ub96y+6Hg/Tmrs1e/eTi9IDfx1YbMH3v5NbYtnsf+aGJk/X7nHexXJzzVFKo8 EMHOX5p1+/jNe3fWtkxbtdxFj51dRi/4ybWkTX4811QXSXqvejNhUcfdJxdmpT1K9ZrjVNlY FPPUdppgheep8yIPLZRYijMSDbWYi4oTAX8LLQpGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/r_RqriLYgC7Lzxeza2mflPaE-oY Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: Allignment with draft-ietf-mmusic-sctp-sdp-06 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, 26 Feb 2014 13:04:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1BC3EFESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In the latest version (-06) of draft-ietf-mmusic-sctp-sdp it is no more all= owed (at least that is my reading when comparing the 05->06 diff) to assign= multiple SDP sctpmap attributes to a single m- line. I guess that doesn't affect the mechanism in draft-ejzak-mmusic-data-channe= l-sdpneg as such (eventhough some text may not be needed anymore). But, at = least the example/note in section 4 should be aligned. Example: m=3Dapplication 54111 DTLS/SCTP 5000 5001 5002 c=3DIN IP4 79.97.215.79 a=3Dsctpmap:5000 webrtc-datachannel a=3Dsctpmap:5001 bfcp a=3Dsctpmap:5002 t38 ...should be: m=3Dapplication 54111 DTLS/SCTP 5000 c=3DIN IP4 79.97.215.79 a=3Dsctpmap:5000 webrtc-datachannel (If you want to use multiple sctpmap attributes, I guess you would need to = assign one m- line for each). In addition, perhaps the SCTP port number is not needed in the extension at= tributes (dcmap, dcsa) defined in the draft? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D1BC3EFESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In the latest version (-06) of draft-ietf-mmusic-sct= p-sdp it is no more allowed (at least that is my reading when comparing the= 05->06 diff) to assign multiple SDP sctpmap attributes to a single m- l= ine.

 

I guess that doesn’t affect the mechanism in d= raft-ejzak-mmusic-data-channel-sdpneg as such (eventhough some text may not= be needed anymore). But, at least the example/note in section 4 should be = aligned.

 

Example:

 

m=3Dapplication 54111 D= TLS/SCTP 5000 5001 5002

c=3DIN IP4 79.97.215.79=

         &nb= sp;      a=3Dsctpmap:5000 webrtc-datachannel<= /o:p>

         &nb= sp;      a=3Dsctpmap:5001 bfcp

         &nb= sp;      a=3Dsctpmap:5002 t38

 

…should be:

 

m=3Dapplication 54111 D= TLS/SCTP 5000

c=3DIN IP4 79.97.215.79=

         &nb= sp;      a=3Dsctpmap:5000 webrtc-datachannel<= /o:p>

 

(If you want to use multiple sctpmap attributes, I g= uess you would need to assign one m- line for each).

 

In addition, perhaps the SCTP port number is not nee= ded in the extension attributes (dcmap, dcsa) defined in the draft?

 

Regards,

 

Christer

 

         &nb= sp;     

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D1BC3EFESESSMB209erics_-- From nobody Wed Feb 26 05:19: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 845061A02F5 for ; Wed, 26 Feb 2014 05:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, 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 gqkrGzItvK2N for ; Wed, 26 Feb 2014 05:19:15 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id BB7AA1A02E4 for ; Wed, 26 Feb 2014 05:19:14 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-21-530de9d0a4d5 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id E8.7C.04853.0D9ED035; Wed, 26 Feb 2014 14:19:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 14:19:12 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel Thread-Index: Ac8y9K3pwn95tj5YT7SqspOdgSm1jQ== Date: Wed, 26 Feb 2014 13:19:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BC4D7@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1BC4D7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvje6Fl7zBBrOmWlpMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXcnT2QrWC1ZsXnuE8YGxl1iXYycHBICJhIvpt5lh7DFJC7c W8/WxcjFISRwglGi+ccjZghnCaPEt94zQBkODjYBC4nuf9ogDSIC6hJf9/Ywg9jCAj4S8xo7 mUFKRASCJXY/jYYo0ZN4cbyRHSTMIqAqsfJtKkiYV8BXon/jAyYQmxFo7fdTa8BsZgFxiVtP 5jNBnCMgsWTPeWYIW1Ti5eN/rBC2osTHV/sYIerzJa7/vssIMVNQ4uTMJywTGIVmIRk1C0nZ LCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjZHFqcXFuupGBXm56bolealFmcnFx fp5eceomRmBcHNzy22gH48k99ocYpTlYlMR5r7PWBAkJpCeWpGanphakFsUXleakFh9iZOLg lGpgtLsbpXPg9zRhx0e5z5nEb6qvOKhxSijk3uRTl1iDFqWsmqcYK/P0/MH4+h9hIbNULPMr bheVT/A26LaPstpjZraqpOBqqu3RSdxXl2fsnhR5fK7jgY2H17gatb9z/jPNvG5dqf619z5H jm55wV4pNjHDeYEsi9LGP8vOiX4Rm6m+NlW7z0TWTomlOCPRUIu5qDgRAPq8yqZZAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ux-0O2BPSU6rVSprLehwOdZ_hPU Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel 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, 26 Feb 2014 13:19:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1BC4D7ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 5.2.3 says: "It is specific to the sub-protocol whether this closing must in addition be signaled to the peer via a new SDP offer/answer= exchange." Shouldn't the draft define how it is done using an SDP offer/answer exchang= e? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D1BC4D7ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 5.2.3 says:

 

”It is specific t= o the sub-protocol whether this closing must in

         &nb= sp;      addition be signaled to the peer via a ne= w SDP offer/answer exchange.”

 

Shouldn’t the draft define how it is done usin= g an SDP offer/answer exchange?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D1BC4D7ESESSMB209erics_-- From nobody Wed Feb 26 05:30:52 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 029D31A0321 for ; Wed, 26 Feb 2014 05:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, 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 Jv-GS2QFtimY for ; Wed, 26 Feb 2014 05:30:39 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id B3B901A031F for ; Wed, 26 Feb 2014 05:30:38 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-86-530dec7ca75a Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 75.DE.04853.C7CED035; Wed, 26 Feb 2014 14:30:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 14:30:36 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: Ac8y9YTn0Ql62f4ZSwiP0pv/vZVV7g== Date: Wed, 26 Feb 2014 13:30:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BC516@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1BC516ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+JvjW7tG95gg3MtrBZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs3705kLdulWXLi7mqmBcYV6FyMnh4SAicS2f4dZIWwxiQv3 1rN1MXJxCAmcYJT4N2cVlLOEUWL2pbvMXYwcHGwCFhLd/7RBGkQE1CW+7u1hBrGFBQIktq7q ZIGIh0pMefiVDaRcREBPYu/DKpAwi4CqROvVXnYQm1fAV+L61TlgrYxAe7+fWsMEYjMLiEvc ejKfCeIeAYkle84zQ9iiEi8f/4O6U1Hi46t9jBD1+RKzT25mhpgpKHFy5hOWCYxCs5CMmoWk bBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbI4tbg4N93IQC83PbdEL7UoM7m4 OD9Przh1EyMwMg5u+W20g/HkHvtDjNIcLErivNdZa4KEBNITS1KzU1MLUovii0pzUosPMTJx cEo1MK70uRH16nzS+uQ7DPb3dObpX7p/cfut+wtFl95tqKiec/zDl1f/MmYlLjE0lVzRsKbi qEnFiTXhL9Km+K5OYbY71J1atPq3QKdrhc5h422S7e972Flb+Zvi3gd3CbL9n6652spQrUDv vVqe0ud/KhYd2dnTxR7euMDmNnmn0rdrs7a8vGRwzkyJpTgj0VCLuag4EQB/D/YiWgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/OrJOmt624C3K2JgGA1BhZZdcP6c Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 26 Feb 2014 13:30:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1BC516ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 5.2.2 describes what an answerer does when accepting a data channel= : "The peer receiving such an SDP offer performs the following: ... o For accepted data channels, creates peer instances for the data channels with the browser using the channel parameters described in the SDP offer. Note that the browser is asked to create data channels with stream identifiers not "owned" by the agent." But, there is no text on rejecting a data channel in the SDP answer. The answer can of course reject the whole m- line, using port zero in the A= nswer m- line. But, how does the answerer reject an individual sub-protocol= data channel? Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted data ch= annels: "This line MUST be replicated without changes in the SDP answer, if the answerer accepts the offered data channel." I guess one way to reject would be to simply not include the dcmap attribut= e in the Answer, and the Offerer then needs to figure out what was rejected= based on the stream values not present in the Answer. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D1BC516ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 5.2.2 describes what an answerer does when a= ccepting a data channel:

 

  “The peer receiving such an SDP offer p= erforms the following:

 

        &nbs= p;       …

 

   o  For accepted data channels, cre= ates peer instances for the data

      channels with the bro= wser using the channel parameters described

      in the SDP offer.&nbs= p; Note that the browser is asked to create data

      channels with stream = identifiers not "owned" by the agent.”

 

But, there is no text on rejecting a data channel in= the SDP answer.

 

The answer can of course reject the whole m- line, u= sing port zero in the Answer m- line. But, how does the answerer reject an = individual sub-protocol data channel?

 

Section 5.1.1 says, regarding the SDP dcmap attribut= e, for accepted data channels:

 

“This line MUST b= e replicated without changes in the SDP answer, if

         &nb= sp;      the answerer accepts the offered data cha= nnel.”

 

I guess one way to reject would be to simply not inc= lude the dcmap attribute in the Answer, and the Offerer then needs to figur= e out what was rejected based on the stream values not present in the Answe= r.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D1BC516ESESSMB209erics_-- From nobody Wed Feb 26 05:59:52 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 D5A291A035C for ; Wed, 26 Feb 2014 05:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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_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 fyaOoGWm2jmL for ; Wed, 26 Feb 2014 05:59:36 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 608B91A034B for ; Wed, 26 Feb 2014 05:59:36 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id z11so637264lbi.22 for ; Wed, 26 Feb 2014 05:59:34 -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=VOUdtIzPMCc4AgR9liH6DRMHpt2+uqDftGOjAak9Bc4=; b=VcyDeHwiL65tYMS/1fc5sUENUNq7zw6ZJvN/T2oe5oxIWiu9NyPkTODV2kU8EC9zJb 3/e6yRqIRIQxCmLu0tjvpk7C1T0me+/um5Ud5I8crq2XZcR4AV7u4zbmmchIjDYPXnw4 ncyYMIresEbO5Hjd584GU0xgyx5OsekKXOeP2oOLjLlOs8sZSMTK8W5szh5tPYE4YTht koh3Wjzy3I3ylMecvgF8E9bsol51S6Gq9t+xKIf2rN3tj0a8mfQ9r7F8IqEuJXlkPpSc jfPqFOF/Bk1vEXM3gCbw7Fm9O+agVKEIqBnnzmNWR3JEA3l8iIOBVpPfOT1y/HFJB6TH v6yg== MIME-Version: 1.0 X-Received: by 10.152.27.193 with SMTP id v1mr2613105lag.4.1393423174436; Wed, 26 Feb 2014 05:59:34 -0800 (PST) Received: by 10.112.98.132 with HTTP; Wed, 26 Feb 2014 05:59:34 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BC3EF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1BC3EF@ESESSMB209.ericsson.se> Date: Wed, 26 Feb 2014 07:59:34 -0600 Message-ID: From: Richard Ejzak To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0158c486558b3b04f34f9d40 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/iVAU3N3l2ujbs6CcnV0nI8vHCxI Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: Allignment with draft-ietf-mmusic-sctp-sdp-06 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, 26 Feb 2014 13:59:39 -0000 --089e0158c486558b3b04f34f9d40 Content-Type: text/plain; charset=ISO-8859-1 Hi Christer, Thanks for this input. Clearly the example needs to be updated. If the group is certain that we don't want the flexibility to establish multiple SCTP associations on the same 5-tuple, then we should definitely make the change to simplify the dcmap and dcsa attributes. BR, RIchard On Wed, Feb 26, 2014 at 7:04 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > In the latest version (-06) of draft-ietf-mmusic-sctp-sdp it is no more > allowed (at least that is my reading when comparing the 05->06 diff) to > assign multiple SDP sctpmap attributes to a single m- line. > > > > I guess that doesn't affect the mechanism in > draft-ejzak-mmusic-data-channel-sdpneg as such (eventhough some text may > not be needed anymore). But, at least the example/note in section 4 should > be aligned. > > > > Example: > > > > m=application 54111 DTLS/SCTP 5000 5001 5002 > > c=IN IP4 79.97.215.79 > > a=sctpmap:5000 webrtc-datachannel > > a=sctpmap:5001 bfcp > > a=sctpmap:5002 t38 > > > > ...should be: > > > > m=application 54111 DTLS/SCTP 5000 > > c=IN IP4 79.97.215.79 > > a=sctpmap:5000 webrtc-datachannel > > > > (If you want to use multiple sctpmap attributes, I guess you would need to > assign one m- line for each). > > > > In addition, perhaps the SCTP port number is not needed in the extension > attributes (dcmap, dcsa) defined in the draft? > > > > Regards, > > > > Christer > > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e0158c486558b3b04f34f9d40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer,
Thanks for this input.  Clearly the = example needs to be updated.  If the group is certain that we don'= t want the flexibility to establish multiple SCTP associations on the same = 5-tuple, then we should definitely make the change to simplify the dcmap an= d dcsa attributes.

BR, RIchard

<= br>
On Wed, Feb 26, 2014 at 7:04 AM, Christer Hol= mberg <christer.holmberg@ericsson.com> wrote:

Hi,

 

In the latest version (-06) of draft-ietf-mmusic-sct= p-sdp it is no more allowed (at least that is my reading when comparing the= 05->06 diff) to assign multiple SDP sctpmap attributes to a single m- l= ine.

 

I guess that doesn’t affect the mechanism in d= raft-ejzak-mmusic-data-channel-sdpneg as such (eventhough some text may not= be needed anymore). But, at least the example/note in section 4 should be = aligned.

 

Example:

 

m=3Dapplication 54111 D= TLS/SCTP 5000 5001 5002

c=3DIN IP4 79.97.215.79=

         &nb= sp;      a=3Dsctpmap:5000 webrtc-datachannel

         &nb= sp;      a=3Dsctpmap:5001 bfcp

         &nb= sp;      a=3Dsctpmap:5002 t38

 

…should be:

 

m=3Dapplication 54111 D= TLS/SCTP 5000

c=3DIN IP4 79.97.215.79=

         &nb= sp;      a=3Dsctpmap:5000 webrtc-datachannel

 

(If you want to use multiple sctpmap attributes, I g= uess you would need to assign one m- line for each).

 

In addition, perhaps the SCTP port number is not nee= ded in the extension attributes (dcmap, dcsa) defined in the draft?<= u>

 

Regards,

 

Christer

 

         &nb= sp;     

 

 


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


--089e0158c486558b3b04f34f9d40-- From nobody Wed Feb 26 06:08: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 AB5CA1A03B7 for ; Wed, 26 Feb 2014 06:08:00 -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 LTid-DNr8xkF for ; Wed, 26 Feb 2014 06:07:58 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE611A034B for ; Wed, 26 Feb 2014 06:07:57 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id c6so652403lan.38 for ; Wed, 26 Feb 2014 06:07:56 -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=mMHXSRr2wh3f4mwWyVVtxveq1b8PJVOBNymeYUpDNN8=; b=WDhkuScIH40OPLbSVXvN2WUp4mQdB6M1eo7TRw9lKrGYzXNnGgcI/CTCwhIHkMebWR LqlqWBC6UbCbPHsRu4tPQ9BY2s6S9kO+9rKMTcO4o+XaSugHsBD1bmwES14yna6kMOq5 8oYR1B7EaROZHSyL535S4tuZtQBhRoQcjaoXoVLgntXY+3CY6BEHZa5chkCeGNy97Yum e//+pwRDxNEzBqlDZrjGYnxH0G8C6z9i8gKFvbBHbWkQdhEq02vlcmp8v603j56AlRsU 2Rn7i9HIFFmjJK925/CcTFG+2Kr8cwY80oG3duQdgl64CWj+l9UA7MoDCNjbdii1X6CY Xrpg== MIME-Version: 1.0 X-Received: by 10.112.169.10 with SMTP id aa10mr169375lbc.72.1393423676207; Wed, 26 Feb 2014 06:07:56 -0800 (PST) Received: by 10.112.98.132 with HTTP; Wed, 26 Feb 2014 06:07:56 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BC4D7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1BC4D7@ESESSMB209.ericsson.se> Date: Wed, 26 Feb 2014 08:07:56 -0600 Message-ID: From: Richard Ejzak To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c385e03df6ff04f34fbbba Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kSC0hhUvXf6biboBoCRuE7LMKu0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel 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, 26 Feb 2014 14:08:00 -0000 --001a11c385e03df6ff04f34fbbba Content-Type: text/plain; charset=ISO-8859-1 Hi Christer, Another good catch. Although it is implied that closed data channels are removed from subsequent offers, this should be stated explicitly. BR, RIchard On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Section 5.2.3 says: > > > > "It is specific to the sub-protocol whether this closing must in > > addition be signaled to the peer via a new SDP > offer/answer exchange." > > > > Shouldn't the draft define how it is done using an SDP offer/answer > exchange? > > > > Regards, > > > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a11c385e03df6ff04f34fbbba Content-Type: text/html; charset=ISO-8859-1
Hi Christer,
Another good catch.  Although it is implied that closed data channels are removed from subsequent offers, this should be stated explicitly.

BR, RIchard


On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

 

Section 5.2.3 says:

 

”It is specific to the sub-protocol whether this closing must in

                addition be signaled to the peer via a new SDP offer/answer exchange.”

 

Shouldn’t the draft define how it is done using an SDP offer/answer exchange?

 

Regards,

 

Christer


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


--001a11c385e03df6ff04f34fbbba-- From nobody Wed Feb 26 06:13: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 9D5E91A009E for ; Wed, 26 Feb 2014 06:13:47 -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 fen2AEvMTcVt for ; Wed, 26 Feb 2014 06:13:43 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 04A721A03F9 for ; Wed, 26 Feb 2014 06:13:42 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id gl10so673342lab.28 for ; Wed, 26 Feb 2014 06:13:41 -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=0baobaDrJzWiMFLPenz5fen8sOpnqUNtpwQ1yALFfJM=; b=1D0B0YHerw1u6rvZltRVjb0N3/J415WIyJ4mUQr5cQXyG1hH5ALkuFy4nUQDVaZoYk pdcgsYeaad67Bvmeb4Nrw7lPyr5VvYVOlc/t2qNQtHMDJ3LIyleePFCzqzO3xRR3YjYe t4dshXRCHYB+wa8SVatBVi+DBEjxCePPBwR1NUT9MQhGgGGjd769rod9Fd3VNVxXMQq2 j94e8d+O7G3qicaMABpEORi5jQxmBWJT51+CLqc7zdlQX/znHCtfeCeDcfaIzOR9Zi8O cwdlb3E2rsjLKg85tdEWUZyzw+H4zZUg2vowjCaRqUq5UoI3Cys/alnkNfsd4PL4GEZq MTFQ== MIME-Version: 1.0 X-Received: by 10.152.27.193 with SMTP id v1mr2655641lag.4.1393424021112; Wed, 26 Feb 2014 06:13:41 -0800 (PST) Received: by 10.112.98.132 with HTTP; Wed, 26 Feb 2014 06:13:41 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> Date: Wed, 26 Feb 2014 08:13:41 -0600 Message-ID: From: Richard Ejzak To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0158c486cccc1804f34fcf23 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VFXHdqBe6kWwqHkFz7lpJIKuUAI Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 26 Feb 2014 14:13:47 -0000 --089e0158c486cccc1804f34fcf23 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 26, 2014 at 7:30 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Section 5.2.2 describes what an answerer does when accepting a data > channel: > > > > "The peer receiving such an SDP offer performs the following: > > > > ... > > > > o For accepted data channels, creates peer instances for the data > > channels with the browser using the channel parameters described > > in the SDP offer. Note that the browser is asked to create data > > channels with stream identifiers not "owned" by the agent." > > > > But, there is no text on rejecting a data channel in the SDP answer. > > > > The answer can of course reject the whole m- line, using port zero in the > Answer m- line. But, how does the answerer reject an individual > sub-protocol data channel? > Only attributes for "accepted data channels" are included in the SDP answer, which indicates back to the offerer which ones are rejected (they just aren't there). This should be made clearer in the text. > > > Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted data > channels: > > > > "This line MUST be replicated without changes in the SDP answer, if > > the answerer accepts the offered data channel." > > > > I guess one way to reject would be to simply not include the dcmap > attribute in the Answer, and the Offerer then needs to figure out what was > rejected based on the stream values not present in the Answer. > Yes. That is what was intended. BR, RIchard > > > Regards, > > > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e0158c486cccc1804f34fcf23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 26, 2014 at 7:30 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:

Hi,

 

Section 5.2.2 describes what an answerer does when a= ccepting a data channel:

 

  “The peer receiving such an SDP offer p= erforms the following:

 

        &nbs= p;       …

 

   o  For accepted data channels, cre= ates peer instances for the data

      channels with the bro= wser using the channel parameters described

      in the SDP offer.&nbs= p; Note that the browser is asked to create data

      channels with stream = identifiers not "owned" by the agent.”

 

But, there is no text on rejecting a data channel in= the SDP answer.

 

The answer can of course reject the whole m- line, u= sing port zero in the Answer m- line. But, how does the answerer reject an = individual sub-protocol data channel?


Only attributes for "accepted data channels" are inclu= ded in the SDP answer, which indicates back to the offerer which ones are r= ejected (they just aren't there).  This should be made clearer in = the text.
 

 

Section 5.1.1 says, regarding the SDP dcmap attribut= e, for accepted data channels:

 

“This line MUST b= e replicated without changes in the SDP answer, if

         &nb= sp;      the answerer accepts the offered data cha= nnel.”

 

I guess one way to reject would be to simply not inc= lude the dcmap attribute in the Answer, and the Offerer then needs to figur= e out what was rejected based on the stream values not present in the Answe= r.


Yes.  That is what was in= tended.

BR, RIchard
 

 

Regards,

 

Christer

 


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


--089e0158c486cccc1804f34fcf23-- From nobody Wed Feb 26 06:23: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 4B39E1A040C for ; Wed, 26 Feb 2014 06:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=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 SLQxLHw6I8HD for ; Wed, 26 Feb 2014 06:23:25 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AA7EF1A03EF for ; Wed, 26 Feb 2014 06:23:15 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-c3-530df8d1cf0a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B7.08.23809.1D8FD035; Wed, 26 Feb 2014 15:23:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 15:23:11 +0100 From: Christer Holmberg To: Richard Ejzak Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: Allignment with draft-ietf-mmusic-sctp-sdp-06 Thread-Index: Ac8y7cAS6dY38hPvTOKDNescE/oruQABNh8AAALFYjA= Date: Wed, 26 Feb 2014 14:23:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BC692@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1BC3EF@ESESSMB209.ericsson.se> 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.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvje7FH7zBBm/PWltMXf6YxeJZbwOr A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXR8fA2c8Ervoq78wsaGPt4uhg5OSQETCR+ Lr7MAmGLSVy4t56ti5GLQ0jgEKPEgel/GCGcJYwSjbveAVVxcLAJWEh0/9MGaRAR0JbY9vIB WJhZQF3i6uIgkLCwQK7E7Z+v2CFK8iQ2bTrACGFbSaycs4wNxGYRUJWY3X0arIZXwFdi3Z8v 7BCrpjBKHLyygwkkwSkQKLG3expYAyPQcd9PrQGLMwuIS9x6Mp8J4mgBiSV7zjND2KISLx// Y4WwFSU+vtrHCFGvJ3Fj6hQ2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaW VYzsuYmZOenlRpsYgRFycMtv1R2Md86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVANjldqq3z6rJoebOvEuvW6y4LlCmcchwTXavDr7fS/dSYy0fHBgyYofej9z7lSk dZVfsy/03MKcve8r8517ygWnuwvu2szYf8Vnqu7ZGz++rDt8svDXsnbx9ja1rV/qjtc9YtWY 1b+0Vzww6Im2x4Y9K5dp9O6ZWbbllfCXRg2m08se51jouuvrK7EUZyQaajEXFScCABSk8Yxe AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PIpWZDLUqfoZg1CFd0SPOYqEaSg Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: Allignment with draft-ietf-mmusic-sctp-sdp-06 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, 26 Feb 2014 14:23:30 -0000 Hi, > Thanks for this input. =A0Clearly the example needs to be updated. =A0If = the group is certain that we don't want the flexibility > to establish multiple SCTP associations on the same 5-tuple It MAY (we need to look into that) still be possible to do that with BUNDLE= , but you would use separate m- lines for each SCTP association. Regards, Christer On Wed, Feb 26, 2014 at 7:04 AM, Christer Holmberg wrote: Hi, =A0 In the latest version (-06) of draft-ietf-mmusic-sctp-sdp it is no more all= owed (at least that is my reading when comparing the 05->06 diff) to assign= multiple SDP sctpmap attributes to a single m- line. =A0 I guess that doesn't affect the mechanism in draft-ejzak-mmusic-data-channe= l-sdpneg as such (eventhough some text may not be needed anymore). But, at = least the example/note in section 4 should be aligned.=20 =A0 Example: =A0 m=3Dapplication 54111 DTLS/SCTP 5000 5001 5002 c=3DIN IP4 79.97.215.79 =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a=3Dsctpmap:5000 webrtc-datacha= nnel =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a=3Dsctpmap:5001 bfcp =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a=3Dsctpmap:5002 t38 =A0 .should be: =A0 m=3Dapplication 54111 DTLS/SCTP 5000 c=3DIN IP4 79.97.215.79 =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a=3Dsctpmap:5000 webrtc-datacha= nnel =A0 (If you want to use multiple sctpmap attributes, I guess you would need to = assign one m- line for each). =A0 In addition, perhaps the SCTP port number is not needed in the extension at= tributes (dcmap, dcsa) defined in the draft? =A0 Regards, =A0 Christer =A0 =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 =A0 =A0 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Feb 26 07:13: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 DDD591A066F for ; Wed, 26 Feb 2014 07:13:10 -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 s_g3CToWqQPB for ; Wed, 26 Feb 2014 07:13:06 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D07571A0670 for ; Wed, 26 Feb 2014 07:13:05 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-bb-530e047f3852 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 94.31.23809.F740E035; Wed, 26 Feb 2014 16:13:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 16:13:03 +0100 From: Christer Holmberg To: Richard Ejzak Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel Thread-Index: Ac8y9K3pwn95tj5YT7SqspOdgSm1jf///isA///d/LA= Date: Wed, 26 Feb 2014 15:13:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BC7FC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1BC4D7@ESESSMB209.ericsson.se> 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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1BC7FCESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjW4DC1+wwbHP7BZTlz9msXjW28Dq wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGW8frSAueCXW8W9H59ZGhif2HcxcnBICJhI PL2n2MXICWSKSVy4t54NxBYSOMQosWmtYRcjF5C9hFHi8OSPLCD1bAIWEt3/tEFqRAS0Jba9 fAAWZhZQl7i6OAgkLCwQLTHtwVdmiJIYiSVvepggbCuJKw9fsoPYLAKqEvO697KC2LwCvhK7 f11lhFg1hVFi+6l3YAlOgUCJ5oYWsGZGoNu+n1oDZjMLiEvcejKfCeJmAYkle84zQ9iiEi8f /2OFsBUlPr7axwhRny9xa8lBNohlghInZz5hmcAoOgvJqFlIymYhKYOI60gs2P2JDcLWlli2 8DUzjH3mwGMmZPEFjOyrGNlzEzNz0suNNjEC4+nglt+qOxjvnBM5xCjNwaIkzvvhrXOQkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbXuoyZdsc/NM2fGbLq8cRn/ssOCySsvLiO9dQ9j9/O llsaEgMFnz0TyrTP/n5QymDu36D2w339K37eEltS9qFl8w/Doravot9cOo8msvdrhvms/822 4/HT8oL8MueTp/ymqiyr7msPsLiUeXZKjmk1z56Vyl5Fi7+fnfliborFh23z9edY7k5XYinO SDTUYi4qTgQADf5K43UCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uRdxSomU7ETj8rgPb-yZllxRyQk Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel 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, 26 Feb 2014 15:13:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1BC7FCESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There are no channels in the offers - there are SDP attributes associated w= ith the channels :) You also need to be more clear on whether sending of SSN reset is mandatory= when using your draft (you only say that "browsers will send it"). Regards, Christer From: Richard Ejzak [mailto:richard.ejzak@gmail.com] Sent: 26. helmikuuta 2014 16:08 To: Christer Holmberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external clos= ing of channel Hi Christer, Another good catch. Although it is implied that closed data channels are r= emoved from subsequent offers, this should be stated explicitly. BR, RIchard On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg > wrote: Hi, Section 5.2.3 says: "It is specific to the sub-protocol whether this closing must in addition be signaled to the peer via a new SDP offer/answer= exchange." Shouldn't the draft define how it is done using an SDP offer/answer exchang= e? Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1D1BC7FCESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

There are no channels in = the offers – there are SDP attributes associated with the channels J

 <= /p>

You also need to be more = clear on whether sending of SSN reset is mandatory when using your draft (y= ou only say that “browsers will send it”).

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Richard = Ejzak [mailto:richard.ejzak@gmail.com]
Sent: 26. helmikuuta 2014 16:08
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: extern= al closing of channel

 

Hi Christer,

Another good catch.  Although it is implied tha= t closed data channels are removed from subsequent offers, this should be s= tated explicitly.

 

BR, RIchard

 

On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

Section 5.2.3 says:

 

”It is specific to the sub-protocol whether this closing must in=

            = ;    addition be signaled to the peer via a new SDP offer/an= swer exchange.”

 

Shouldn’t the draft define how it is done using an SDP offer= /answer exchange?

 

Regards,

 

Christer


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

 

--_000_7594FB04B1934943A5C02806D1A2204B1D1BC7FCESESSMB209erics_-- From nobody Wed Feb 26 07:42: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 906251A028A for ; Wed, 26 Feb 2014 07:42:49 -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 7aQ_sHrUFwQG for ; Wed, 26 Feb 2014 07:42:46 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id B0C221A0677 for ; Wed, 26 Feb 2014 07:42:43 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id q8so770008lbi.28 for ; Wed, 26 Feb 2014 07:42:41 -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=EupREC2Kst7TUy3qwyUA25vZVvEk+nUN7sIzsq0qGac=; b=kSsSwlRphflXtjYt7IvYcVwIMXaMB4bKXE3nrstPeBpUotkiRnpqviMfvcaMpaww6m U7wZGaEeR+LXdyU3JIqzX/RPZpfl7yCHvhKP4Lv5f0mbcYl2XUiTdegslGvtuT0ZDnuW WrfAtfnaQbG4MXiLAdWXS2nb9xIQ2wttmhoKy+37jjbZV+0cRv7Zp5MCIGp6vvsaIOCa Kxdv5gqI1xOgvzzHJgowTV1UlNvaTp2bdihT2Rbo4BJJicX7/x2dsp77muJ4aYdu5f8d yVloeb1CbjjhPmCy5+HYyvUB64uSlPWHaqiwDWOwNomOiMsq1jE14aERiVfZMqZfk6/4 9nmA== MIME-Version: 1.0 X-Received: by 10.112.180.72 with SMTP id dm8mr2723973lbc.28.1393429361738; Wed, 26 Feb 2014 07:42:41 -0800 (PST) Received: by 10.112.98.132 with HTTP; Wed, 26 Feb 2014 07:42:41 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BC7FC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1BC4D7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1BC7FC@ESESSMB209.ericsson.se> Date: Wed, 26 Feb 2014 09:42:41 -0600 Message-ID: From: Richard Ejzak To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e011836be2049f604f3510e47 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/gFbmzGenlggjMicaNOsndW9Fess Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel 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, 26 Feb 2014 15:42:49 -0000 --089e011836be2049f604f3510e47 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 26, 2014 at 9:13 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > There are no channels in the offers - there are SDP attributes associated > with the channels J > Fair enough. > > > You also need to be more clear on whether sending of SSN reset is > mandatory when using your draft (you only say that "browsers will send it"). > The text should refer to protocol stack behavior rather than to the browser since it's supposed to also apply to data channel usage outside the context of WebRTC. (We intended to fix all th browser references in this draft and missed this one.) So, yes, SSN reset is mandatory. Thanks again, Richard > > Regards, > > > > Christer > > > > *From:* Richard Ejzak [mailto:richard.ejzak@gmail.com] > *Sent:* 26. helmikuuta 2014 16:08 > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external > closing of channel > > > > Hi Christer, > > Another good catch. Although it is implied that closed data channels are > removed from subsequent offers, this should be stated explicitly. > > > > BR, RIchard > > > > On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > Section 5.2.3 says: > > > > "It is specific to the sub-protocol whether this closing must in > > addition be signaled to the peer via a new SDP > offer/answer exchange." > > > > Shouldn't the draft define how it is done using an SDP offer/answer > exchange? > > > > Regards, > > > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --089e011836be2049f604f3510e47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 26, 2014 at 9:13 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:

Hi,<= /p>

 

There are no channels in = the offers – there are SDP attributes associated with the channels J


Fair enough.
 

 

You also need to be more = clear on whether sending of SSN reset is mandatory when using your draft (y= ou only say that “browsers will send it”).


The text should refer to proto= col stack behavior rather than to the browser since it's supposed to al= so apply to data channel usage outside the context of WebRTC.  (We int= ended to fix all th browser references in this draft and missed this one.) =  So, yes, SSN reset is mandatory.    

Thanks again,
Richard

 

Regards,

 

Christer

 

From: Richard = Ejzak [mailto:= richard.ejzak@gmail.com]
Sent: 26. helmikuuta 2014 16:08
To: Christer Holmberg
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: extern= al closing of channel

 

Hi Christer,

Another good catch.  Although it is implied tha= t closed data channels are removed from subsequent offers, this should be s= tated explicitly.

 

BR, RIchard

 <= /p>

On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

Section 5.2.3 says:<= u>

 

”It is specific to the sub-protocol whether this closing must in

         &nb= sp;      addition be signaled to the peer via a ne= w SDP offer/answer exchange.”

 

Shouldn’t the draft define how it is done usin= g an SDP offer/answer exchange?

 

Regards,

 

Christer=


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

 


--089e011836be2049f604f3510e47-- From nobody Wed Feb 26 10:59:54 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 0A1991A00F2 for ; Wed, 26 Feb 2014 10:59:48 -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=unavailable 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 cjZsrWWTXNfM for ; Wed, 26 Feb 2014 10:59:46 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 014FB1A07FE for ; Wed, 26 Feb 2014 10:59:29 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1QIxQ3d029055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 12:59:27 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s1QIxQkS014134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 13:59:26 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 13:59:26 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//sW+yX/9iL+AP/roUyA/9ZDm9A= Date: Wed, 26 Feb 2014 18:59:26 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> <530D189F.8020804@alum.mit.edu> In-Reply-To: <530D189F.8020804@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RmjNhiTcNM9-bB5BOGsrGLZ6ttU Subject: Re: [MMUSIC] [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-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: Wed, 26 Feb 2014 18:59:48 -0000 + mmusic - rtcweb (in bcc) Hi Paul, I wanted to close this email loop. Please see my inline comments. > > > > [Raju] If I understand correctly, these parameters simply define the > > data channel transport properties. Yes, they may have some correletion > with > > subprotocol, but that's not a one-to-one mapping. > > For example, a given subprotocol could run on a reliable or > > unreliable transport; depending on app needs it may use unreliable > > transport and deal with reliablity at subprotocol stack (or ignore it). >=20 > In some cases. But in general it is easy and common to define a protocol > that needs a reliable transport, and it won't work without one. >=20 > What if every application in the world that uses TCP had the option to > specify if it was reliable or not? How many would screw it up? >=20 [Raju]=20 Application subprotocol users need to know the transport needs for the prot= ocol and select a single transport if multiple options exist. This is simil= ar to how users select TCP or UDP when implementing any Layer5 protocol (e.= g. SIP) on top of Layer 4. If APIs abstract this subprotocol then the transport selection can be hidde= n under the API (if only one choice exists) and API user won't have to spec= ify a transport.=20 We really appreciate your time in providing valuable comments on these draf= ts! Best Regards! Raju From nobody Wed Feb 26 11:54:14 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 A39AB1A0118 for ; Wed, 26 Feb 2014 11:54:06 -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 kORUwO_h0POr for ; Wed, 26 Feb 2014 11:54:02 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EA9441A0722 for ; Wed, 26 Feb 2014 11:53:58 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-9f-530e4654ac23 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8B.8A.04249.4564E035; Wed, 26 Feb 2014 20:53:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 20:53:56 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Paul Kyzivat" , "mmusic@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//ubSND/9sNUAP/tdnOA/9qg+ID/s+mAAP9ntHLA Date: Wed, 26 Feb 2014 19:53:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BCCB6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> <530D189F.8020804@alum.mit.edu> 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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvjW6oG1+wwQIDi6nLH7NYrNhwgNWi YeMVVgdmj9Zne1k9/r7/wOSxZMlPpgDmKC6blNSczLLUIn27BK6MX9+OsxS85KmYsWkWawPj Qq4uRk4OCQETiakfr7BC2GISF+6tZ+ti5OIQEjjCKPHp1FJGCGcJo8T3BQeAqjg42AQsJLr/ aYPERQSmMEpsXXCFEaRbWCBWov3xDiYQW0QgTuLRg23sEEVNjBL/LzwAS7AIqEr0Hp7DDmLz CvhKtGz9yQSx4TebxIwDi8AmcQJN+rfjLZjNCHTT91NrwJqZBcQlbj2ZzwRxq4DEkj3nmSFs UYmXj/9B/aAksej2Z6h6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjKKzkIydhaRlFpKWWUha FjCyrGLkKE4tTspNNzLYxAiMkoNbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGHM2KWs4KCinrizW+lvJeXhCVl7G4ue5NkZzLRdxn+UJVJl8/xDXhGPH govVOdMCjkxrW+0nEWVjulBpyarzN8pcXRZf+n0p+UVBrazokl0i+pEBzy4Y9S/8cFeWv3TG xK+mKx5PK2P890nnruzj/z+aXxQWbjgTtma28Out/RP7tBOKWx627FFiKc5INNRiLipOBABC wAQkYAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QRjVG4cOK3O1IIb54N_IXidB_IQ Subject: Re: [MMUSIC] [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-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: Wed, 26 Feb 2014 19:54:07 -0000 Hi, >I wanted to close this email loop. Please see my inline comments. I am ok closing it for now - but I still have a different opinion :) >> [Raju] If I understand correctly, these parameters simply define the=20 >> data channel transport properties. Yes, they may have some=20 >> correletion with >> subprotocol, but that's not a one-to-one mapping. >> For example, a given subprotocol could run on a reliable or=20 >> unreliable transport; depending on app needs it may use unreliable=20 >> transport and deal with reliablity at subprotocol stack (or ignore it). >>=20 >> In some cases. But in general it is easy and common to define a=20 >> protocol that needs a reliable transport, and it won't work without one. >>=20 >> What if every application in the world that uses TCP had the option to=20 >> specify if it was reliable or not? How many would screw it up? >>=20 >[Raju] >Application subprotocol users need to know the transport needs for the pro= tocol and select a single >transport if multiple options exist. This is sim= ilar to how users select TCP or UDP when >implementing any Layer5 protocol = (e.g. SIP) on top of Layer 4. RFC 3261, i.e. the "sub-protocol specification", defines the characteristic= s when using TCP or UDP for SIP. There is no mechanism in UDP or TCP to neg= otiate SIP timers. I DO buy the argument that, when using DCP, there may not be a registered s= ub-protocol to begin with, so this type of low-level information needs to b= e negotiated. BUT, when using draft-ejzak my assumption is that people will indicate the = sup-protocol. Regards, Christer From nobody Wed Feb 26 12:01:28 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 9B1341A08A5 for ; Wed, 26 Feb 2014 12:01:24 -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 KXprbCuSLEcS for ; Wed, 26 Feb 2014 12:01:19 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 45A871A088F for ; Wed, 26 Feb 2014 12:00:26 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-e8-530e47d8bcec Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9C.85.10875.8D74E035; Wed, 26 Feb 2014 21:00:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 21:00:23 +0100 From: Christer Holmberg To: Richard Ejzak Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel Thread-Index: Ac8y9K3pwn95tj5YT7SqspOdgSm1jf///isA///d/LCAADx9gP//qDPA Date: Wed, 26 Feb 2014 20:00:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BCD0C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1BC4D7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1BC7FC@ESESSMB209.ericsson.se> 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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1BCD0CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje4Nd75gg8N3BC2mLn/MYvGst4HV gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MrY/fQvW8H/jIrNG16zNDAui+ti5OSQEDCR OPBuHguELSZx4d56ti5GLg4hgUOMEtMWTWCEcJYwSsyaMA8ow8HBJmAh0f1PG6RBREBbYtvL BywgYWYBdYmri4NAwsIC0RLTHnxlhiiJkVjypocJpEREwE3i/ndLkDCLgKrE6rtTwAbyCvhK LPvqBrFoPpPExi172UBqOAUCJaZNf8IOYjMCnfb91BomEJtZQFzi1pP5TBAnC0gs2XOeGcIW lXj5+B8rhK0ksej2Z6j6fIn23otgNq+AoMTJmU9YJjCKzkIyahaSsllIyiDiOhILdn9ig7C1 JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HLDTYzAeDq45bfuDsZT50QOMUpzsCiJ83546xwk JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdGVOSxPa4rbs5NcBiGCdX8n+KzZ422iEmWpHBEv FTFF4NrCJvkrV1/5/jjh2Lew4ehltVXP7sn3qSxflCT/YNmPm7MNFdjfZWw4EBdxvO+f7t4L 641PlZ8O3nXeOL7T40zSHMUQBdU/HtqbFR1/GcpeUDkh5DuB+6504+k7DJ9bJ70w1TXi2KvE UpyRaKjFXFScCACajaiedQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7betq4v58o7GbKDzHYzti6rq2SY Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel 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, 26 Feb 2014 20:01:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1BCD0CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, You also need to be more clear on whether sending of SSN reset is mandator= y when using your draft (you only say that "browsers will send it"). The text should refer to protocol stack behavior rather than to the browser= since it's supposed to also apply to data channel usage outside the contex= t of WebRTC. (We intended to fix all th browser references in this draft a= nd missed this one.) So, yes, SSN reset is mandatory. Then you also need to cover that in the procedures. For example, when an entity receives an Offer removing a channel, it MUST s= end a SSN reset. Also, what to do if an entity receives an SSN reset, but not an associated = Offer. These kind of error situations often cause troubles at interop testings, so= let's try to cover them from the beginning :) Regards, Christer From: Richard Ejzak [mailto:richard.ejzak@gmail.com] Sent: 26. helmikuuta 2014 16:08 To: Christer Holmberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external clos= ing of channel Hi Christer, Another good catch. Although it is implied that closed data channels are r= emoved from subsequent offers, this should be stated explicitly. BR, RIchard On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg > wrote: Hi, Section 5.2.3 says: "It is specific to the sub-protocol whether this closing must in addition be signaled to the peer via a new SDP offer/answer= exchange." Shouldn't the draft define how it is done using an SDP offer/answer exchang= e? Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1D1BCD0CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 You also need to b= e more clear on whether sending of SSN reset is mandatory when using your draft (you only say that “browsers will send it”).=

 

The text should refer to protocol stack behavior rat= her than to the browser since it's supposed to also apply to data channel u= sage outside the context of WebRTC.  (We intended to fix all th browse= r references in this draft and missed this one.)  So, yes, SSN reset is mandatory.    

 

Then you also need to cov= er that in the procedures.

 <= /p>

For example, when an enti= ty receives an Offer removing a channel, it MUST send a SSN reset.

 <= /p>

Also, what to do if an en= tity receives an SSN reset, but not an associated Offer.<= /p>

 <= /p>

These kind of error situa= tions often cause troubles at interop testings, so let’s try to cover= them from the beginning J

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 

From: Richard Ejzak [mailto:richard.ejzak@gmail.com]
Sent: 26. helmikuuta 2014 16:08
To: Christer Holmberg
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: extern= al closing of channel

 

Hi Christer,

Another good catch.  Although it is impl= ied that closed data channels are removed from subsequent offers, this shou= ld be stated explicitly.

 

BR, RIchard

 

On Wed, Feb 26, 2014 at 7:19 AM, Christer Hol= mberg <christer.holmberg@ericsson.com> wrote:

Hi,

 

Section 5.2.3 says:<= o:p>

 

”It is specific to the sub-protocol whether this= closing must in

        &n= bsp;       addition be signaled to the peer v= ia a new SDP offer/answer exchange.”

 

Shouldn’t the draft define how it is do= ne using an SDP offer/answer exchange?

 

Regards,

 

Christer


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

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D1BCD0CESESSMB209erics_-- From nobody Wed Feb 26 12:12: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 479CA1A01DF for ; Wed, 26 Feb 2014 12:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 QjCd0sy70tHu for ; Wed, 26 Feb 2014 12:12:42 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2B90A1A0186 for ; Wed, 26 Feb 2014 12:12:42 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1QKCbC9012458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 14:12:38 -0600 (CST) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s1QKCVIR019368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 15:12:36 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 15:12:35 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Richard Ejzak , Christer Holmberg Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: AQHPMv00Ot+PDux+H0inH2oRraNWlJrH7JxQ Date: Wed, 26 Feb 2014 20:12:35 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFFB545US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YPeXFqh4swrjuVJ8vDfmpXHJZhE Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 26 Feb 2014 20:12:49 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826DFFB545US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find my comments inline. But, there is no text on rejecting a data channel in the SDP answer. The answer can of course reject the whole m- line, using port zero in the A= nswer m- line. But, how does the answerer reject an individual sub-protocol= data channel? Only attributes for "accepted data channels" are included in the SDP answer= , which indicates back to the offerer which ones are rejected (they just ar= en't there). This should be made clearer in the text. Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted data ch= annels: "This line MUST be replicated without changes in the SDP answer, if the answerer accepts the offered data channel." I guess one way to reject would be to simply not include the dcmap attribut= e in the Answer, and the Offerer then needs to figure out what was rejected= based on the stream values not present in the Answer. Yes. That is what was intended. [Raju] In addition to the above mentiooed cases, if we all agree we need to= add the following cases in the next draft: 1. SDP offer has no a=3Ddcmap. This has two use cases: a. Initial SDP offer: no data channel streams (DCS) are open yet. b. Subsequent SDP offer: Remove all previously opened data channels/st= reams. In either case, the SCTP association is kept open (and ICE procedures are p= erformed) even when no data channels are in use. 2. Creation of new DCS(s) using SDP offer (initial or subsequent) a. Offerer has to create the data channels locally first by doing cre= ateDataChannel or equivalent API into data channel stack before sending off= er. 3. SDP offer was rejected a. DCSs are kept per previous SDP offer/answer. This means DCSs that = are to be deleted has to be deleted (i.e. calling createDataChannel or equi= valent API) only after successful SDP answer. b. If any new DCSs are attempted to be created per new SDP offer, thes= e have to be closed now. 4. Per http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconne= ction-createdatachannel createDataChannel() API the 'external' negotiation = field is per data channel. But this draft only allows external negotiation= to be used for all or no streams; it can't be selective. This restriction = is also needed so that the SDP offer/answer odd/even stream id allocation w= on't conflict DCP's TLS role based odd/even mechanism. Best Regards! Raju --_000_E1FE4C082A89A246A11D7F32A95A17826DFFB545US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Please find my comments inline.=

But, there is no text on rejecting a data channel in the SDP answe= r.

 

The answer can of course reject the whole m- line, using port zero= in the Answer m- line. But, how does the answerer reject an individual sub= -protocol data channel?

 

Only attributes for "accepted data channels&quo= t; are included in the SDP answer, which indicates back to the offerer whic= h ones are rejected (they just aren't there).  This should be made cle= arer in the text.

 

 

Section 5.1.1 says, regarding the SDP dcmap attribute, for accepte= d data channels:

 

“This line MUST be replicated without changes in the SDP answer, if

            = ;    the answerer accepts the offered data channel.”

 

I guess one way to reject would be to simply not include the dcmap= attribute in the Answer, and the Offerer then needs to figure out what was= rejected based on the stream values not present in the Answer.

 

Yes.  That is what was intended.

[Raju] In addition to = the above mentiooed cases, if we all agree we need to add the following cas= es in the next draft:

1.       SDP offer= has no a=3Ddcmap. This has two use cases:

a.  &= nbsp;    Initial SDP offer= : no data channel streams (DCS) are open yet.

b.  &= nbsp;   Subsequent SDP of= fer: Remove all previously opened data channels/streams.<= /p>

2.       Creation = of new DCS(s) using SDP offer (initial or subsequent)

a.  &= nbsp;    Offerer has to cr= eate the data channels locally first by doing createDataChannel or equivale= nt API into data channel stack before sending offer.

3.       SDP offer= was rejected

a.  &= nbsp;    DCSs are kept per= previous SDP offer/answer. This means DCSs that are to be deleted has to b= e deleted (i.e. calling createDataChannel or equivalent API) only after successful SDP answer.

b.  &= nbsp;   If any new DCSs a= re attempted to be created per new SDP offer, these have to be closed now.<= o:p>

4. &= nbsp;     Per http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-created= atachannel createDataChannel() API the ‘external’ negotiati= on field is per data channel.  But this draft only allows external neg= otiation to be used for all or no streams; it can’t be selective. This restriction is also needed so that the SDP offer/answer= odd/even stream id allocation won’t conflict DCP’s TLS role ba= sed odd/even mechanism.

 <= /p>

Best Regards!<= /span>

Raju

--_000_E1FE4C082A89A246A11D7F32A95A17826DFFB545US70UWXCHMBA02z_-- From nobody Wed Feb 26 12:19: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 C3F061A08A8 for ; Wed, 26 Feb 2014 12:18:58 -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 CqSBH83FaQHj for ; Wed, 26 Feb 2014 12:18:56 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAA71A08A7 for ; Wed, 26 Feb 2014 12:18:56 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1QKImQY019044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 14:18:50 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s1QKIlWj031475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 15:18:48 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 15:18:47 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//sW+yX/9iL+AP/roUyA/9ZDm9D/rB6LgP9Yiy1Q Date: Wed, 26 Feb 2014 20:18:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu> <530D189F.8020804@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1BCCB6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BCCB6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/JDuzRxl2xefuJslAy2prc7_kVVA Subject: Re: [MMUSIC] [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-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: Wed, 26 Feb 2014 20:18:59 -0000 Hi, Please see my comments inline. > Hi, >=20 > >I wanted to close this email loop. Please see my inline comments. >=20 > I am ok closing it for now - but I still have a different opinion :) [Raju] There won't be much fun if we all agree on everything. Isn't it?! :-= ) >=20 > >> [Raju] If I understand correctly, these parameters simply define the > >> data channel transport properties. Yes, they may have some > >> correletion with > >> subprotocol, but that's not a one-to-one mapping. > >> For example, a given subprotocol could run on a reliable or > >> unreliable transport; depending on app needs it may use unreliable > >> transport and deal with reliablity at subprotocol stack (or ignore it)= . > >> > >> In some cases. But in general it is easy and common to define a > >> protocol that needs a reliable transport, and it won't work without on= e. > >> > >> What if every application in the world that uses TCP had the option to > >> specify if it was reliable or not? How many would screw it up? > >> > >[Raju] > >Application subprotocol users need to know the transport needs for the > protocol and select a single >transport if multiple options exist. This i= s > similar to how users select TCP or UDP when >implementing any Layer5 > protocol (e.g. SIP) on top of Layer 4. >=20 > RFC 3261, i.e. the "sub-protocol specification", defines the characterist= ics > when using TCP or UDP for SIP. There is no mechanism in UDP or TCP to > negotiate SIP timers. [Raju] What you said is correct! However, int his case DCP does negotiate t= hese timers inband. The external negotiation is simply providing similar me= chanism so that both peers have same data channel properties (similar to DC= P). Thanks Raju >=20 > I DO buy the argument that, when using DCP, there may not be a registered > sub-protocol to begin with, so this type of low-level information needs t= o > be negotiated. >=20 > BUT, when using draft-ejzak my assumption is that people will indicate th= e > sup-protocol. From nobody Wed Feb 26 12:27:47 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 E61FF1A0111 for ; Wed, 26 Feb 2014 12:27:35 -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_14=0.6, J_CHICKENPOX_15=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 Jas9J045omqj for ; Wed, 26 Feb 2014 12:27:34 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 499AD1A00D7 for ; Wed, 26 Feb 2014 12:27:34 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta06.westchester.pa.mail.comcast.net with comcast id X1S31n00717dt5G568TY7X; Wed, 26 Feb 2014 20:27:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id X8TY1n00K3ZTu2S3Z8TY0a; Wed, 26 Feb 2014 20:27:32 +0000 Message-ID: <530E4E34.4010707@alum.mit.edu> Date: Wed, 26 Feb 2014 15:27:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393446452; bh=cIdfsWAHBtbkWbaB1bpnqLA6vlz0jYBA1Fi+rykZqPI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jTR8jPSYBABXoEGYdBHPqHP91Vz5+mxdiSkvXJn6luyFZNHx7R5uk/wHvCVB53dwQ Jtzur91VlmO+l6bhbMrxwhP977FaGEQhCuEGlf5YfCSRe6sSyq3tyt5ObjelMfpzaG 25YemKMP1bQWmBtrfpiBl8OrlXGUmaLhyASPzLw0wfXgLBDYT3S+iXxM6wY4z9lR20 jg51YOWd/2RzVgCV5q5oO5ue/ucm5O3AuzNgxzhGrFiOBcd/H+oVVtATbmrJtQU204 6c2xRUNxnm7h1AdgNnWpm0V1fSHdMBuS6tYU8OQlcVeX30zN84fbs7wCRpuKqr0KyQ 4liAKXby1wlZg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/NV1-q5tTBz6jolmsOhnuK7334Gg Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 26 Feb 2014 20:27:36 -0000 I would like some clarity about how this interacts with DCEP. IMO these are not mutually exclusive. But they must be used with care. So, when a channel that was in the SDP previously then disappears from the SDP it is necessary to close the corresponding channel. But channels that were opened via DCEP should not be closed. That also means that one should never mention a DCEP channel in SDP. Thanks, Paul On 2/26/14 3:12 PM, Makaraju, Maridi Raju (Raju) wrote: > Please find my comments inline. > > But, there is no text on rejecting a data channel in the SDP answer. > > The answer can of course reject the whole m- line, using port zero in > the Answer m- line. But, how does the answerer reject an individual > sub-protocol data channel? > > Only attributes for "accepted data channels" are included in the SDP > answer, which indicates back to the offerer which ones are rejected > (they just aren't there). This should be made clearer in the text. > > Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted > data channels: > > “This line MUST be replicated without changes in the SDP answer, if > > the answerer accepts the offered data channel.” > > I guess one way to reject would be to simply not include the dcmap > attribute in the Answer, and the Offerer then needs to figure out > what was rejected based on the stream values not present in the Answer. > > Yes. That is what was intended. > > /[Raju] In addition to the above mentiooed cases, if we all agree we > need to add the following cases in the next draft:/ > > */1./*SDP offer has no a=dcmap. This has two use cases: > > a.Initial SDP offer: no data channel streams (DCS) are open yet. > > b.Subsequent SDP offer: Remove all previously opened data channels/streams. > > In either case, the SCTP association is kept open (and ICE procedures > are performed) even when no data channels are in use. > > */2./*Creation of new DCS(s) using SDP offer (initial or subsequent) > > a.Offerer has to create the data channels locally first by doing > createDataChannel or equivalent API into data channel stack before > sending offer. > > */3./*SDP offer was rejected > > a.DCSs are kept per previous SDP offer/answer. This means DCSs that are > to be deleted has to be deleted (i.e. calling createDataChannel or > equivalent API) only after successful SDP answer. > > b.If any new DCSs are attempted to be created per new SDP offer, these > have to be closed now. > > */4./*Per > http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-createdatachannel > createDataChannel() API the ‘external’ negotiation field is per data > channel. But this draft only allows external negotiation to be used for > all or no streams; it can’t be selective. This restriction is also > needed so that the SDP offer/answer odd/even stream id allocation won’t > conflict DCP’s TLS role based odd/even mechanism. > > Best Regards! > > Raju > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Feb 26 12:31:54 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 52C561A0111 for ; Wed, 26 Feb 2014 12:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Db-sZ96zVLWa for ; Wed, 26 Feb 2014 12:31:45 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0016E1A00D7 for ; Wed, 26 Feb 2014 12:31:44 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1QKVeAe028885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 14:31:40 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s1QKVbWk028526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 15:31:39 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 15:31:39 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Richard Ejzak Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel Thread-Index: Ac8y9K3pwn95tj5YT7SqspOdgSm1jf///isA///d/LCAADx9gP//qDPA//9J3TA= Date: Wed, 26 Feb 2014 20:31:38 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1BC4D7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1BC7FC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1BCD0C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BCD0C@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFFB63CUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xi3zxegadyKWCVwojGnYBBJf4iI Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel 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, 26 Feb 2014 20:31:49 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826DFFB63CUS70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Comments inline. Hi, You also need to be more clear on whether sending of SSN reset is mandator= y when using your draft (you only say that "browsers will send it"). The text should refer to protocol stack behavior rather than to the browser= since it's supposed to also apply to data channel usage outside the contex= t of WebRTC. (We intended to fix all th browser references in this draft a= nd missed this one.) So, yes, SSN reset is mandatory. Then you also need to cover that in the procedures. For example, when an entity receives an Offer removing a channel, it MUST s= end a SSN reset. [Raju] Sure, we will make that clear. Thanks. As I already commented on oth= er thread, the section "4.3.2 Closing data channel" needs more description. Also, what to do if an entity receives an SSN reset, but not an associated = Offer. [Raju] Also as noted in other email thread, SDP offerer who wants to close = a data channel should close the data channel ONLY when successful SDP answe= r is received. The above mentioned SSN reset case happens when SDP answerer= starts closing channel right after sending SDP answer. SDP offer side data= channel stack needs to handle such a case anyway (we will have this scenar= io with inband DCP too) and informs the application via onClose() or equiva= lent API. Then at SDP answer, offerer do not have to explictly close the da= ta channel. Lastly, SSN reset Thanks Raju These kind of error situations often cause troubles at interop testings, so= let's try to cover them from the beginning :) Regards, Christer From: Richard Ejzak [mailto:richard.ejzak@gmail.com] Sent: 26. helmikuuta 2014 16:08 To: Christer Holmberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external clos= ing of channel Hi Christer, Another good catch. Although it is implied that closed data channels are r= emoved from subsequent offers, this should be stated explicitly. BR, RIchard On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg > wrote: Hi, Section 5.2.3 says: "It is specific to the sub-protocol whether this closing must in addition be signaled to the peer via a new SDP offer/answer= exchange." Shouldn't the draft define how it is done using an SDP offer/answer exchang= e? Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_E1FE4C082A89A246A11D7F32A95A17826DFFB63CUS70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Comments inline.

 <= /p>

 

 

Hi,

 You also need to be more clear on= whether sending of SSN reset is mandatory when using your draft (you only say that “browsers will send it”).=

 

The text should refer to protoc= ol stack behavior rather than to the browser since it's supposed to also ap= ply to data channel usage outside the context of WebRTC.  (We intended= to fix all th browser references in this draft and missed this one.)  So, yes, SSN reset is mandatory.   =  

&n= bsp;

Then you a= lso need to cover that in the procedures.

 = ;

For exampl= e, when an entity receives an Offer removing a channel, it MUST send a SSN = reset.

[Raju] S= ure, we will make that clear. Thanks. As I already commented on other threa= d, the section “4.3.2 Closing data channel” needs more descript= ion.=

 = ;

Also, what= to do if an entity receives an SSN reset, but not an associated Offer.

[Raju] A= lso as noted in other email thread, SDP offerer who wants to close a data c= hannel should close the data channel ONLY when successful SDP answer is received. The above mentioned SSN reset case happens when SD= P answerer starts closing channel right after sending SDP answer. SDP offer= side data channel stack needs to handle such a case anyway (we will have t= his scenario with inband DCP too) and informs the application via onClose() or equivalent API. Then at SDP a= nswer, offerer do not have to explictly close the data channel. Lastly, SSN= reset

&nb= sp;

Thanks

Raju

&nb= sp;

 = ;

These kind= of error situations often cause troubles at interop testings, so let’= ;s try to cover them from the beginning J

 = ;

Regards,

 = ;

Christer

 = ;

 

From: Richard Ejzak [mailto:= richard.ejzak@= gmail.com]
Sent: 26. helmikuuta 2014 16:08
To: Christer Holmberg
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: extern= al closing of channel

 

Hi Christer,

Another good catch.  Although it is implied that closed data = channels are removed from subsequent offers, this should be stated explicit= ly.

 

BR, RIchard

 

On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg <christer.holmberg@= ericsson.com> wrote:

Hi,

 

Section 5.2.3 says:

 

”It is specific to the sub-protocol whether this closing must in=

            = ;    addition be signaled to the peer via a new SDP offer/an= swer exchange.”

 

Shouldn’t the draft define how it is done using an SDP offer= /answer exchange?

 

Regards,

 

Christer


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

 

 

--_000_E1FE4C082A89A246A11D7F32A95A17826DFFB63CUS70UWXCHMBA02z_-- From nobody Wed Feb 26 12:38:54 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 9D59D1A0247 for ; Wed, 26 Feb 2014 12:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 MfGnrr07lOCG for ; Wed, 26 Feb 2014 12:38:42 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 46B971A0281 for ; Wed, 26 Feb 2014 12:38:41 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1QKcbJ9005068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 14:38:37 -0600 (CST) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s1QKcb0v031878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 15:38:37 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 15:38:37 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Richard Ejzak Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel Thread-Index: Ac8y9K3pwn95tj5YT7SqspOdgSm1jf///isA///d/LCAADx9gP//qDPA//9J3TD//pBtYA== Date: Wed, 26 Feb 2014 20:38:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1BC4D7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1BC7FC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1BCD0C@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFFB693US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SPZ4CbBoxGOVTmgyJO3SaHc75KY Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel 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, 26 Feb 2014 20:38:49 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826DFFB693US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, hit the send button by accident. Comments inline. From: Makaraju, Maridi Raju (Raju) Sent: Wednesday, February 26, 2014 2:32 PM To: Christer Holmberg; Richard Ejzak Cc: mmusic@ietf.org Subject: RE: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external clos= ing of channel Hi, Comments inline. Hi, You also need to be more clear on whether sending of SSN reset is mandator= y when using your draft (you only say that "browsers will send it"). The text should refer to protocol stack behavior rather than to the browser= since it's supposed to also apply to data channel usage outside the contex= t of WebRTC. (We intended to fix all th browser references in this draft a= nd missed this one.) So, yes, SSN reset is mandatory. Then you also need to cover that in the procedures. For example, when an entity receives an Offer removing a channel, it MUST s= end a SSN reset. [Raju] Sure, we will make that clear. Thanks. As I already commented on oth= er thread, the section "4.3.2 Closing data channel" needs more description. Also, what to do if an entity receives an SSN reset, but not an associated = Offer. [Raju] Also as noted in other email thread, SDP offerer who wants to close = a data channel should close the data channel ONLY when successful SDP answe= r is received. The above mentioned SSN reset case happens when SDP answerer= starts closing channel right after sending SDP answer. SDP offer side data= channel stack needs to handle such a case anyway (we will have this scenar= io with inband DCP too) and informs the application via onClose() or equiva= lent API. Then at SDP answer, offerer do not have to explictly close the da= ta channel. Lastly, SSN reset [Raju] If SSN reset is received on a side which did not having a pending SD= P answer (to remove the stream) or the stream was not closed earlier via SD= P offer/answer then a new SDP offer has to be generated to remove the strea= m via external negotiation. Otherwise no new SDP offer is needed as the str= eam is being removed or was removed already. We will add this text to section 4.3.2. Thanks Raju Thanks Raju These kind of error situations often cause troubles at interop testings, so= let's try to cover them from the beginning :) Regards, Christer From: Richard Ejzak [mailto:richard.ejzak@gmail.com] Sent: 26. helmikuuta 2014 16:08 To: Christer Holmberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external clos= ing of channel Hi Christer, Another good catch. Although it is implied that closed data channels are r= emoved from subsequent offers, this should be stated explicitly. BR, RIchard On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg > wrote: Hi, Section 5.2.3 says: "It is specific to the sub-protocol whether this closing must in addition be signaled to the peer via a new SDP offer/answer= exchange." Shouldn't the draft define how it is done using an SDP offer/answer exchang= e? Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_E1FE4C082A89A246A11D7F32A95A17826DFFB693US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, hit the send butto= n by accident.  Comments inline.

 <= /p>

From: Makaraju= , Maridi Raju (Raju)
Sent: Wednesday, February 26, 2014 2:32 PM
To: Christer Holmberg; Richard Ejzak
Cc: mmusic@ietf.org
Subject: RE: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: extern= al closing of channel

 

Hi,

Comments inline.

 <= /p>

 

 

Hi,

 You also need to be more clear on= whether sending of SSN reset is mandatory when using your draft (you only say that “browsers will send it”).=

 

The text should refer to protoc= ol stack behavior rather than to the browser since it's supposed to also ap= ply to data channel usage outside the context of WebRTC.  (We intended= to fix all th browser references in this draft and missed this one.)  So, yes, SSN reset is mandatory.   =  

&n= bsp;

Then you a= lso need to cover that in the procedures.

 = ;

For exampl= e, when an entity receives an Offer removing a channel, it MUST send a SSN = reset.

[Raju] S= ure, we will make that clear. Thanks. As I already commented on other threa= d, the section “4.3.2 Closing data channel” needs more descript= ion.=

 = ;

Also, what= to do if an entity receives an SSN reset, but not an associated Offer.

[Raju] A= lso as noted in other email thread, SDP offerer who wants to close a data c= hannel should close the data channel ONLY when successful SDP answer is received. The above mentioned SSN reset case happens when SD= P answerer starts closing channel right after sending SDP answer. SDP offer= side data channel stack needs to handle such a case anyway (we will have t= his scenario with inband DCP too) and informs the application via onClose() or equivalent API. Then at SDP a= nswer, offerer do not have to explictly close the data channel. Lastly, SSN= reset

[Raj= u] If SSN reset is received on a side which did not having a pending SDP an= swer (to remove the stream) or the stream was not closed earlier via SDP offer/answer then a new SDP offer has to be generated to remove th= e stream via external negotiation. Otherwise no new SDP offer is needed as = the stream is being removed or was removed already.

We w= ill add this text to section 4.3.2.

 

Than= ks

Raju=

&nb= sp;

Thanks

Raju

&nb= sp;

 = ;

These kind= of error situations often cause troubles at interop testings, so let’= ;s try to cover them from the beginning J

 = ;

Regards,

 = ;

Christer

 = ;

 

From: Richard Ejzak [mailto:= richard.ejzak@= gmail.com]
Sent: 26. helmikuuta 2014 16:08
To: Christer Holmberg
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: extern= al closing of channel

 

Hi Christer,

Another good catch.  Although it is implied that closed data = channels are removed from subsequent offers, this should be stated explicit= ly.

 

BR, RIchard

 

On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg <christer.holmberg@= ericsson.com> wrote:

Hi,

 

Section 5.2.3 says:

 

”It is specific to the sub-protocol whether this closing must in=

            = ;    addition be signaled to the peer via a new SDP offer/an= swer exchange.”

 

Shouldn’t the draft define how it is done using an SDP offer= /answer exchange?

 

Regards,

 

Christer


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

 

 

--_000_E1FE4C082A89A246A11D7F32A95A17826DFFB693US70UWXCHMBA02z_-- From nobody Wed Feb 26 21:45: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 CEE7F1A03C8 for ; Wed, 26 Feb 2014 21:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 p2oTx0AeTMY9 for ; Wed, 26 Feb 2014 21:45:30 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id E2DD01A01B3 for ; Wed, 26 Feb 2014 21:45:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CA02A7C0A45 for ; Thu, 27 Feb 2014 06:45:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp41pQJf3zbS for ; Thu, 27 Feb 2014 06:45:25 +0100 (CET) Received: from [172.16.199.123] (75-144-30-89-NewEngland.hfc.comcastbusiness.net [75.144.30.89]) by mork.alvestrand.no (Postfix) with ESMTPSA id DA1457C051E for ; Thu, 27 Feb 2014 06:45:22 +0100 (CET) Message-ID: <530EAED1.7090609@alvestrand.no> Date: Thu, 27 Feb 2014 04:19:45 +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: <52FEAA17.9070406@nostrum.com> <53014BFC.3070406@alum.mit.edu> In-Reply-To: <53014BFC.3070406@alum.mit.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/01yyFwkWTJnmLLEQULD43rPYiAs Subject: Re: [MMUSIC] POF/PAN draft update - move BUNDLE-specific stuff to bundle 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: Thu, 27 Feb 2014 05:45:33 -0000 On 02/17/2014 12:38 AM, Paul Kyzivat wrote: > Another comment on this draft: > > While the mechanism described in this draft is strongly motivated by > BUNDLE, it is conceptually independent of BUNDLE. IMO all the > BUNDLE-specific behavior should be removed from this draft, and > instead placed into the BUNDLE draft. > > I realize there is a chicken/egg thing here. It would make sense to > keep the bundle-specifics here, so they don't get forgotten, until > they are incorporated into the bundle draft. If moving the BUNDLE-specific stuff to the BUNDLE draft means that BUNDLE is dependent on completion of POF/PAN before considered completed, I'm strongly opposed to this. BUNDLE should not depend on POF/PAN. If BUNDLE-specific aspects of POF/PAN need to be broken out, there needs to be a third draft that references both. > > Thanks, > Paul > > > On 2/14/14 6:43 PM, Adam Roach wrote: >> I've updated the partial offer/partial answer draft to reflect the >> conversations we had in Vancouver: >> http://tools.ietf.org/html/draft-roach-mmusic-pof-pan-02 >> >> Diffs: >> http://tools.ietf.org/rfcdiff?url2=draft-roach-mmusic-pof-pan-02.txt >> >> Note that this relies on the following draft for group membership >> manipulation: >> http://tools.ietf.org/html/draft-roach-mmusic-groupid >> >> Please point out whether you think I've missed any of the Vancouver >> discussions or other feedback. Thanks! >> >> /a >> >> >> _______________________________________________ >> 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 nobody Thu Feb 27 11:55: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 1E86B1A0661; Thu, 27 Feb 2014 11:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 SRhvqrIDo4ZZ; Thu, 27 Feb 2014 11:55:17 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 55E641A04B7; Thu, 27 Feb 2014 11:55:16 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1RJtDUB011487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 13:55:13 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s1RJtAdB022388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 14:55:13 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 14:55:11 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: AQHPMv00Ot+PDux+H0inH2oRraNWlJrH7JxQgABjlQCAAR/dwA== Date: Thu, 27 Feb 2014 19:55:11 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> In-Reply-To: <530E4E34.4010707@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xZzfQ1DNAaBT8GpFQUwWqdKj2dE Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 27 Feb 2014 19:55:20 -0000 + rtcweb as it impacts DCP draft. Please see comments inline. > I would like some clarity about how this interacts with DCEP. >=20 > IMO these are not mutually exclusive. But they must be used with care. [Raju] I debated on this with myself before concluding in my earlier reply that they are mutually exclusive. My mistake, instead of=20 concluding I should have given options. To make this internal or=20 external per data channel granuality we need to add more=20 restrictions/notes to these draft.=20 http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-03#section-4 say= s: "To avoid glare in opening Channels, each side MUST use either even or odd Streams when sending a DATA_CHANNEL_OPEN message. The method used to determine which side uses odd or even is based on the underlying DTLS connection role when used in WebRTC, with the side acting as the DTLS client using even stream identifiers." Where as draft-ejzak-mmusic-data-channel-sdpneg determines this=20 based on SDP offerer (even) and answerer (odd). What if the SDP answerer becomes TLS client? The stream #id assignments conflict with SDP offer/answer. So, to avoid such conflict we need to add the following clarifications: 1. draft-ejzak-mmusic-data-channel-sdpneg If DCP is used along with external negotiation, when creating data channel the client should always specify the stream id=20 to use. Leaving selection to data channel stack (DCSK) will=20 result in conflicts as DCSK (browser) will assign stream ids=20 per DTLS role. 2. draft-ietf-rtcweb-data-protocol-03 Item (1) above conflicts with DCP's odd/even rule, for which the draft says "MUST" ("each side MUST use either even or=20 odd Streams"). This section 4 (and other sections) text has to be updated to "SHOULD" or "MAY". If we all agree to these updates then I am ok to make=20 internal or external negotiation granularity per data channel. Best Regards Raju >=20 > So, when a channel that was in the SDP previously then disappears from > the SDP it is necessary to close the corresponding channel. But channels > that were opened via DCEP should not be closed. >=20 > That also means that one should never mention a DCEP channel in SDP. >=20 > Thanks, > Paul >=20 > On 2/26/14 3:12 PM, Makaraju, Maridi Raju (Raju) wrote: > > Please find my comments inline. > > > > But, there is no text on rejecting a data channel in the SDP answer. > > > > The answer can of course reject the whole m- line, using port zero in > > the Answer m- line. But, how does the answerer reject an individual > > sub-protocol data channel? > > > > Only attributes for "accepted data channels" are included in the SDP > > answer, which indicates back to the offerer which ones are rejected > > (they just aren't there). This should be made clearer in the text. > > > > Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted > > data channels: > > > > "This line MUST be replicated without changes in the SDP answer, if > > > > the answerer accepts the offered data channel." > > > > I guess one way to reject would be to simply not include the dcmap > > attribute in the Answer, and the Offerer then needs to figure out > > what was rejected based on the stream values not present in the > Answer. > > > > Yes. That is what was intended. > > > > /[Raju] In addition to the above mentiooed cases, if we all agree we > > need to add the following cases in the next draft:/ > > > > */1./*SDP offer has no a=3Ddcmap. This has two use cases: > > > > a.Initial SDP offer: no data channel streams (DCS) are open yet. > > > > b.Subsequent SDP offer: Remove all previously opened data > channels/streams. > > > > In either case, the SCTP association is kept open (and ICE procedures > > are performed) even when no data channels are in use. > > > > */2./*Creation of new DCS(s) using SDP offer (initial or subsequent) > > > > a.Offerer has to create the data channels locally first by doing > > createDataChannel or equivalent API into data channel stack before > > sending offer. > > > > */3./*SDP offer was rejected > > > > a.DCSs are kept per previous SDP offer/answer. This means DCSs that are > > to be deleted has to be deleted (i.e. calling createDataChannel or > > equivalent API) only after successful SDP answer. > > > > b.If any new DCSs are attempted to be created per new SDP offer, these > > have to be closed now. > > > > */4./*Per > > http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection- > createdatachannel > > createDataChannel() API the 'external' negotiation field is per data > > channel. But this draft only allows external negotiation to be used fo= r > > all or no streams; it can't be selective. This restriction is also > > needed so that the SDP offer/answer odd/even stream id allocation won't > > conflict DCP's TLS role based odd/even mechanism. > > > > Best Regards! > > > > Raju > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Feb 27 13:51: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 4E8BD1A0676; Thu, 27 Feb 2014 13:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_14=0.6, 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 Hzx9tDyqZyMZ; Thu, 27 Feb 2014 13:51:16 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id BFD9C1A0675; Thu, 27 Feb 2014 13:51:15 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-40-530fb35172e6 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 8E.D9.04853.153BF035; Thu, 27 Feb 2014 22:51:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Thu, 27 Feb 2014 22:51:12 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Paul Kyzivat" , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: Ac8y9YTn0Ql62f4ZSwiP0pv/vZVV7v///hmAgABkRoCAAAQtAIABiUuA///PR8A= Date: Thu, 27 Feb 2014 21:51:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW7gZv5gg7MrpSymLn/MYrFiwwFW i4aNV1gt1v5rZ3dg8Wh9tpfV4+/7D0weS5b8ZApgjuKySUnNySxLLdK3S+DKaHzZxlrQZVBx 48hGxgbGuWpdjJwcEgImEscuf2GEsMUkLtxbz9bFyMUhJHCCUWLPmcVMEM4SRonJH54AVXFw sAlYSHT/0waJiwjsZpT4+vwCM0i3sECsxNFlV5lAakQE4iRenlMBCYsI+El8OrqFBcRmEVCV uP7qI1gJr4CvxL3jUhDj7zBJnD9ygh2khhNozIY1M8AOYgQ66PupNUwgNrOAuMSHg9eZIQ4V kFiy5zyULSrx8vE/VghbSWLF9kuMEPV6EjemTmGDsLUlli18DVbPKyAocXLmE5YJjKKzkIyd haRlFpKWWUhaFjCyrGKULE4tLs5NNzLQy03PLdFLLcpMLi7Oz9MrTt3ECIymg1t+G+1gPLnH /hCjNAeLkjjvddaaICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MlYLzvqp/OTCv9I/biuxC Jt1jR/20Z2T3Ja0/qeWxWvpGoITv7HNL70hXbdn4oIwl9J+uA0PCFfm8Hacmvmx6nhSyqkYx 13f6sVrRo9OfzbKIczBbeiG8p8DFettKqyaxVT53ZsseZHRe05iRGMl+eLpjo9H8JxZ5rpVL c2cy9Uxr0bqx71afEktxRqKhFnNRcSIAmYhj6nQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4W_hvijtXZHeuZEUrBXgenyoFog Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 27 Feb 2014 21:51:18 -0000 Hi, Isn't it enough to, in the data channel protocol spec, say that the odd/eve= n rule applies unless the stream id is explicitly negotiated using some oth= er mechanism? Or something like that... Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta Makaraju,= Maridi Raju (Raju) L=E4hetetty: 27. helmikuuta 2014 21:55 Vastaanottaja: Paul Kyzivat; mmusic@ietf.org; rtcweb@ietf.org Aihe: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejecti= on of channel + rtcweb as it impacts DCP draft. Please see comments inline. > I would like some clarity about how this interacts with DCEP. >=20 > IMO these are not mutually exclusive. But they must be used with care. [Raju] I debated on this with myself before concluding in my earlier reply = that they are mutually exclusive. My mistake, instead of concluding I shoul= d have given options. To make this internal or external per data channel gr= anuality we need to add more restrictions/notes to these draft.=20 http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-03#section-4 say= s: "To avoid glare in opening Channels, each side MUST use either even or odd Streams when sending a DATA_CHANNEL_OPEN message. The method used to determine which side uses odd or even is based on the underlying DTLS connection role when used in WebRTC, with the side acting as the DTLS client using even stream identifiers." Where as draft-ejzak-mmusic-data-channel-sdpneg determines this based on SD= P offerer (even) and answerer (odd). What if the SDP answerer becomes TLS client? The stream #id assignments con= flict with SDP offer/answer. So, to avoid such conflict we need to add the following clarifications: 1. draft-ejzak-mmusic-data-channel-sdpneg If DCP is used along with external negotiation, when creating data channel the client should always specify the stream id=20 to use. Leaving selection to data channel stack (DCSK) will=20 result in conflicts as DCSK (browser) will assign stream ids=20 per DTLS role. 2. draft-ietf-rtcweb-data-protocol-03 Item (1) above conflicts with DCP's odd/even rule, for which the draft says "MUST" ("each side MUST use either even or=20 odd Streams"). This section 4 (and other sections) text has to be updated to "SHOULD" or "MAY". If we all agree to these updates then I am ok to make internal or external = negotiation granularity per data channel. Best Regards Raju >=20 > So, when a channel that was in the SDP previously then disappears from=20 > the SDP it is necessary to close the corresponding channel. But=20 > channels that were opened via DCEP should not be closed. >=20 > That also means that one should never mention a DCEP channel in SDP. >=20 > Thanks, > Paul >=20 > On 2/26/14 3:12 PM, Makaraju, Maridi Raju (Raju) wrote: > > Please find my comments inline. > > > > But, there is no text on rejecting a data channel in the SDP answer. > > > > The answer can of course reject the whole m- line, using port zero=20 > > in the Answer m- line. But, how does the answerer reject an=20 > > individual sub-protocol data channel? > > > > Only attributes for "accepted data channels" are included in the SDP=20 > > answer, which indicates back to the offerer which ones are rejected=20 > > (they just aren't there). This should be made clearer in the text. > > > > Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted > > data channels: > > > > "This line MUST be replicated without changes in the SDP answer,=20 > > if > > > > the answerer accepts the offered data channel." > > > > I guess one way to reject would be to simply not include the dcmap > > attribute in the Answer, and the Offerer then needs to figure out > > what was rejected based on the stream values not present in the > Answer. > > > > Yes. That is what was intended. > > > > /[Raju] In addition to the above mentiooed cases, if we all agree we=20 > > need to add the following cases in the next draft:/ > > > > */1./*SDP offer has no a=3Ddcmap. This has two use cases: > > > > a.Initial SDP offer: no data channel streams (DCS) are open yet. > > > > b.Subsequent SDP offer: Remove all previously opened data > channels/streams. > > > > In either case, the SCTP association is kept open (and ICE=20 > > procedures are performed) even when no data channels are in use. > > > > */2./*Creation of new DCS(s) using SDP offer (initial or subsequent) > > > > a.Offerer has to create the data channels locally first by doing=20 > > createDataChannel or equivalent API into data channel stack before=20 > > sending offer. > > > > */3./*SDP offer was rejected > > > > a.DCSs are kept per previous SDP offer/answer. This means DCSs that=20 > > are to be deleted has to be deleted (i.e. calling createDataChannel=20 > > or equivalent API) only after successful SDP answer. > > > > b.If any new DCSs are attempted to be created per new SDP offer,=20 > > these have to be closed now. > > > > */4./*Per > > http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection- > createdatachannel > > createDataChannel() API the 'external' negotiation field is per data=20 > > channel. But this draft only allows external negotiation to be used=20 > > for all or no streams; it can't be selective. This restriction is=20 > > also needed so that the SDP offer/answer odd/even stream id=20 > > allocation won't conflict DCP's TLS role based odd/even mechanism. > > > > Best Regards! > > > > Raju > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Feb 27 14:59: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 4C73E1A02A6; Thu, 27 Feb 2014 14:59:10 -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 WCDKXSH_WHe9; Thu, 27 Feb 2014 14:59:09 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CF22B1A015E; Thu, 27 Feb 2014 14:59:08 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1RMx4S9027874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 16:59:04 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s1RMx3f5029253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 17:59:03 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 17:59:03 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: AQHPMv00Ot+PDux+H0inH2oRraNWlJrH7JxQgABjlQCAAR/dwIAAideA//+55EA= Date: Thu, 27 Feb 2014 22:59:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/28M4CyqmGlaTTdr1b1hTDbyQJNY Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 27 Feb 2014 22:59:10 -0000 Hi Christer, > Hi, >=20 > Isn't it enough to, in the data channel protocol spec, say that the odd/e= ven > rule applies unless the stream id is explicitly negotiated using some oth= er > mechanism? >=20 [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data-chan= nel-sdpneg should still need to say that "when both external and DCP are us= ed, even for DCP created streams the stream ids have to be specified and ma= naged by the application (else DCP stack will default to odd/even rule per = DTLS role which may conflict with SDP offer/answer rule)". Thanks for agreeing to add this to the draft! Raju From nobody Fri Feb 28 02:33: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 236501A07AD; Fri, 28 Feb 2014 02:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] 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 6YoB2f-y-aqI; Fri, 28 Feb 2014 02:33:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B51B51A019A; Fri, 28 Feb 2014 02:33:35 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140228103335.29438.12054.idtracker@ietfa.amsl.com> Date: Fri, 28 Feb 2014 02:33:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ydv7RNH4ZxT-qUkD1JifEi69ELY Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-g723-g729-06.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, 28 Feb 2014 10:33:37 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Offer/Answer Considerations for G723 Annex A and G729 Annex B Author(s) : M. Perumal, et al Filename : draft-ietf-mmusic-sdp-g723-g729 Pages : 8 Date : 2014-02-28 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-g723-g729-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-g723-g729"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-28023335.I-D@ietf.org> --NextPart-- From nobody Fri Feb 28 04:31: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 1C5D01A0285 for ; Fri, 28 Feb 2014 04:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 kLAmGdeWW7pK for ; Fri, 28 Feb 2014 04:31:22 -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 DC00A1A025E for ; Fri, 28 Feb 2014 04:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1453; q=dns/txt; s=iport; t=1393590680; x=1394800280; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=F2W5MtTUmu/Bp96hjjggXJkbLvS/TK8mzPbslDJ5TQQ=; b=aeUjI8SLbPRUVvOwPvglwfGrmQnqJfOC4IUv0Q38kQyf3Pb03HhQxZMZ i+D04b7WPB5amdROh/SbyjoegFTtY90t96SVGuB5w0HCkfre5ftgFEsk3 EppaAiZ3iYhFE0hz8T66/O+cS3hMG1DeMWflHFAb6JbsYojngq+klyavb Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAFWBEFOtJV2b/2dsb2JhbABagwY7V8EcgRMWdIIlAQEBBDpLBAIBCBEEAQELFAkHMhQJCAIEEwgBh3ANyzMXjgQBAR44BoMdgRQEqmSDLYFxOQ X-IronPort-AV: E=Sophos;i="4.97,561,1389744000"; d="scan'208";a="23937353" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 28 Feb 2014 12:31:07 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1SCV75x006342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 28 Feb 2014 12:31:07 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.2]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 28 Feb 2014 06:31:07 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-g723-g729-06.txt Thread-Index: AQHPNHCOQOgFAags0kedPqQk5mg3IJrKlzBg Date: Fri, 28 Feb 2014 12:31:06 +0000 Message-ID: References: <20140228103335.29438.12054.idtracker@ietfa.amsl.com> In-Reply-To: <20140228103335.29438.12054.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.44.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QCbiyIudBnvvqXDqIX7ksxmPIR8 Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-g723-g729-06.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, 28 Feb 2014 12:31:24 -0000 This revision addresses the comments received during IESG evaluation. Muthu |-----Original Message----- |From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Internet-Drafts= @ietf.org |Sent: Friday, February 28, 2014 4:04 PM |To: i-d-announce@ietf.org |Cc: mmusic@ietf.org |Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-g723-g729-06.txt | |A new Internet-Draft is available from the on-line Internet-Drafts directo= ries. |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 | Author(s) : M. Perumal, et al | Filename : draft-ietf-mmusic-sdp-g723-g729 | Pages : 8 | Date : 2014-02-28 | | 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. | | |A URL for this Internet-Draft is: |http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-g723-g729-06.txt | |Internet-Drafts are also available by anonymous FTP at: |ftp://ftp.ietf.org/internet-drafts/ | |Below is the data which will enable a MIME compliant mail reader |implementation to automatically retrieve the ASCII version of the |Internet-Draft. From nobody Fri Feb 28 04:36: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 063581A018F; Fri, 28 Feb 2014 04:36:26 -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 zUoxTLIumUOx; Fri, 28 Feb 2014 04:36:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B22971A07B5; Fri, 28 Feb 2014 04:36:21 -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: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140228123621.15125.7871.idtracker@ietfa.amsl.com> Date: Fri, 28 Feb 2014 04:36:21 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SxxrnHTgbVnuTGXtkInxwk91huo Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'Offer/Answer Considerations for G723 Annex A and G729 Annex B' to Proposed Standard (draft-ietf-mmusic-sdp-g723-g729-06.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, 28 Feb 2014 12:36:26 -0000 The IESG has approved the following document: - 'Offer/Answer Considerations for G723 Annex A and G729 Annex B' (draft-ietf-mmusic-sdp-g723-g729-06.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-sdp-g723-g729/ Technical Summary 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. Working Group Summary There is WG consensus behind this draft. All issues raised during and before WGLC have been addressed. Document Quality This document clarifies behavior with the discussed SDP parameters to be in line with existing specifications and pragmatic implementations. The document has been discussed in MMUSIC, PAYLOAD, and AVTEXT working groups and has been revised according to the feedback. 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. From nobody Fri Feb 28 06:46: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 29B9F1A080E for ; Fri, 28 Feb 2014 06:45:58 -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 8BYqqavrG2J0 for ; Fri, 28 Feb 2014 06:45:56 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C71F11A02C1 for ; Fri, 28 Feb 2014 06:45:55 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-88-5310a121942e Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 40.7F.23809.121A0135; Fri, 28 Feb 2014 15:45:53 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.347.0; Fri, 28 Feb 2014 15:45:52 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D75EA110007; Fri, 28 Feb 2014 16:45:52 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CE96456B2B; Fri, 28 Feb 2014 16:45:47 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 82AB054336; Fri, 28 Feb 2014 16:45:47 +0200 (EET) Message-ID: <5310A120.4@ericsson.com> Date: Fri, 28 Feb 2014 16:45:52 +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.3.0 MIME-Version: 1.0 To: Justin Uberti References: <526147C3.9040204@ericsson.com> <5261704B.9090307@nostrum.com> In-Reply-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+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvja7iQoFgg4mLJSy2ThWymLr8MYsD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DK2LX2HHvBe56Kvp3+DYz/OLsYOTkkBEwknjb/ ZoWwxSQu3FvP1sXIxSEkcIhRYv3jrYwQzgZGiav9T6GcPYwSbacvM0M4axklTh+exwzSLySw nFFi86FyEJtXQFXi8pvtLCA2C5D95t5qdhCbTcBe4uaE62C2qECyxKdFnYwQ9YISJ2c+AasX EVCTeDhrF9hNzAIyEjPONjKB2MICDhLP36xjh1h8hVHi5bYeoMXsHJwCgRKNjBDlthIX5lxn gbDlJba/ncMM8ZqaxNVzm6DOVJW4+u8V4wRG0VlINs9C0j4LSfsCRuZVjOy5iZk56eVGmxiB AX9wy2/VHYx3zokcYpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+N8ZckA jR1S/l1ywjqRKd/9jT9yzXr0IGDrxueK23TO1C5bNPlc9Xu5QMGS0MITJz7dULDMdVj7yZHv X+iX55tvxm1zf7NZg+fE6dqEb7lzamer/33iO3HCgh2Vc6u3Hrz06Nz6f7sFXn1I5dnz893O xkNX8+QjJ3qwmrE2/ctYH/4/pG3xGu1PSizFGYmGWsxFxYkAGh/RTUYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2I7pOpHgAKC8g_E9IeuvJk0XcBw Cc: mmusic Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks 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, 28 Feb 2014 14:45:58 -0000 Hi Justin, We discussed this issue at the previous IETF meeting and back then you were doing large scale measurements with Chrome on the sensible connectivity check values. Did you come into some conclusions with those studies? Anything new we could recommend based on the results? Cheers, Ari On 18/10/13 21:34, Justin Uberti wrote: > FWIW, we are now doing trials to understand what is the absolute lower > bound for ICE checks on today's internet (i.e. what is the minimum time > to allow for a NAT to create a new UDP binding). > > > On Fri, Oct 18, 2013 at 10:30 AM, Adam Roach > wrote: > > On 10/18/13 09:44, Emil Ivov wrote: >> It might be worth reminding exactly what these 50ms would be >> protecting us against > > They're protecting us against RTP arriving at a rate of 20ms per packet. > > >> and why is it that we don't need to be >> protected against it in the case of RTP where 20ms is accepted as a >> fine default value. > > Well, it's not. This is exactly why we ended up requiring ICE: it > ensures explicit consent before you start blowing media at someone. > > See also > http://www.ietf.org/mail-archive/web/mmusic/current/msg04589.html > > /a > > _______________________________________________ > 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 nobody Fri Feb 28 07:57: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 1F52B1A085C for ; Fri, 28 Feb 2014 07:57:13 -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 Jomb5F151gPT for ; Fri, 28 Feb 2014 07:57:12 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id EC91B1A083E for ; Fri, 28 Feb 2014 07:57:11 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id XpJr1n00A1YDfWL55rxAW7; Fri, 28 Feb 2014 15:57:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([130.129.152.238]) by omta20.westchester.pa.mail.comcast.net with comcast id Xruu1n00H58sGga3gruwrg; Fri, 28 Feb 2014 15:55:08 +0000 Message-ID: <5310B14E.4000809@alum.mit.edu> Date: Fri, 28 Feb 2014 10:54:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> 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=1393603030; bh=f9fp8KuOfJ9zm18eCbvBXn0kpxqdlHNcscQWACXwnYQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F/LR0zG8rf9MGFPCVrnz1dIdwW8bHsnCzQO02fyDnrbBjbjz4cAabW21Dnm1cp7ps dh/wpvMw01VsJ7aXs6062qovHS88AhY4kak1TgmaAAyuoPT+HzRgsYuBso+OdmgPUn ubh6ozpv2Kf/NfNRljhhPp+VubssrhcLlRRQVtKa8QBa8fJgzFIk1pKcbh9mEuuBDb gWi/atNgAF7nKKJEC6PzuhdNx8/9R4meFXW2eoxg4fpwtzIfgoKsMN6NsuygTF68ow jSJi7g4zn7eiCJ0dOJJLtj1YwQORWDCCA+ku1QzTJCwoIoOnj9JKwiikpJuRU/ceim 5432jPau05sPA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fANgb7180l1A8uk3BXOCCJIc2w4 Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 28 Feb 2014 15:57:14 -0000 Raju, On 2/27/14 5:59 PM, Makaraju, Maridi Raju (Raju) wrote: > Hi Christer, > >> Hi, >> >> Isn't it enough to, in the data channel protocol spec, say that the odd/even >> rule applies unless the stream id is explicitly negotiated using some other >> mechanism? >> > [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data-channel-sdpneg should still need to say that "when both external and DCP are used, even for DCP created streams the stream ids have to be specified and managed by the application (else DCP stack will default to odd/even rule per DTLS role which may conflict with SDP offer/answer rule)". Can we assume there must be a mechanism for using DCEP and still controlling which channels are used? It might help if the O/A negotiation also followed the even/odd rule. But there are difficulties in knowing who is even and who is odd for the first O/A. If the offerer always creates the channel before sending the offer, then that will prevent the two mechanisms from stepping on one another's stream ids. Thanks, Paul > Thanks for agreeing to add this to the draft! > > Raju > > From nobody Fri Feb 28 07:58:52 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 365FA1A083E for ; Fri, 28 Feb 2014 07:58:51 -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 1nhFctxKyM6Y for ; Fri, 28 Feb 2014 07:58:50 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACE81A00DE for ; Fri, 28 Feb 2014 07:58:49 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-b3-5310b2373fde Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F7.F2.04249.732B0135; Fri, 28 Feb 2014 16:58:47 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.347.0; Fri, 28 Feb 2014 16:58:46 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F06301101F3 for ; Fri, 28 Feb 2014 17:58:46 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EE65356B2A for ; Fri, 28 Feb 2014 17:58:41 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ABC5156AEB for ; Fri, 28 Feb 2014 17:58:41 +0200 (EET) Message-ID: <5310B236.7050108@ericsson.com> Date: Fri, 28 Feb 2014 17:58:46 +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.3.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42KZGfG3Rtd8k0CwwY1vqhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsXpJ5kLdrJVLNw9ka2BsYe1i5GTQ0LARKL7+H92CFtM4sK9 9WxdjFwcQgJHGCUWPv/ABJIQEtjAKPH7qD1E4hKjxM+561khnMOMEm+vvmSBcPYySry+3sAC 0sIroC2xbcYBsB0sAqoSa1e3ge1gE7CXuDnhOpgtKpAs8WlRJyNEvaDEyZlPwHpFBGQk9m7a zAxiCws4S3zYdQMszixgK3FhznUoW15i+9s5zBB3q0lcPbeJGeJUVYmr/14xTmAUmoVk7Cwk 7bOQtC9gZF7FyFGcWpyUm25ksIkRGJ4Ht/y22MF4+a/NIUZpDhYlcd6Pb52DhATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTAeZXuUsPby1VcnXGc/Dv9w52kV24G/c7L2dC96xzYvgv3Xl+hD PGxKWWL2Nz6lWbvfnrtqveSKy67ZFVH2S79z8D++cez72q9nrZiFa+sK5YTe2UXHP/nFds/2 oqNw99WSjgm5FudLE9KsFe9361wO1OC4IZpidWnBessZv488fPS94EctU81pJZbijERDLeai 4kQAaW1TDB0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yGClbswISWYeCqen5uBTrJJS0P0 Subject: [MMUSIC] ICE options: need new optional and/or required attributes? 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, 28 Feb 2014 15:58:51 -0000 Hi all, One open issue regarding ICE-bis has been the semantics of the ice-options attribute. Currently there is no way of saying "do aggressive ICE even if you don't understand this option" or "reject my offer if you don't understand this option". One way of solving this would be to introduce a new attribute like: a=ice-options-required:foo That is, if "foo" is unknown option to the answerer, the offer is rejected. In addition to solving the second case, it could also be used to test for the first and if option was not understood, simply leave it out of the new offer. Of course this would result in one signaling exchange of delay, and hence for the first case (do still aggressive) we could also introduce yet another option: a=ice-options-optional:bar Opinions? Cheers, Ari From nobody Fri Feb 28 08:46:54 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 46D771A00D1; Fri, 28 Feb 2014 08:46:50 -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 shksOz-QIkEM; Fri, 28 Feb 2014 08:46:47 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 33F111A00EF; Fri, 28 Feb 2014 08:46:47 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1SGkesF028681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2014 10:46:40 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s1SGkY0i016154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 11:46:40 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 28 Feb 2014 11:46:34 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel Thread-Index: AQHPMv00Ot+PDux+H0inH2oRraNWlJrH7JxQgABjlQCAAR/dwIAAideA//+55ECAAXTlAP//tqXA Date: Fri, 28 Feb 2014 16:46:33 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> <5310B14E.4000809@alum.mit.edu> In-Reply-To: <5310B14E.4000809@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cJOH3TDMxoDBYFE5LDZV6TiLw6c Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 28 Feb 2014 16:46:50 -0000 Hi Paul, > >> Isn't it enough to, in the data channel protocol spec, say that the > odd/even > >> rule applies unless the stream id is explicitly negotiated using some > other > >> mechanism? > >> > > [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data- > channel-sdpneg should still need to say that "when both external and DCP = are > used, even for DCP created streams the stream ids have to be specified an= d > managed by the application (else DCP stack will default to odd/even rule = per > DTLS role which may conflict with SDP offer/answer rule)". >=20 > Can we assume there must be a mechanism for using DCEP and still > controlling which channels are used? [Raju] Yes, we can assume that and it is already supported by : http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.5 and http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannel-id I believe it is safe to assume non-browser implementations of=20 data channel stack gives an option for application to select=20 stream ids independent of DCEP or external negotiation. >=20 > It might help if the O/A negotiation also followed the even/odd rule. [Raju] May be I am missing something here. Richard's draft already has a specific even/odd rule for O/A. But the issue is TLS based rule may conflict with the O/A rule as TLS roles may change depending on a=3Dsetup. > But there are difficulties in knowing who is even and who is odd for the > first O/A. [Raju] Not related to first or subsequent O/A, but rather a conflict=20 between TLS roles vs. O/A. >=20 > If the offerer always creates the channel before sending the offer, then > that will prevent the two mechanisms from stepping on one another's > stream ids. [Raju]=20 In some cases, initial offer may not have a data channel stream created.=20 I don't know how this can prevent stepping on each other?! May be I am missing something here?! In most cases TLS role is=20 determined after O/A is completed, but offerer creates a data=20 channel before answer, then how does it know even/odd rule?=20 So, trying to use TLS role for external negotiation is problematic. Thanks Raju