From ggb@tokbox.com Wed May 1 11:27:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726AE21F94E1 for ; Wed, 1 May 2013 11:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsCqV6tpYZz4 for ; Wed, 1 May 2013 11:26:56 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id 04BEA21F9684 for ; Wed, 1 May 2013 11:26:55 -0700 (PDT) Received: from mail-pa0-f69.google.com ([209.85.220.69]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUYFeb+h2JMSCXa9+e3Zv0m14JnjJewod@postini.com; Wed, 01 May 2013 11:26:56 PDT Received: by mail-pa0-f69.google.com with SMTP id kl13so1794354pab.0 for ; Wed, 01 May 2013 11:26:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer:x-gm-message-state; bh=uvuMbPYklyzlFSmlCven0I+YYZeEcaVlVvJawEFGSeM=; b=o0lngGbDMepddOLDD1RNaRDMfiKUq32za1yoEHX42XGoaShvQqh8ZF5P4C/jDLOvBO JR0xj44TQUIl+A9BsaEqLmgm944sLRXfaKwxu7SdDoWPLaEEXcRC0vtTi4Aw6KF8wXtL 7tIz22wfssEHF7P3rCB0lk2dSrG+2Glkso1VutIi3ZLOcTFnFTsSb4Au3tBAff/7Qt50 1yPPj4900u79qWCrazidojxA0MLqERWhqGABgRJjXMTHIVajw2cGWPMeCLEEsLbLoJrS /+1Z3hyNYPzZ+rFTtp6PkY2BsykoBJQTJ2mKg2a8lo4IpVnUWlkDnMxubSkO0xV/ZJtn oVCA== X-Received: by 10.68.26.6 with SMTP id h6mr5321534pbg.149.1367432814951; Wed, 01 May 2013 11:26:54 -0700 (PDT) X-Received: by 10.68.26.6 with SMTP id h6mr5321524pbg.149.1367432814737; Wed, 01 May 2013 11:26:54 -0700 (PDT) Received: from [192.168.10.114] (ginger.tokbox.com. [216.38.134.117]) by mx.google.com with ESMTPSA id aj6sm3897974pbd.14.2013.05.01.11.26.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 11:26:53 -0700 (PDT) From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 1 May 2013 11:26:52 -0700 Message-Id: To: mmusic@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnUT5ci6Bn/tCBmXmp3u9b01n4o/I5rJacZtasMDx5Nr8hKG2fywqCISUiLIh3+M/k7vUmRGxqFi/NdO0Va9aV4P7E7uaVDUNA+9Nl0gDXOvke62V19tyUKhABTtwD6mxRvuXc0cjgyShfeh/aYlu6y4+t1pg== Subject: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 18:27:02 -0000 RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which = side is the DTLS server must be established via some out-of-band = mechanism such as SDP." What is the specification on how to signal that in SDP? =20 Specifically in case of 3pcc where both endpoints are SDP offerers which = one should take the client and server roles for DTLS? Should we tie = that role to ICE controlled/controlling roles or should we negotiate it = in the SDP somehow? G. From pkyzivat@alum.mit.edu Wed May 1 13:58:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9DF21F986C for ; Wed, 1 May 2013 13:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyEXCUscrfuS for ; Wed, 1 May 2013 13:57:56 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 7970121F99EE for ; Wed, 1 May 2013 13:57:00 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id Wcjz1l0081vXlb851kx0Ek; Wed, 01 May 2013 20:57:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id Wkx01l00E3ZTu2S3dkx0Ty; Wed, 01 May 2013 20:57:00 +0000 Message-ID: <5181819B.5050107@alum.mit.edu> Date: Wed, 01 May 2013 16:56:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: 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=1367441820; bh=LSzlL5ok0tfgVafGwFqA6pmwLOUoBD+SEYtKHz/IYK4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=X2yjbc96s95Dr8dP8LUheKFDTChlN/8vL2ld15ypEfnfGnaEyNRCWuL2bUcXs6e9T yL5mA/B2QW/ng4PAYHp19aKUMRCgEqROaM8zujRxmZ9waCet9ntqJR6HLhpUxqsFNs 8WC3rRzAmz7FHbccxe8sgl/ZM+i6l39yb0CVwSmc3kwMpLlLZYfHtMr7J6YzQwdEec uSkxxbc8DpQFdSPQ8+uBzo2NX12L41D26FXIeXT7ivQlwoqBiIZFWgGV4mCRaQj/kR 9xNz5J5owdsx4C3+f7s+h+/LFphoMxO+ADPUVIvvI8pGGDmotY/sgMdDsP0t3dMnpe DnQhz4sZU5k0Q== Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 20:58:06 -0000 On 5/1/13 2:26 PM, Gustavo García wrote: > RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which side is the DTLS server must be established via some out-of-band mechanism such as SDP." > > What is the specification on how to signal that in SDP? > > Specifically in case of 3pcc where both endpoints are SDP offerers which one should take the client and server roles for DTLS? Should we tie that role to ICE controlled/controlling roles or should we negotiate it in the SDP somehow? See RFC4145. From ggb@tokbox.com Wed May 1 14:11:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F264F21F9B20 for ; Wed, 1 May 2013 14:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA7hgJmrDfsN for ; Wed, 1 May 2013 14:10:54 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with SMTP id 1101221F9B34 for ; Wed, 1 May 2013 14:10:54 -0700 (PDT) Received: from mail-da0-f70.google.com ([209.85.210.70]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUYGE2dMPltMQ2+pfegS/KeRTkwPDAbST@postini.com; Wed, 01 May 2013 14:10:54 PDT Received: by mail-da0-f70.google.com with SMTP id i30so2222346dad.1 for ; Wed, 01 May 2013 14:10:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=xwfDdEuk6fJNv9jqUxOIWzw5STvCH8EOxx9UuV907WY=; b=YqIzw6sXk7D4gKb3TOxEe/6yKKo+LnYJ/zPpn6ossoV/3NlHfhARakHlZAxrfUmeRf g1SjwQCSDYxTVn8rGIfGj8u1hGGu3UNvrwRqR1S73G+/VVJ4oE3Piqv804BT0Cwn2LrX /xWO0Z4jDbhVb80lhG0MrcfodrhhHTrIk6Qo73Emm7Tgq1M9bivn/Rt++KFo9lpsdlSP Sz8wWtBwQKxsTLGCFd+M+Why6Kg8abJnstjXBgk3bGX64ImM4cv1LpGNZGuQlosaDDtV Z1m0ShdpKKco5JWPfp2tpQ30JHFVWIFDQZ62PgrKYNW4f7ddBz6udAlLXoz3IL6/ep2T qi9g== X-Received: by 10.68.20.74 with SMTP id l10mr5912273pbe.150.1367442649327; Wed, 01 May 2013 14:10:49 -0700 (PDT) X-Received: by 10.68.20.74 with SMTP id l10mr5912264pbe.150.1367442649272; Wed, 01 May 2013 14:10:49 -0700 (PDT) Received: from [192.168.10.114] (ginger.tokbox.com. [216.38.134.117]) by mx.google.com with ESMTPSA id ze11sm5045104pab.22.2013.05.01.14.10.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 14:10:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= In-Reply-To: <5181819B.5050107@alum.mit.edu> Date: Wed, 1 May 2013 14:10:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> References: <5181819B.5050107@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQngubhWJdBllJ1CRNxaLxTOQKclc4PYmeRlv3Yb7AwXTMoo1CHGlF7ANcE0PfhT/i4zkk8xQYQLHcIMzVJY/RzuvGZZItjshxLgR2GV72lQjxjRqw9Kafd4F3rDyYra3PzrUPjpUovI5bkeN9n8aalBplgkLw== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 21:11:04 -0000 I saw it, but that is all about TCP client/server role and not DTLS = client/server role. Are we supposed to use the same "setup" attribute = for dtls role negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm = misunderstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and = which side is the DTLS server must be established via some out-of-band = mechanism such as SDP." >>=20 >> What is the specification on how to signal that in SDP? >>=20 >> Specifically in case of 3pcc where both endpoints are SDP offerers = which one should take the client and server roles for DTLS? Should we = tie that role to ICE controlled/controlling roles or should we negotiate = it in the SDP somehow? >=20 > See RFC4145. >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From juberti@google.com Wed May 1 15:28:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4154621F8C38 for ; Wed, 1 May 2013 15:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsuaOo-zv+Lu for ; Wed, 1 May 2013 15:28:07 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F36EA21F9955 for ; Wed, 1 May 2013 15:26:58 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a11so2499596iee.34 for ; Wed, 01 May 2013 15:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=e8xHs03SWN42VJfhfJl8Gh29HXGkDkYrteT2GVpO+7w=; b=MYO0h52AUh6mfuKlvlQJQ7CoCrtGjMzHUCjLd9GPnKY4yiGzut+6ck1TN+kCrVWNEh slQxwKaTYMMMLH3lx8tTS/gV8AkMM3Z1JLNQLHhcNyr2yo+e8cSctrOKRzGYyqgY5SDf bCj9FWDv95R6lrC/XSSw1XsKvtldzF7isixJNSVDFAITkzx9I+n7AZZ6SsX0cS/w9P7X BqBm+RLucodPW+1bs6hPfYTuTMsikLyozRfD4UmVi2cnN+X13MK8/EKaAAj9S/1Inu0t qJ3M7vikF3TPYHfX1EouKezSsuaY4gvnqKDAfQ/0fT/aay5Ln85MKYVc/g3w1eDGr5kS F1bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=e8xHs03SWN42VJfhfJl8Gh29HXGkDkYrteT2GVpO+7w=; b=Yno0wxCR7ETP1uPgbHl7dVMioxu+VooxOjFmwWova+H0beQeHDCrKF7qPJ6KglNYkA 6/RerMSNsyHuk3GeRFNCUOrA6gsRM2NiWQJu92Cm09xvR+fzoM2ZGQPPqXlA8Hn5JLAj 9vbgVKGx20kmLe9a9gpPmfpo6FKNEgoYSD2fX+dh3HY/5NMqCyr5GYIrqy9I4+abEtd+ F2aYEdQZxFIH4RY39VJDlNpD7ISHGJ2/QdodEEGak/tOWvQ2DXq583n4b6z4y5tOhxrF PWHJI/JRni2vQNIQ9tEnayBqYIoR4fVspf3OQg0+Au52PJwkBI9/XrCC7KWkhZo7s8Pb eQ6Q== X-Received: by 10.50.32.4 with SMTP id e4mr13492338igi.95.1367447217991; Wed, 01 May 2013 15:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Wed, 1 May 2013 15:26:37 -0700 (PDT) In-Reply-To: <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> From: Justin Uberti Date: Wed, 1 May 2013 15:26:37 -0700 Message-ID: To: =?UTF-8?Q?Gustavo_Garc=C3=ADa?= Content-Type: multipart/alternative; boundary=e89a8f3ba56dad8a0b04dbaf9dab X-Gm-Message-State: ALoCoQl6KIGvtqpnHqec138kzS8/kH4uiyY5fOK1OAzZvsvLtqu8BbjaWlbE4lTWApyVt+PaaQ14EGDwHDjXKxAgG0ECEgIs/EG0JwIWN3hGkVwTv3C54yQn8F5Op5GXZylEJZM9ryAKmH/0DtJ7PG9+Zhd2MsGXPmLvbw5BuGI6irVTgmWE9xuAsOv3YHcyYlzZ4a4uzIgt Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 22:28:08 -0000 --e89a8f3ba56dad8a0b04dbaf9dab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think Paul means the active/passive attributes in RFC 5763, but I'm still not sure about how 3rd party call control would be handled in this case, i.e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=C3=ADa wrote: > I saw it, but that is all about TCP client/server role and not DTLS > client/server role. Are we supposed to use the same "setup" attribute f= or > dtls role negotiation even if it is over UDP? > > I think there is no reason to tie TCP and DTLS roles, but perhaps I'm > misunderstanding something. > > On 01/05/2013, at 13:56, Paul Kyzivat wrote: > > > On 5/1/13 2:26 PM, Gustavo Garc=C3=ADa wrote: > >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and > which side is the DTLS server must be established via some out-of-band > mechanism such as SDP." > >> > >> What is the specification on how to signal that in SDP? > >> > >> Specifically in case of 3pcc where both endpoints are SDP offerers > which one should take the client and server roles for DTLS? Should we > tie that role to ICE controlled/controlling roles or should we negotiate = it > in the SDP somehow? > > > > See RFC4145. > > > > _______________________________________________ > > 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 > --e89a8f3ba56dad8a0b04dbaf9dab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think Paul means the active/passive attributes in RFC 57= 63, but I'm still not sure about how 3rd party call control would be ha= ndled in this case, i.e. when both endpoints think they are offerers and se= t a=3Dsetup:actpass.

ICE has logic to determine roles in this scenario, as shows = in RFC 5245, B.11.=C2=A0


On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=C3=ADa = <g= gb@tokbox.com> wrote:
I saw it, but that is all about TCP client/s= erver role and not DTLS client/server role. =C2=A0 Are we supposed to use t= he same "setup" attribute for dtls role negotiation even if it is= over UDP?

I think there is no reason to tie TCP and DTLS roles, but perhaps I'm m= isunderstanding something.

On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> On 5/1/13 2:26 PM, Gustavo Garc=C3=ADa wrote:
>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS clien= t and which side is the DTLS server must be established via some out-of-ban= d mechanism such as SDP."
>>
>> What is the specification on how to signal that in SDP?
>>
>> Specifically in case of 3pcc where both endpoints are SDP offerers= which one should take the client and server roles for DTLS? =C2=A0 =C2=A0S= hould we tie that role to ICE controlled/controlling roles or should we neg= otiate it in the SDP somehow?
>
> See RFC4145.
>
> _______________________________________________
> 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

--e89a8f3ba56dad8a0b04dbaf9dab-- From juberti@google.com Wed May 1 15:29:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00F421F8B8F for ; Wed, 1 May 2013 15:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.069 X-Spam-Level: X-Spam-Status: No, score=-101.069 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5mzMOYJV35M for ; Wed, 1 May 2013 15:29:26 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2595221F986B for ; Wed, 1 May 2013 15:29:22 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c12so2520124ieb.3 for ; Wed, 01 May 2013 15:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gBhWNKKci5flG6QgjPlemXxuIBP1NsdC8tK4ebeh0kI=; b=e/UNX2l85r/FhV3xpDrNARwMIX1ycFM3Nj45DcySzQoP7LBnY1KNRzVsnEstPKz+iP zv94X6FwVoj2hWn8XMApP4TBN/VOBkl4u4W60sb21cqHZ3twc/Pz+wQo1+hccjK8z5Uh MtbLD6KZFzydrDYlGtSkWhSfCx79Rzg0HeDCPpRRttpfvWPGP9Gcp760EtFL8NQuYR9w 9q4ZAR4HEgMMgfwXSrh7rqF5O4T8+x8TJRn2zkNVhiaavBwgNhAmcdHcCUAqpUAWt4uB 4G7vZMGx3mjc0cKTup1tR+lm4wk/1X1rmzX6l+nBiHTayFJwv7ALuK7d6Ea75NVsMb4d S+BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=gBhWNKKci5flG6QgjPlemXxuIBP1NsdC8tK4ebeh0kI=; b=aJJe347k8+XG0WqdIYAVLsRG+CpTGZ1D2s+1Y205j67YCjqeY1n7KnT7BHeMPSDKym Kz9JKOQN4qniYfmAwNlccBkwrLpFqK9dtaNc1Z6Aj2mMbMejH9SE09fD0YAK2+PONtgh P3OR7rwgT7w9JedYebnYCgG4Kqbj9Krny9UaJUyTOTGMpl+R9H+XeKQDPQL8JZaiKj1R rBQ3qPG50fixAZifv8671uxwwdDitAaobHvIM6wCLsIk44iszLH8f9LCfdRdYZrvAHP3 Dk2UFRs18oXw/7yU3WwfNCJCiw5QXQJS2NcHutaM6LDq1pryUYTcmvb7CBgGNLiEL5eB ooHg== X-Received: by 10.50.18.74 with SMTP id u10mr2708271igd.42.1367447361754; Wed, 01 May 2013 15:29:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Wed, 1 May 2013 15:29:01 -0700 (PDT) In-Reply-To: <51801BBD.1010505@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> <517FFB7E.8050801@alum.mit.edu> <51801BBD.1010505@alum.mit.edu> From: Justin Uberti Date: Wed, 1 May 2013 15:29:01 -0700 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e014947363f359404dbafa6bb X-Gm-Message-State: ALoCoQlXZ17LIpyHXRouPYP5TiBlc96BtYvF5lPBi5GHn9LnsfpY9gkoQC7lT+GfyKi8MRjrU3Z68nHCQdHTEZZomdC4B4uBiOf0rmCpXLLuiP4EhSs41q1K/xhDmyvdVaMiskZOXIewNJXZZYfY5FgG996YxS9dtrJ/dIfBIyl6IVPtabGzzBgQkqzA9wTuJp9MRV2w1WdQ Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 22:29:26 -0000 --089e014947363f359404dbafa6bb Content-Type: text/plain; charset=UTF-8 +1 to mandating rtcp-mux when BUNDLEing. Otherwise, we have weird situations, such as if you try to BUNDLE a SCTP session and a non-RTCP-mux RTP session together; the former has 1 ICE component, the latter has 2. On Tue, Apr 30, 2013 at 12:30 PM, Paul Kyzivat wrote: > On 4/30/13 3:00 PM, Martin Thomson wrote: > >> On 30 April 2013 10:12, Paul Kyzivat wrote: >> >>> What are the implications of *not* mandating it? >>> >> >> I'm more interesting in learning why someone might want to split it >> out. I can't see any reason for doing that... >> >> ...that is, except perhaps for some of the fictitious attacks I invent >> when someone suggests that RTCP is a good place for a security >> mechanism of one sort or other. >> > > Well, IIUC it was separate before there was a way to combine them. > Why was that? Why hasn't separate RTCP gone away entirely? > > Thanks, > Paul > > ______________________________**_________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/**listinfo/mmusic > --089e014947363f359404dbafa6bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to mandating rtcp-mux when BUNDLEing.

Otherwise, we have weird situations, such as if you try to BUNDLE a SCTP = session and a non-RTCP-mux RTP session together; the former has 1 ICE compo= nent, the latter has 2.


On Tue,= Apr 30, 2013 at 12:30 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>= wrote:
On 4/30/13 3:00 PM, Martin= Thomson wrote:
On 30 April 2013 10:12, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
What are the implications of *not* mandating it?

I'm more interesting in learning why someone might want to split it
out. =C2=A0I can't see any reason for doing that...

...that is, except perhaps for some of the fictitious attacks I invent
when someone suggests that RTCP is a good place for a security
mechanism of one sort or other.

Well, IIUC it was separate before there was a way to combine them.
Why was that? Why hasn't separate RTCP gone away entirely?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul
_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic

--089e014947363f359404dbafa6bb-- From mzanaty@cisco.com Wed May 1 21:04:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAAC21F85CE for ; Wed, 1 May 2013 21:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GZTwrmMRXYd for ; Wed, 1 May 2013 21:04:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9A17A21F867B for ; Wed, 1 May 2013 21:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7267; q=dns/txt; s=iport; t=1367467448; x=1368677048; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4Pv/QGLaebriOssEbl9F/4MNBYY41kVzVP5qOsijqAE=; b=fFt6mYdOGJAd21RbQK7PkTcmmat/Ww9pq5dACBhfJgPrf5bLjLtzPr1F 5F+mPTAD69c5ccFQl7tXkP6kQPye4aLRKjL0Bp0413YrpDlRSbgBPMo7v bz4QBgAIojfNIrzGbUe0X1t2QFSuMZ0c/EY2GPXIwsb+BiAmR3gzZScXy 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAA7lgVGtJXG8/2dsb2JhbABSgwc3vyOBARZ0gh8BAQEDAQEBAWsLBQsCAQgOCh0KBycLFBECBA4FiAYGDL8kBI8eBAeCcWEDiF2OTJExgw0 X-IronPort-AV: E=Sophos;i="4.87,593,1363132800"; d="scan'208,217";a="205244460" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 02 May 2013 04:04:08 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r42448lZ015494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 04:04:08 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 1 May 2013 23:04:07 -0500 From: "Mo Zanaty (mzanaty)" To: Justin Uberti Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORq6jUvZFEriikUyEO6sxlAqo8pjxJyYAgAAVMYCAAAp7+g== Date: Thu, 2 May 2013 04:04:07 +0000 Message-ID: <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7984C671D3FF4CC3AC4A9965087DD07Eciscocom_" MIME-Version: 1.0 Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 04:04:19 -0000 --_000_7984C671D3FF4CC3AC4A9965087DD07Eciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 --_000_7984C671D3FF4CC3AC4A9965087DD07Eciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so= the other leg will answer with active or passive but not actpass.

A complex 3PCC/B2BUA delays offers toward both legs, so it must analyz= e and alter SDP in complex ways to generate two answers from two offers, pa= rt of which is deciding which answer should become active and which should = become passive.

The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs.

DTLS-SRTP is actually an easy case since RFC 5763 requires offers to b= e actpass. TCP is harder since RFC 4145 allows offers to be active, passive= , or actpass, causing more complex reinvites to resolve active/active or pa= ssive/passive conflicts.

Mo


On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> wrote:

I think Paul means the active/passive attributes in RFC 57= 63, but I'm still not sure about how 3rd party call control would be handle= d in this case, i.e. when both endpoints think they are offerers and set a= =3Dsetup:actpass.

ICE has logic to determine roles in this scenario, as shows in RFC 524= 5, B.11. 


On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa= <ggb@tokbox.com&= gt; wrote:
I saw it, but that is all about TCP client/server role and not DTLS client/= server role.   Are we supposed to use the same "setup" attri= bute for dtls role negotiation even if it is over UDP?

I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something.

On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote:
>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS clien= t and which side is the DTLS server must be established via some out-of-ban= d mechanism such as SDP."
>>
>> What is the specification on how to signal that in SDP?
>>
>> Specifically in case of 3pcc where both endpoints are SDP offerers= which one should take the client and server roles for DTLS?    S= hould we tie that role to ICE controlled/controlling roles or should we neg= otiate it in the SDP somehow?
>
> See RFC4145.
>
> _______________________________________________
> 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
--_000_7984C671D3FF4CC3AC4A9965087DD07Eciscocom_-- From albrecht.schwarz@alcatel-lucent.com Thu May 2 00:15:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECC621F988D for ; Thu, 2 May 2013 00:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ4k+JerFDo8 for ; Thu, 2 May 2013 00:15:17 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4C21F9800 for ; Thu, 2 May 2013 00:15:16 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r427FCh2013179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 May 2013 02:15:12 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r427FA2B026237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 03:15:11 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 2 May 2013 03:15:11 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 2 May 2013 09:15:02 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "Mo Zanaty (mzanaty)" , Justin Uberti Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpl/XH1yp96NPUWvLDnzWSG5+pjwrh2AgAAD2gCAABUxgIAAXkyAgABRLxA= Date: Thu, 2 May 2013 07:15:02 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>, <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> In-Reply-To: <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC0305AAFR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 07:15:23 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC0305AAFR711WXCHMBA03zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The RFC situation is not really clear, even confusing concerning client/ser= ver role negotiations (in case of transport security sessions over connecti= on-oriented IP transport protocols). =B7 RFC 4145 is only about TCP, i.e., TCP client/server role assign= ments. Thus, the RFC 4145 introduced SDP attribute is TCP specific. =B7 draft-ietf-mmusic-sctp-sdp: seems to profile the "a=3Dsetup:" a= ttribute for SCTP path establishment directions ... (?) =B7 RFC 5763 uses the TCP SDP attribute for DTLS session establishm= ent, i.e. DTLS client/server role assignments; that's actually a semantical= change of this SDP element vs RFC 4145 ... and DTLS is TLS based, leading to the question of role/assignments in c= ase of TLS/TCP sessions? I.e., the TCP client/server and also TLS client/server roles? Keeping in mi= nd that the role assignments at IP transport layer and security session lay= er may principally be different! The "a=3Dsetup" definition by RFC 4145 is unfortunate in my opinion. Required seems to be a generic SDP specification (i.e., outside RFC 4145), = which may be then tight to the concerned protocol. Sth like an explicit ind= ication "a=3Dsetup:PROTOCOL:" or an implicit indication by adding an identi= fier. The "m=3D" line element does not really help to reduce ambiguity (a= s Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "= transport". The proto field identifies a whole stack of protocol layers."). Albrecht PS I would see following parameter values for a SDP "a=3Dsetup:PROTOCOL:" attr= ibute extension: L4: TCP, SCTP, DCCP(?) L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling ...) From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Mo Zanaty (mzanaty) Sent: Donnerstag, 2. Mai 2013 06:04 To: Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 --_000_786615F3A85DF44AA2A76164A71FE1AC0305AAFR711WXCHMBA03zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The RFC situation is not real= ly clear, even confusing concerning client/server role negotiations (in cas= e of transport security sessions over connection-oriented IP transport protocols).

 

=B7    =      RFC 4145 is only abou= t TCP, i.e., TCP client/server role assignments. Thus, the RFC 4145 introdu= ced SDP attribute is TCP specific.

=B7    =      draft-ietf-mmusic-sct= p-sdp: seems to profile the “a=3Dsetup:” attribute for SCTP pat= h establishment directions … (?)

=B7    =      RFC 5763 uses the TCP= SDP attribute for DTLS session establishment, i.e. DTLS client/server role= assignments; that’s actually a semantical change of this SDP element vs RFC 4145

 

… and DTLS is TLS based= , leading to the question of role/assignments in case of TLS/TCP sessions?<= o:p>

I.e., the TCP client/server a= nd also TLS client/server roles? Keeping in mind that the role assignments = at IP transport layer and security session layer may principally be different!

 

The “a=3Dsetup” d= efinition by RFC 4145 is unfortunate in my opinion.

Required seems to be a generi= c SDP specification (i.e., outside RFC 4145), which may be then tight to th= e concerned protocol. Sth like an explicit indication “a=3Dsetup:PROTOCOL:” or an implicit indication by adding an i= dentifier.

 

The “m=3D” lin= e <proto> element does not really help to reduce ambiguity (as Paul r= eminded again: ““Unfortunately SDP has a pretty confusing idea of "transport". The proto field = identifies a whole stack of protocol layers.&= #8221;).

 

Albrecht

PS

I would see following paramet= er values for a SDP “a=3Dsetup:PROTOCOL:” attribute extension:<= o:p>

L4: TCP, SCTP, DCCP(?)

L4+: TLS, DTLS, DTLS-SRTP= (?, due to RFC 5764 SDP profiling …)

 

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.o= rg] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

A simple 3PCC/B2BUA only delays offers toward one le= g like RFC3725, so the other leg will answer with active or passive but not= actpass.

 

A complex 3PCC/B2BUA delays offers toward both legs,= so it must analyze and alter SDP in complex ways to generate two answers f= rom two offers, part of which is deciding which answer should become active= and which should become passive.

 

The flow in RFC 5245 B.11 is oversimplified. SDP can= 't be forwarded unaltered by a B2BUA which delays offers on both legs. Gene= rating two answers from two offers is much more complex than simply forward= ing the offers as answers.

 

DTLS-SRTP is actually an easy case since RFC 5763 re= quires offers to be actpass. TCP is harder since RFC 4145 allows offers to = be active, passive, or actpass, causing more complex reinvites to resolve a= ctive/active or passive/passive conflicts.

 

Mo



On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> wrote:

I think Paul means the active/passive attributes in = RFC 5763, but I'm still not sure about how 3rd party call control would be = handled in this case, i.e. when both endpoints think they are offerers and = set a=3Dsetup:actpass.

 

ICE has logic to determine roles in this scenario, a= s shows in RFC 5245, B.11. 

 

On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa <= ;ggb@tokbox.com>= wrote:

I saw it, but that is all about TCP client/server ro= le and not DTLS client/server role.   Are we supposed to use the same = "setup" attribute for dtls role negotiation even if it is over UD= P?

I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something.


On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote:
>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS clien= t and which side is the DTLS server must be established via some out-of-ban= d mechanism such as SDP."
>>
>> What is the specification on how to signal that in SDP?
>>
>> Specifically in case of 3pcc where both endpoints are SDP offerers= which one should take the client and server roles for DTLS?    S= hould we tie that role to ICE controlled/controlling roles or should we neg= otiate it in the SDP somehow?
>
> See RFC4145.
>
> _______________________________________________
> 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.o= rg/mailman/listinfo/mmusic

--_000_786615F3A85DF44AA2A76164A71FE1AC0305AAFR711WXCHMBA03zeu_-- From prvs=3834f4ee55=christer.holmberg@ericsson.com Thu May 2 03:01:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF1321F993C for ; Thu, 2 May 2013 03:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78sbnHG92asW for ; Thu, 2 May 2013 03:00:57 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 60B6821F8605 for ; Thu, 2 May 2013 03:00:56 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-9e-5182395700d2 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A9.3A.32006.75932815; Thu, 2 May 2013 12:00:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Thu, 2 May 2013 12:00:54 +0200 From: Christer Holmberg To: Justin Uberti , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? Thread-Index: Ac5FpkrHryzI/aQNT0iUvXy00zH5hwADtcYAAAPFvoAAAQhZgAA4imSAABwqMXA= Date: Thu, 2 May 2013 10:00:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> <517FFB7E.8050801@alum.mit.edu> <51801BBD.1010505@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C369709ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+JvrW64ZVOgwdKDwhZbpwpZTF3+mMVi xYYDrA7MHn/ff2DyWLCp1GPJkp9MAcxR3DZJiSVlwZnpefp2CdwZO1o/shU0xVbcPnKOrYFx T1QXIyeHhICJxPPmx0wQtpjEhXvr2boYuTiEBA4zSuzf2skKkhASWMwoMaUDyObgYBOwkOj+ pw1iigj4SPz7IAxiMguoS1xdHARSLCxgI9G0YycziC0iYCsx5d4NdgjbT+L8vE6wTSwCKhKb Tzewgdi8Ar4SH3a8Z4HYOp9J4s72n2ANnAKBEtMaP7OA2IxAp30/tQasmVlAXOLWk/lQJwtI LNlznhnCFpV4+fgfK4StKHF1+nKo+nyJy7vOMkMsE5Q4OfMJywRG0VlIRs1CUjYLSdkssNc0 Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRvbcxMyc9HKjTYzA+Dq45bfqDsY750QOMUpz sCiJ8yZzNQYKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFINjHYGS2qaXSZ18c03U5rKIezf tslBQCD3xD7ZTq+PBWFi+2eFhIccv1e7ZNmVVcvi2XaG7P1yvJaB39CtbXa21qffGvz7BBR9 ec75byvf42i28YjrZKmrf558ui8bFFu1zuHNz0PPTjJzeKUobpd4vTr9xM9gXmf+8wZFcgaf fvbJvGxS7++uUGIpzkg01GIuKk4EADhmLtGCAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 10:01:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C369709ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoaW5ncyB3b3VsZCBjZXJ0YWlubHkgd29yayB3aXRoIHNlcGFyYXRlIFJUQ1AgcG9y dHMuIEJ1dCwgaXQgd291bGQgbWVhbiBhbiBhZGRpdGlvbmFsIDUtdHVwbGUsIHdpdGggYXNzb2Np YXRlZCBJQ0UgZXRjLCB3aGljaCBpcyB3aGF0IHdlIHdhbnQgdG8gYXZvaWQgYnkgdXNpbmcgQlVO RExFLg0KDQpBbmQsIGFzIEJVTkRMRSBhbHJlYWR5IG1hbmRhdGVzIHRoZSBTRFAgb2ZmZXJlciB0 byBvZmZlciBydGNwLW11eCwgbXkgc3VnZ2VzdGlvbiBpcyB0byBtYW5kYXRlIHRoZSBTRFAgYW5z d2VyZXIgdG8gYWNjZXB0IGl0IChhc3N1bWluZyBpdCBlbmFibGVzIEJVTkRMRSwgdGhhdCBpcyku DQoNCkhvd2V2ZXIsIGlmIHBlb3BsZSBoYXZlIGlzc3VlcyB3aXRoIGEgTVVTVCwgYSBjb21wcm9t aXNlIHdvdWxkIGJlIOKAnFNIT1VMRCwgdW5sZXNzIHNvbWUgbWVjaGFuaXNtIGV4cGxpY2l0bHkg cmVxdWlyZXMgdGhlIHVzYWdlIG9mIHNlcGFyYXRlIFJUQ1AgcG9ydHPigJ3igKYgb3Igc29tZXRo aW5nIGxpa2UgdGhhdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogbW11c2ljLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IDIuIHRvdWtva3V1dGEgMjAxMyAxOjI5DQpUbzogUGF1 bCBLeXppdmF0DQpDYzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gQlVO RExFOiBtYW5kYXRlIFJUUC9SVENQIG11bHRpcGxleGluZz8NCg0KKzEgdG8gbWFuZGF0aW5nIHJ0 Y3AtbXV4IHdoZW4gQlVORExFaW5nLg0KDQpPdGhlcndpc2UsIHdlIGhhdmUgd2VpcmQgc2l0dWF0 aW9ucywgc3VjaCBhcyBpZiB5b3UgdHJ5IHRvIEJVTkRMRSBhIFNDVFAgc2Vzc2lvbiBhbmQgYSBu b24tUlRDUC1tdXggUlRQIHNlc3Npb24gdG9nZXRoZXI7IHRoZSBmb3JtZXIgaGFzIDEgSUNFIGNv bXBvbmVudCwgdGhlIGxhdHRlciBoYXMgMi4NCg0KT24gVHVlLCBBcHIgMzAsIDIwMTMgYXQgMTI6 MzAgUE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PG1haWx0bzpwa3l6aXZh dEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCk9uIDQvMzAvMTMgMzowMCBQTSwgTWFydGluIFRob21z b24gd3JvdGU6DQpPbiAzMCBBcHJpbCAyMDEzIDEwOjEyLCBQYXVsIEt5eml2YXQgPHBreXppdmF0 QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQpXaGF0 IGFyZSB0aGUgaW1wbGljYXRpb25zIG9mICpub3QqIG1hbmRhdGluZyBpdD8NCg0KSSdtIG1vcmUg aW50ZXJlc3RpbmcgaW4gbGVhcm5pbmcgd2h5IHNvbWVvbmUgbWlnaHQgd2FudCB0byBzcGxpdCBp dA0Kb3V0LiAgSSBjYW4ndCBzZWUgYW55IHJlYXNvbiBmb3IgZG9pbmcgdGhhdC4uLg0KDQouLi50 aGF0IGlzLCBleGNlcHQgcGVyaGFwcyBmb3Igc29tZSBvZiB0aGUgZmljdGl0aW91cyBhdHRhY2tz IEkgaW52ZW50DQp3aGVuIHNvbWVvbmUgc3VnZ2VzdHMgdGhhdCBSVENQIGlzIGEgZ29vZCBwbGFj ZSBmb3IgYSBzZWN1cml0eQ0KbWVjaGFuaXNtIG9mIG9uZSBzb3J0IG9yIG90aGVyLg0KDQpXZWxs LCBJSVVDIGl0IHdhcyBzZXBhcmF0ZSBiZWZvcmUgdGhlcmUgd2FzIGEgd2F5IHRvIGNvbWJpbmUg dGhlbS4NCldoeSB3YXMgdGhhdD8gV2h5IGhhc24ndCBzZXBhcmF0ZSBSVENQIGdvbmUgYXdheSBl bnRpcmVseT8NCg0KICAgICAgICBUaGFua3MsDQogICAgICAgIFBhdWwNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QN Cm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B1C369709ESESSMB209erics_ 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+VGhpbmdzIHdvdWxkIGNlcnRhaW5seSB3b3JrIHdpdGggc2VwYXJhdGUgUlRDUCBwb3J0 cy4gQnV0LCBpdCB3b3VsZCBtZWFuIGFuIGFkZGl0aW9uYWwgNS10dXBsZSwgd2l0aCBhc3NvY2lh dGVkIElDRSBldGMsIHdoaWNoIGlzIHdoYXQgd2Ugd2FudCB0byBhdm9pZCBieSB1c2luZw0KIEJV TkRMRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFuZCwgYXMgQlVORExFIGFscmVhZHkgbWFuZGF0ZXMgdGhlIFNEUCBv ZmZlcmVyIHRvIG9mZmVyIHJ0Y3AtbXV4LCBteSBzdWdnZXN0aW9uIGlzIHRvIG1hbmRhdGUgdGhl IFNEUCBhbnN3ZXJlciB0byBhY2NlcHQgaXQgKGFzc3VtaW5nIGl0IGVuYWJsZXMgQlVORExFLCB0 aGF0DQogaXMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgaWYgcGVvcGxlIGhhdmUgaXNzdWVzIHdpdGgg YSBNVVNULCBhIGNvbXByb21pc2Ugd291bGQgYmUg4oCcU0hPVUxELCB1bmxlc3Mgc29tZSBtZWNo YW5pc20gZXhwbGljaXRseSByZXF1aXJlcyB0aGUgdXNhZ2Ugb2Ygc2VwYXJhdGUgUlRDUCBwb3J0 c+KAneKApiBvciBzb21ldGhpbmcNCiBsaWtlIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5TZW50OjwvYj4gMi4g dG91a29rdXV0YSAyMDEzIDE6Mjk8YnI+DQo8Yj5Ubzo8L2I+IFBhdWwgS3l6aXZhdDxicj4NCjxi PkNjOjwvYj4gbW11c2ljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lD XSBCVU5ETEU6IG1hbmRhdGUgUlRQL1JUQ1AgbXVsdGlwbGV4aW5nPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0byBtYW5kYXRpbmcgcnRjcC1tdXggd2hlbiBC VU5ETEVpbmcuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P dGhlcndpc2UsIHdlIGhhdmUgd2VpcmQgc2l0dWF0aW9ucywgc3VjaCBhcyBpZiB5b3UgdHJ5IHRv IEJVTkRMRSBhIFNDVFAgc2Vzc2lvbiBhbmQgYSBub24tUlRDUC1tdXggUlRQIHNlc3Npb24gdG9n ZXRoZXI7IHRoZSBmb3JtZXIgaGFzIDEgSUNFIGNvbXBvbmVudCwgdGhlIGxhdHRlciBoYXMgMi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEFwciAzMCwgMjAxMyBhdCAxMjozMCBQ TSwgUGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1 IiB0YXJnZXQ9Il9ibGFuayI+cGt5eml2YXRAYWx1bS5taXQuZWR1PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNC8zMC8xMyAzOjAw IFBNLCBNYXJ0aW4gVGhvbXNvbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDMwIEFwcmlsIDIwMTMgMTA6MTIsIFBhdWwgS3l6aXZhdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnBreXppdmF0QGFs dW0ubWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2hhdCBhcmUgdGhlIGltcGxpY2F0aW9ucyBvZiAqbm90KiBtYW5kYXRpbmcgaXQ/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJJ20gbW9yZSBpbnRlcmVz dGluZyBpbiBsZWFybmluZyB3aHkgc29tZW9uZSBtaWdodCB3YW50IHRvIHNwbGl0IGl0PGJyPg0K b3V0LiAmbmJzcDtJIGNhbid0IHNlZSBhbnkgcmVhc29uIGZvciBkb2luZyB0aGF0Li4uPGJyPg0K PGJyPg0KLi4udGhhdCBpcywgZXhjZXB0IHBlcmhhcHMgZm9yIHNvbWUgb2YgdGhlIGZpY3RpdGlv dXMgYXR0YWNrcyBJIGludmVudDxicj4NCndoZW4gc29tZW9uZSBzdWdnZXN0cyB0aGF0IFJUQ1Ag aXMgYSBnb29kIHBsYWNlIGZvciBhIHNlY3VyaXR5PGJyPg0KbWVjaGFuaXNtIG9mIG9uZSBzb3J0 IG9yIG90aGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlbGwsIElJVUMgaXQg d2FzIHNlcGFyYXRlIGJlZm9yZSB0aGVyZSB3YXMgYSB3YXkgdG8gY29tYmluZSB0aGVtLjxicj4N CldoeSB3YXMgdGhhdD8gV2h5IGhhc24ndCBzZXBhcmF0ZSBSVENQIGdvbmUgYXdheSBlbnRpcmVs eT88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYXVsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1C369709ESESSMB209erics_-- From prvs=4834b6ea25=christer.holmberg@ericsson.com Thu May 2 03:14:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5C21F9988 for ; Thu, 2 May 2013 03:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vunlyavpnzkb for ; Thu, 2 May 2013 03:14:51 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B888A21F8930 for ; Thu, 2 May 2013 03:14:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-a0-51823c99127c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6C.FB.32006.99C32815; Thu, 2 May 2013 12:14:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Thu, 2 May 2013 12:14:49 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] 10 BUNDLE questions: Same SDES key for multiple m- lines? Thread-Index: Ac5Fm5YzG97WvrBuR0q4LrredSKh4QAJysmAAFamXCA= Date: Thu, 2 May 2013 10:14:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369768@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C368D88@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.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+Jvre5Mm6ZAgyWTLSyunfnHaDF1+WMW ByaPnbPusnssWfKTKYApitsmKbGkLDgzPU/fLoE7Y9+NBWwF6wQqji1qZ25g/MHfxcjJISFg InHofCMThC0mceHeerYuRi4OIYHDjBIz2r4yQjiLGSWez1rB3sXIwcEmYCHR/U8bpEFEQFdi 0dkHYGFmAXWJq4uDQMLCAoESb6dtYoQoCZJYMmMWlG0lseR6CwtIOYuAisSmVSkgYV4BX4n9 2z+yQ2yawihxr+0JC0iCE2hOa88uZhCbEei276fWgN3JLCAucevJfKibBSSW7DnPDGGLSrx8 /I8VwlaUuDp9ORPEaZoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGMVmIZk6C6FjFpKOWUg6FjCy rGJkz03MzEkvN9rECIyPg1t+q+5gvHNO5BCjNAeLkjhvMldjoJBAemJJanZqakFqUXxRaU5q 8SFGJg5OEMEl1cDY4PWB9cTFYo8t3/ZffHY5z5Gr9PdZn96LX/r4g7imPfqqFZtddXYx0/kY m5yQdav+7tqjY11pKXUn+KxH/kmr/U826jD90HiRdGZe1O9w6ZLMv+1xNU27vj686lQl1C56 wU0n1Pbs2SN7Gc9+8N6SMveZzUcj14lbJV9/rFnJ/Jbx3Eul+hOXlViKMxINtZiLihMB9gfK tGICAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions: Same SDES key for multiple m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 10:14:57 -0000 SGksDQoNCj4+IFJlZ2FyZGluZyB1c2luZyB0aGUgc2FtZSBTREVTIGtleSwgaXQgaXMgaW1wb3J0 YW50IHRvIHJlbWVtYmVyIHRoYXQsIGlmIHRoZXJlIGlzIGEgZmFsbGJhY2sgKGllIHRoZSByZW1v dGUgZW5kcG9pbnQgDQo+PiBkb2VzIG5vdCBzdXBwb3J0IEJVTkRMRSwgYW5kIHRoZSBTRFAgYW5z d2VyIHdpbGwgY29udGFpbiBkaWZmZXJlbnQgcG9ydHMpLCB0aGVyZSB3aWxsIGJlIGRpZmZlcmVu dCBSVFAgc2Vzc2lvbnMsIGluIA0KPj4gd2hpY2ggY2FzZSB0d28tdGltZSBwYWQgYmVjb21lcyBh biBpc3N1ZS4NCj4NCj4gWWVzLCBJIGhhZG4ndCBjb25zaWRlcmVkIHRoYXQsIGJ1dCBpdCdzIGFu b3RoZXIgcmVhc29uIHRvIGhhdmUgZGlmZmVyZW50IGtleXMgOikgIFNpbmNlIHRoaXMgaXMgb25s eSB0aGUgYnVuZGxpbmcgc2lkZSB0aGF0IGlzIA0KPiBhZmZlY3RlZCwgdGhpcyBjYW4gYmUgYWRk cmVzc2VkIHdpdGggYSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBub3RlIHRvIHRoZSBlZmZlY3Qg dGhhdCB0aGUgYnVuZGxlciwgd2hvIGhhcyBjaG9zZW4gdG8gdXNlIA0KPiB0aGUgc2FtZSBrZXkg YWNyb3NzIG09IGxpbmVzLCBNVVNUIE5PVCBzZWxlY3QgdGhlIHNhbWUgU1NSQyBmb3IgdGhvc2Ug c2Vzc2lvbnMuICBJIHRoaW5rIHRoYXQncyBhbiBlYXN5IHRoaW5nIHRvIGRvLg0KPg0KPiBTdGls bCwgZXZlbiB3aXRob3V0IHNwZWNpYWwgbWVhc3VyZXMgY2hhbmNlcyBhcmUgdGhhdCB5b3Ugd29u dCBwaWNrIGNvbGxpZGluZyBTU1JDcy4gIFRob3VnaCB0aGUgb2RkcyBhcmUgbm90IHJlYWxseSBp biB5b3VyIA0KPiBmYXZvciBnaXZlbiB0aGUgc2l6ZSBvZiB0aGUgc3BhY2UgeW91IGNob3NlIGZy b207IGl0IGRvZXNuJ3QgdGFrZSBtYW55IHNlc3Npb25zIGJlZm9yZSBpdCBoYXBwZW5zIHRvIHNv bWVvbmUuDQo+DQo+PiBTbywgb25lIHdheSBmb3J3YXJkIHdvdWxkIGJlOg0KPj4NCj4+IDEuIElu IHRoZSBmaXJzdCBvZmZlciwgd2hlbiBpdCBpcyBzdGlsbCB1bmtub3duIHdoZXRoZXIgdGhlIHJl bW90ZSBlbmRwb2ludCBzdXBwb3J0cyBCVU5ETEUsIHVzZSBkaWZmZXJlbnQgU0RFUyBrZXlzLg0K Pj4NCj4+IDIuIEluIHRoZSBzZWNvbmQgb2ZmZXIsIGlmIHRoZSByZW1vdGUgZW5kcG9pbnQgaW5k aWNhdGVkIHN1cHBvcnQgb2YgQlVORExFLCBhbGxvdyBzd2l0Y2hpbmcgdG8gYSBzaW5nbGUgU0RF UyBrZXkuDQo+DQo+IFRoYXQgd291bGQgYmUgcmVhc29uYWJsZSB0b28uICBJIHByb2JhYmx5IHdv dWxkbid0IGJvdGhlciB3aXRoIHRoZSBjaGFuZ2UgaW4gcHJhY3RpY2UgKHNlZSBhYm92ZSksIGJ1 dCBNQVkgPT0gZ29vZC4NCg0KU291bmRzIGdvb2QgdG8gbWUuDQoNCihBZnRlciBhbGwsIG9uY2Ug eW91IGtub3cgdGhhdCB5b3UgYXJlIG9ubHkgZ29pbmcgdG8gaGF2ZSBhIHNpbmdsZSBSVFAgc2Vz c2lvbiwgaXQgZG9lc24ndCByZWFsbHkgbWF0dGVyIGlmIHlvdSB1c2UgYSBzaW5nbGUgb3IgZGlm ZmVyZW50IFNERVMga2V5cy4pDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K From prvs=7834fac474=christer.holmberg@ericsson.com Thu May 2 05:55:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7C21F84B5 for ; Thu, 2 May 2013 05:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHZs8waRJAT2 for ; Thu, 2 May 2013 05:55:17 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0240C21F96BD for ; Thu, 2 May 2013 05:55:15 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-73-518262320577 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 51.51.28165.23262815; Thu, 2 May 2013 14:55:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Thu, 2 May 2013 14:55:14 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE and ZERO PORT VALUE Thread-Index: Ac5HLpsHDAej8eBpR9CrVaLIOw2gaQ== Date: Thu, 2 May 2013 12:55:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369973@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C369973ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvra5RUlOgwcMJVhZTlz9mcWD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8a9Y8/YCyb5VrRN/MrUwPjesYuRk0NCwESiYV87O4QtJnHh 3no2EFtI4DCjxKN5Jl2MXED2YkaJgz8nsXQxcnCwCVhIdP/TBqkREVCX+Lq3hxnEFhZQlvhx /wY7RFxDYu7ht4wQtp7EvGVzWUFsFgEViVezn4PV8Ar4SlyZcI8JxGYE2vv91Bowm1lAXOLW k/lMEPcISCzZc54ZwhaVePn4HyuErShxdfpyJpBzmAXyJb7OZYEYKShxcuYTlgmMQrOQTJqF UDULSRVEiY7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipE9NzEzJ73ccBMjMOQPbvmtu4Px 1DmRQ4zSHCxK4rxJXI2BQgLpiSWp2ampBalF8UWlOanFhxiZODhBBJdUA2MNt1rqk+PdhecK kxcY9/E7e54If3p/2p/TJspCEwTVxfN3dtc/N2LO/yPhcdH6dG35oxj/1RN8X23by6y40fDL 1fSiVKYLLf/qHSfITpZ/7h3lZl/+qf67dcayRyc0dZ+8/Pb77g3Za7k7Z32v2cyyPEjVaLL9 RC7OwjlOPNurdZj2Htt3NlKJpTgj0VCLuag4EQBSK0qJTAIAAA== Subject: [MMUSIC] BUNDLE and ZERO PORT VALUE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 12:55:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C369973ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One of the open issues is the usage of m- lines with port value zero within= a BUNDLE group. As Paul has indicated, RFC 5888 does not currently allow it. One suggestion has been to update RFC 5888. But, before we go down that pat= h, I think we need to see whether NOT allowing zero port m- lines in BUNDLE= groups would work. So, how would it impact BUNDLE? Zero port value in answer: If an m- line in the offer contains a non-zero port value, but the associat= ed m- line in the answer contains a zero port value (read: the answerer rej= ected the offered media associated with the m- line), the number of m- line= s associated with the BUNDLE group would differ in the offer and answer. As the media is rejected, no matter whether it would be part of a BUNDLE gr= oup or not, I can't think of any issues. Zero port value in offer: If an m- line in the offer contains a zero port value, the associated m- li= ne in the answer MUST also contain a zero port value. If the m- line has previously been part of a BUNDLE group, with a non-zero = port value, it means that the number of m- lines in the BUNDLE group will b= e reduced. But, again, as the media is rejected, no matter whether it would= be part of a BUNDLE group or not, I can't think of any issues. Then, if one later wants assign a non-zero value to the m- line, and insert= it into a BUNDLE group, the number of m- lines in the BUNDLE group would i= ncrease. I don't see any issues as such with that. One question, however, i= s whether the answerer is allowed to accept the m- line, but reject it bein= g part of a BUNDLE group. But, let's discuss that in a separate thread. SUGGESTION: My suggestion is that we do NOT allow m- lines with zero port value in a BU= NDLE group. Please indicate whether you are aware of restrictions, or probl= ems, that this would bring, and we will document those. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C369973ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One of the open issues is the usage of m- lines with= port value zero within a BUNDLE group.

 

As Paul has indicated, RFC 5888 does not currently a= llow it.

 

One suggestion has been to update RFC 5888. But, bef= ore we go down that path, I think we need to see whether NOT allowing zero = port m- lines in BUNDLE groups would work.

 

 

 

So, how would it impact BUNDLE?

 

Zero port value in answer:

 

If an m- line in the offer contains a non-zero port = value, but the associated m- line in the answer contains a zero port value = (read: the answerer rejected the offered media associated with the m- line)= , the number of m- lines associated with the BUNDLE group would differ in the offer and answer.

 

As the media is rejected, no matter whether it would= be part of a BUNDLE group or not, I can’t think of any issues.<= /o:p>

 

 

Zero port value in offer:

 

If an m- line in the offer contains a zero port valu= e, the associated m- line in the answer MUST also contain a zero port value= .

 

If the m- line has previously been part of a BUNDLE = group, with a non-zero port value, it means that the number of m- lines in = the BUNDLE group will be reduced. But, again, as the media is rejected, no = matter whether it would be part of a BUNDLE group or not, I can’t think of any issues.

 

Then, if one later wants assign a non-zero value to = the m- line, and insert it into a BUNDLE group, the number of m- lines in t= he BUNDLE group would increase. I don’t see any issues as such with t= hat. One question, however, is whether the answerer is allowed to accept the m- line, but reject it being part of a B= UNDLE group. But, let’s discuss that in a separate thread.=

 

 

SUGGESTION:

 

My suggestion is that we do NOT allow m- lines with = zero port value in a BUNDLE group. Please indicate whether you are aware of= restrictions, or problems, that this would bring, and we will document tho= se.

 

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C369973ESESSMB209erics_-- From mzanaty@cisco.com Thu May 2 05:55:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3AF21F8673 for ; Thu, 2 May 2013 05:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiumTqJNcl8B for ; Thu, 2 May 2013 05:55:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8968821F976F for ; Thu, 2 May 2013 05:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9882; q=dns/txt; s=iport; t=1367499330; x=1368708930; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0rhOKUIMecA+ltn66picAJn8/T4ulS4JLHIqGXOI2LI=; b=Zs/8k2Go2hnaiHjpQvPWPh3fmaEPccVW9HrGCmJUjw1FB7d15wM9IHqr H3NLopPS1yBzrro/NniFmEhaztwqv08SRXE4iEOtA45jUy3VZ7Cct+BLx qtBfjuN+cRtPEPfQk8euaEP42cgPm7f8ej/d8Yd3GKh19D+keg3Pf9tr7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAOtgglGtJV2a/2dsb2JhbABSgkNEN78fgQIWdIIfAQEBBAEBASpAAQsQAgEIEQQBASgHJwsUCQgCBA4FiAwMwFkEjx4EBgGCcWEDlymRMYMN X-IronPort-AV: E=Sophos;i="4.87,595,1363132800"; d="scan'208,217";a="205609725" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 02 May 2013 12:55:29 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r42CtS0k010370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 12:55:28 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 2 May 2013 07:55:28 -0500 From: "Mo Zanaty (mzanaty)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? Thread-Index: Ac5FpkrHryzI/aQNT0iUvXy00zH5hwADtcYAAAPFvoAAAQhZgAA4imSAABwqMXAABklLyA== Date: Thu, 2 May 2013 12:55:27 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> <517FFB7E.8050801@alum.mit.edu> <51801BBD.1010505@alum.mit.edu> , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CE0F590AD94847029082FDE0DCBFB698ciscocom_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 12:55:39 -0000 --_000_CE0F590AD94847029082FDE0DCBFB698ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 for MUST in offer and answer. On May 2, 2013, at 6:01 AM, "Christer Holmberg" > wrote: Hi, Things would certainly work with separate RTCP ports. But, it would mean an= additional 5-tuple, with associated ICE etc, which is what we want to avoi= d by using BUNDLE. And, as BUNDLE already mandates the SDP offerer to offer rtcp-mux, my sugge= stion is to mandate the SDP answerer to accept it (assuming it enables BUND= LE, that is). However, if people have issues with a MUST, a compromise would be =93SHOULD= , unless some mechanism explicitly requires the usage of separate RTCP port= s=94=85 or something like that. Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 2. toukokuuta 2013 1:29 To: Paul Kyzivat Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? +1 to mandating rtcp-mux when BUNDLEing. Otherwise, we have weird situations, such as if you try to BUNDLE a SCTP se= ssion and a non-RTCP-mux RTP session together; the former has 1 ICE compone= nt, the latter has 2. On Tue, Apr 30, 2013 at 12:30 PM, Paul Kyzivat > wrote: On 4/30/13 3:00 PM, Martin Thomson wrote: On 30 April 2013 10:12, Paul Kyzivat > wrote: What are the implications of *not* mandating it? I'm more interesting in learning why someone might want to split it out. I can't see any reason for doing that... ...that is, except perhaps for some of the fictitious attacks I invent when someone suggests that RTCP is a good place for a security mechanism of one sort or other. Well, IIUC it was separate before there was a way to combine them. Why was that? Why hasn't separate RTCP gone away entirely? Thanks, Paul _______________________________________________ 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_CE0F590AD94847029082FDE0DCBFB698ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1 for MUST in offer and answer.


On May 2, 2013, at 6:01 AM, "Christer Holmberg" <christer.holmberg@ericsson.com>= wrote:

Hi,

 <= /p>

Things would certainly wo= rk with separate RTCP ports. But, it would mean an additional 5-tuple, with= associated ICE etc, which is what we want to avoid by using BUNDLE.

 <= /p>

And, as BUNDLE already ma= ndates the SDP offerer to offer rtcp-mux, my suggestion is to mandate the S= DP answerer to accept it (assuming it enables BUNDLE, that is).

 <= /p>

However, if people have i= ssues with a MUST, a compromise would be =93SHOULD, unless some mechanism e= xplicitly requires the usage of separate RTCP ports=94=85 or something like that.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: mmusic-bounces@ietf.org [mai= lto:mmusic-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 2. toukokuuta 2013 1:29
To: Paul Kyzivat
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

 

+1 to mandating rtcp-mux when BUNDLEing.

 

Otherwise, we have weird situations, such as if you = try to BUNDLE a SCTP session and a non-RTCP-mux RTP session together; the f= ormer has 1 ICE component, the latter has 2.

 

On Tue, Apr 30, 2013 at 12:30 PM, Paul Kyzivat <<= a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blank">pkyzivat@alum.mit= .edu> wrote:

On 4/30/13 3:00 PM, Martin Thomson wrote:=

On 30 April 2013 10:12, Paul Kyzivat <pkyzivat@alum.mit.edu&g= t; wrote:

What are the implications of *not* mandating it?


I'm more interesting in learning why someone might want to split it
out.  I can't see any reason for doing that...

...that is, except perhaps for some of the fictitious attacks I invent
when someone suggests that RTCP is a good place for a security
mechanism of one sort or other.

 

Well, IIUC it was separate before there was a way to= combine them.
Why was that? Why hasn't separate RTCP gone away entirely?

        Thanks,
        Paul


_______________________________________________
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_CE0F590AD94847029082FDE0DCBFB698ciscocom_-- From prvs=3834f4ee55=christer.holmberg@ericsson.com Thu May 2 06:02:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBD621F8935 for ; Thu, 2 May 2013 06:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyOFCnHass36 for ; Thu, 2 May 2013 06:02:34 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E130F21F8523 for ; Thu, 2 May 2013 06:02:25 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-af-518263e0aba4 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 18.13.32006.0E362815; Thu, 2 May 2013 15:02:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Thu, 2 May 2013 15:02:24 +0200 From: Christer Holmberg To: "Mo Zanaty (mzanaty)" Thread-Topic: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? Thread-Index: Ac5FpkrHryzI/aQNT0iUvXy00zH5hwADtcYAAAPFvoAAAQhZgAA4imSAABwqMXAABklLyAAANmRg Date: Thu, 2 May 2013 13:02:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> <517FFB7E.8050801@alum.mit.edu> <51801BBD.1010505@alum.mit.edu> , <7594FB04B1934943A5C02806D1A2204B1C369709@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3699A8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvre7D5KZAg0VtTBZbpwpZTF3+mMXi xYM5TBYrNhxgdWDx+Pv+A5PHlN8bWT0WbCr1WLLkJ1MASxS3TVJiSVlwZnqevl0Cd8al5mXs Ba+yKs51rmJrYPwV18XIySEhYCLxcvsNZghbTOLCvfVsXYxcHEIChxklHiydAOUsZpRYdrkZ yOHgYBOwkOj+pw3SICKgK/Hu9zNGEJtZoFii7exCFhBbWMBGomnHTmaIGluJKfdusEPYURL/ f25gBbFZBFQklvxtBavnFfCV6Ng0hxli1xRmiXu/Z4AlOIGaW+Z/ArMZga77fmoNE8QycYlb T+YzQVwtILFkz3moD0QlXj7+xwphK0pcnb6cCeRmZoF8iZuPbSF2CUqcnPmEZQKj6Cwkk2Yh VM1CUgVRoiOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYmTPTczMSS832sQIjLuDW36r7mC8 c07kEKM0B4uSOG8yV2OgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk4QwSXVwBi4UDX4kBxzGs+d 6vXHzPacTPlqWMGwckZ6n8+0lZwPBJV2Rvx6FaEhG3HL+M2BDA/pivuCbwy+3bbUy10h/nuZ ypXp3w4dm923etXnBg4uGf6sOqa2bWzPzLcu0f7ytsr+XMOpZ5sjHF+2OafPkri24U7E4Xnz 1toHinVHJveqs6TedF1iWqTEUpyRaKjFXFScCADnLwi9jgIAAA== Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 13:02:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3699A8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In fact, I noticed that, in the second offer, BUNDLE already mandates it in= both the offer and answer :) So, the only addition would be to mandate it also in the first answer. Regards, Christer From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] Sent: 2. toukokuuta 2013 15:55 To: Christer Holmberg Cc: Justin Uberti; Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? +1 for MUST in offer and answer. On May 2, 2013, at 6:01 AM, "Christer Holmberg" > wrote: Hi, Things would certainly work with separate RTCP ports. But, it would mean an= additional 5-tuple, with associated ICE etc, which is what we want to avoi= d by using BUNDLE. And, as BUNDLE already mandates the SDP offerer to offer rtcp-mux, my sugge= stion is to mandate the SDP answerer to accept it (assuming it enables BUND= LE, that is). However, if people have issues with a MUST, a compromise would be "SHOULD, = unless some mechanism explicitly requires the usage of separate RTCP ports"= ... or something like that. Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 2. toukokuuta 2013 1:29 To: Paul Kyzivat Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? +1 to mandating rtcp-mux when BUNDLEing. Otherwise, we have weird situations, such as if you try to BUNDLE a SCTP se= ssion and a non-RTCP-mux RTP session together; the former has 1 ICE compone= nt, the latter has 2. On Tue, Apr 30, 2013 at 12:30 PM, Paul Kyzivat > wrote: On 4/30/13 3:00 PM, Martin Thomson wrote: On 30 April 2013 10:12, Paul Kyzivat > wrote: What are the implications of *not* mandating it? I'm more interesting in learning why someone might want to split it out. I can't see any reason for doing that... ...that is, except perhaps for some of the fictitious attacks I invent when someone suggests that RTCP is a good place for a security mechanism of one sort or other. Well, IIUC it was separate before there was a way to combine them. Why was that? Why hasn't separate RTCP gone away entirely? Thanks, Paul _______________________________________________ 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_7594FB04B1934943A5C02806D1A2204B1C3699A8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

In fact, I noticed that, = in the second offer, BUNDLE already mandates it in both the offer and answe= r :)

 <= /p>

So, the only addition wou= ld be to mandate it also in the first answer.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Mo Zanat= y (mzanaty) [mailto:mzanaty@cisco.com]
Sent: 2. toukokuuta 2013 15:55
To: Christer Holmberg
Cc: Justin Uberti; Paul Kyzivat; mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

 

+1 for MUST in offer and answer.



On May 2, 2013, at 6:01 AM, "Christer Holmberg" <christer.holmberg@ericsson.com>= wrote:

Hi,

 <= /p>

Things would certainly wo= rk with separate RTCP ports. But, it would mean an additional 5-tuple, with= associated ICE etc, which is what we want to avoid by using BUNDLE.

 <= /p>

And, as BUNDLE already ma= ndates the SDP offerer to offer rtcp-mux, my suggestion is to mandate the S= DP answerer to accept it (assuming it enables BUNDLE, that is).

 <= /p>

However, if people have i= ssues with a MUST, a compromise would be “SHOULD, unless some mechani= sm explicitly requires the usage of separate RTCP ports”… or so= mething like that.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 2. toukokuuta 2013 1:29
To: Paul Kyzivat
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?<= o:p>

 

+1 to mandating rtcp-mux when BUNDLEing.

 

Otherwise, we have weird situations, such as if you = try to BUNDLE a SCTP session and a non-RTCP-mux RTP session together; the f= ormer has 1 ICE component, the latter has 2.

 

On Tue, Apr 30, 2013 at 12:30 PM, Paul Kyzivat <<= a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blank">pkyzivat@alum.mit= .edu> wrote:

On 4/30/13 3:00 PM, Martin Thomson wrote:=

On 30 April 2013 10:12, Paul Kyzivat <pkyzivat@alum.mit.edu&g= t; wrote:

What are the implications of *not* mandating it?


I'm more interesting in learning why someone might want to split it
out.  I can't see any reason for doing that...

...that is, except perhaps for some of the fictitious attacks I invent
when someone suggests that RTCP is a good place for a security
mechanism of one sort or other.

 

Well, IIUC it was separate before there was a way to= combine them.
Why was that? Why hasn't separate RTCP gone away entirely?

        Thanks,
        Paul


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

 

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

--_000_7594FB04B1934943A5C02806D1A2204B1C3699A8ESESSMB209erics_-- From pkyzivat@alum.mit.edu Thu May 2 07:17:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A42921F8B2B for ; Thu, 2 May 2013 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.038 X-Spam-Level: X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzP9zSvnXjMt for ; Thu, 2 May 2013 07:17:47 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 665B121F8B3A for ; Thu, 2 May 2013 07:17:46 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta01.westchester.pa.mail.comcast.net with comcast id Wz7i1l0040xGWP8512HlcM; Thu, 02 May 2013 14:17:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id X2Hl1l01B3ZTu2S3Y2HlmP; Thu, 02 May 2013 14:17:45 +0000 Message-ID: <51827589.4060509@alum.mit.edu> Date: Thu, 02 May 2013 10:17:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>, <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> 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=1367504266; bh=U1KHQrp7AoKm1yA+QhWcP/aqhnrguIUjZipk+XTGUiI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y+LVBYdBujYrSLEr7LY4ulUYnktD1JAK+N0nKrRw5vIec6cC0esApmohGrfmz7Lhp Bph++kwsA8uZ172CaR/7CQMShvKRYJYrf6EFIOunGrkUbRWYyCvJN8oVJ0VU1kmR53 RfVb1OYh99Yb+TsQYuy/7pMJiCs6TWN4tZ24M+9k3AnXlYPyl6ZEnaQJAR1gLcJXiA BkVBcLA5YYPwlCza8Cf8UA7/Ut39aaCUEVZu0q+3oDYoZV21jrNFzI5Ts3ZS8EyacE tVf9Kx7zLwPCX5kVlbY8kP/jUR99/qTksZksqKBmrk/mnP/HWJd76gLS94WjCOHVpE 6hT16y7kBvm1Q== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:17:53 -0000 Replying to everybody, Yes, 4145 was just for TCP, but the same notation has subsequently been applied in several other contexts that need the same kind of decision, as pointed out by others in this thread. And yes, it would be better if there was a separate specification of a=setup, divorced from its application to any particular proto. But doing that would violate the rich tradition and spirit of SDP evolution. :-) Mo has covered the 3pcc case well. It is a solved problem for a=setup. Thanks, Paul On 5/2/13 3:15 AM, Schwarz, Albrecht (Albrecht) wrote: > The RFC situation is not really clear, even confusing concerning > client/server role negotiations (in case of transport security sessions > over connection-oriented IP transport protocols). > > ·RFC 4145 is only about TCP, i.e., TCP client/server role assignments. > Thus, the RFC 4145 introduced SDP attribute is TCP specific. > > ·draft-ietf-mmusic-sctp-sdp: seems to profile the “a=setup:” attribute > for SCTP path establishment directions … (?) > > ·RFC 5763 uses the TCP SDP attribute for DTLS session establishment, > i.e. DTLS client/server role assignments; that’s actually a semantical > change of this SDP element vs RFC 4145 > > … and DTLS is TLS based, leading to the question of role/assignments in > case of TLS/TCP sessions? > > I.e., the TCP client/server and also TLS client/server roles? Keeping in > mind that the role assignments at IP transport layer and security > session layer may principally be different! > > The “a=setup” definition by RFC 4145 is unfortunate in my opinion. > > Required seems to be a generic SDP specification (i.e., outside RFC > 4145), which may be then tight to the concerned protocol. Sth like an > explicit indication “a=setup:PROTOCOL:” or an implicit indication by > adding an identifier. > > The “m=” line element does not really help to reduce ambiguity > (as Paul reminded again: ““Unfortunately SDP has a pretty confusing idea > of "transport". The proto field identifies a whole stack of protocol > layers.”). > > Albrecht > > PS > > I would see following parameter values for a SDP “a=setup:PROTOCOL:” > attribute extension: > > L4: TCP, SCTP, DCCP(?) > > L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling …) > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Mo Zanaty (mzanaty) > *Sent:* Donnerstag, 2. Mai 2013 06:04 > *To:* Justin Uberti > *Cc:* Paul Kyzivat; mmusic@ietf.org > *Subject:* Re: [MMUSIC] DTLS-SRTP client/server role negotiation > > A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so > the other leg will answer with active or passive but not actpass. > > A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze > and alter SDP in complex ways to generate two answers from two offers, > part of which is deciding which answer should become active and which > should become passive. > > The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded > unaltered by a B2BUA which delays offers on both legs. Generating two > answers from two offers is much more complex than simply forwarding the > offers as answers. > > DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be > actpass. TCP is harder since RFC 4145 allows offers to be active, > passive, or actpass, causing more complex reinvites to resolve > active/active or passive/passive conflicts. > > Mo > > > > On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: > > I think Paul means the active/passive attributes in RFC 5763, but I'm > still not sure about how 3rd party call control would be handled in this > case, i.e. when both endpoints think they are offerers and set > a=setup:actpass. > > ICE has logic to determine roles in this scenario, as shows in RFC 5245, > B.11. > > On Wed, May 1, 2013 at 2:10 PM, Gustavo García > wrote: > > I saw it, but that is all about TCP client/server role and not DTLS > client/server role. Are we supposed to use the same "setup" attribute > for dtls role negotiation even if it is over UDP? > > I think there is no reason to tie TCP and DTLS roles, but perhaps I'm > misunderstanding something. > > > On 01/05/2013, at 13:56, Paul Kyzivat wrote: > > > On 5/1/13 2:26 PM, Gustavo García wrote: > >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and > which side is the DTLS server must be established via some out-of-band > mechanism such as SDP." > >> > >> What is the specification on how to signal that in SDP? > >> > >> Specifically in case of 3pcc where both endpoints are SDP offerers > which one should take the client and server roles for DTLS? Should we > tie that role to ICE controlled/controlling roles or should we negotiate > it in the SDP somehow? > > > > See RFC4145. > > > > _______________________________________________ > > 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 pkyzivat@alum.mit.edu Thu May 2 07:49:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F344421F8B3A for ; Thu, 2 May 2013 07:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaZbcG8CpT4g for ; Thu, 2 May 2013 07:49:33 -0700 (PDT) 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 13A7021F8B2B for ; Thu, 2 May 2013 07:49:32 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id X2JE1l0031YDfWL5B2pYgh; Thu, 02 May 2013 14:49:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id X2pY1l00r3ZTu2S3g2pYeb; Thu, 02 May 2013 14:49:32 +0000 Message-ID: <51827CFA.2030109@alum.mit.edu> Date: Thu, 02 May 2013 10:49:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C369973@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C369973@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=1367506172; bh=YdVF6sO9VLmMFEaSYYlW0H5o8J+DAMFgmpdWxaVcXBs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qL7hwXEnQ2ic4Gg9aYLC3ObzmT8o0yLDxyjVRc0etNaee2nfgjwihKeog7Nz769OS wiQaZHnYpg6Q14gm0coA9NnfPbqt2BQgBXC+iTwfh6jSh5GIRDPxNkFvvg3605jRda UcRGB9DMdrsPt69MT7OBCg/jUcPJjO2gehM+hHDGAV5ZCji8rS/UKlOt4Z7xodYco9 3sWLfbB0oPsZTtS9lutsoMPmA8sQUd2MseeHYZRapMU+u0HOvbXVZeYEBaeURyrEbo kVteQJ8juJRTlezt5Hxucy1bQLCGqx80x9SfclOkcR2VC2ijGpz1Goe6+U2vUuQqpc ygoVZfhNxwgbA== Subject: Re: [MMUSIC] BUNDLE and ZERO PORT VALUE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:49:38 -0000 Christer, I think what you suggest should work. An implication is that you can't signal how you would like to bundle a hypothetical m-line (currently with port zero) were it to subsequently be offered with a non-zero port. I think that is ok. My take has always been that the mechanism of signaling a rejected/unused m-line with a zero port was intended to imply that none of the accompanying media section lines need to be valid, and ones that otherwise might have been required are not required in this case. That is necessary so that an answerer can successfully refuse an offered m-line that it doesn't understand, and so can't construct a consistent answer. So the recipient must be very tolerant about what it receives in this case. That means it isn't appropriate to specify *anything* about what goes into the media section of a rejected m-line. Thanks, Paul On 5/2/13 8:55 AM, Christer Holmberg wrote: > Hi, > > One of the open issues is the usage of m- lines with port value zero > within a BUNDLE group. > > As Paul has indicated, RFC 5888 does not currently allow it. > > One suggestion has been to update RFC 5888. But, before we go down that > path, I think we need to see whether NOT allowing zero port m- lines in > BUNDLE groups would work. > > So, how would it impact BUNDLE? > > Zero port value in answer: > > If an m- line in the offer contains a non-zero port value, but the > associated m- line in the answer contains a zero port value (read: the > answerer rejected the offered media associated with the m- line), the > number of m- lines associated with the BUNDLE group would differ in the > offer and answer. > > As the media is rejected, no matter whether it would be part of a BUNDLE > group or not, I can’t think of any issues. > > Zero port value in offer: > > If an m- line in the offer contains a zero port value, the associated m- > line in the answer MUST also contain a zero port value. > > If the m- line has previously been part of a BUNDLE group, with a > non-zero port value, it means that the number of m- lines in the BUNDLE > group will be reduced. But, again, as the media is rejected, no matter > whether it would be part of a BUNDLE group or not, I can’t think of any > issues. > > Then, if one later wants assign a non-zero value to the m- line, and > insert it into a BUNDLE group, the number of m- lines in the BUNDLE > group would increase. I don’t see any issues as such with that. One > question, however, is whether the answerer is allowed to accept the m- > line, but reject it being part of a BUNDLE group. But, let’s discuss > that in a separate thread. > > SUGGESTION: > > My suggestion is that we do NOT allow m- lines with zero port value in a > BUNDLE group. Please indicate whether you are aware of restrictions, or > problems, that this would bring, and we will document those. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From internet-drafts@ietf.org Thu May 2 08:49:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF88621F8FB8; Thu, 2 May 2013 08:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx7+Vcjlablq; Thu, 2 May 2013 08:49:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B48621F8E76; Thu, 2 May 2013 08:49:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130502154935.13800.36809.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2013 08:49:35 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:49:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : A Network Address Translator (NAT) Traversal mechanism f= or media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : Jeff Goldberg Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-15.txt Pages : 32 Date : 2013-05-02 Abstract: This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=083460184e=magnus.westerlund@ericsson.com Thu May 2 08:50:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDAC21F8FFA for ; Thu, 2 May 2013 08:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.174 X-Spam-Level: X-Spam-Status: No, score=-105.174 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+uEEKqajPYr for ; Thu, 2 May 2013 08:50:35 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9521F8FFC for ; Thu, 2 May 2013 08:50:33 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-34-51828b473286 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EC.B6.32006.74B82815; Thu, 2 May 2013 17:50:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 2 May 2013 17:50:32 +0200 Message-ID: <51828B47.1020405@ericsson.com> Date: Thu, 2 May 2013 17:50:31 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130502154935.13800.36809.idtracker@ietfa.amsl.com> In-Reply-To: <20130502154935.13800.36809.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgluLIzCtJLcpLzFFi42KZGfG3VtejuynQ4PhOdoupyx+zODB6LFny kymAMYrbJimxpCw4Mz1P3y6BO+NP40y2ghOCFSeOPGRpYHzE28XIySEhYCKxqLmXBcIWk7hw bz1bFyMXh5DAKUaJefNWM0E4yxglzrQcYwSp4hXQlmi59xXMZhFQkTj8+CsriM0mYCFx80cj UDcHh6hAsMTW1hiIckGJkzOfgC0QERCWmPH2LxuILSzgLLFr2XpmEFtIwFFiTv86sBpOASeJ awc7mSEOkpTY8qKdHcRmFtCTmHK1hRHClpdo3jobqldboqGpg3UCo+AsJOtmIWmZhaRlASPz Kkb23MTMnPRyo02MwAA8uOW36g7GO+dEDjFKc7AoifMmczUGCgmkJ5akZqemFqQWxReV5qQW H2Jk4uAEEVxSDYzugfPVdiSv79LL8Fyq+Y/zwscVu+5K9Bdo7LqSceZcy/rleSodEu+C1WMn hgd0rnkvvVYiZ/7GMxr6l79M3v7FyyTTeO63aWkb94Xf/Lhx779Gzu+PWmxm14qsLTVROp28 5rTM84O1c+98WbY92UnIPKHqvlTH6oa4HtHVP7Ivpa+/6ckjnPtOiaU4I9FQi7moOBEA/28B gBMCAAA= Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:50:45 -0000 WG, This version incorporates the changes discussed in December on list as result of Ari's review. Cheers Magnus On 2013-05-02 17:49, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) > Author(s) : Jeff Goldberg > Magnus Westerlund > Thomas Zeng > Filename : draft-ietf-mmusic-rtsp-nat-15.txt > Pages : 32 > Date : 2013-05-02 > > Abstract: > This document defines a solution for Network Address Translation > (NAT) traversal for datagram based media streams setup and controlled > with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses > Interactive Connectivity Establishment (ICE) adapted to use RTSP as a > signalling channel, defining the necessary extra RTSP extensions and > procedures. > > > 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-15 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-15 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From alan.b.johnston@gmail.com Thu May 2 10:05:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5221421F8F0F for ; Thu, 2 May 2013 10:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZeHtua9nMVo for ; Thu, 2 May 2013 10:05:05 -0700 (PDT) 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 CC00B21F8F0D for ; Thu, 2 May 2013 10:05:04 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id s10so668077wey.17 for ; Thu, 02 May 2013 10:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/tB3WQ2U4ZXLm5tjcaA+3ni/qR4HFIB4CtqXje4abFw=; b=fe/83I2hboXgoF9BxGG+3vxSDoVtioCjiQF9WOATU13adtfVQJChrqmZ7KjpZf16lq Pn3JDV0sNdRLdQSYw0DfGV2rcq+Evr0xPheDy7mFxpixunYCEro92oq2TO/qnIfEkAsN PJdB8JUwFVkkiNAHZv6qT2Y0nGPXOTji9l44hQ+FymM2bHNTRvm/ecbe8LpyZThQZcX3 FJUnbKYYsICaYl518y+8Pvi4IKj4bmHMPFCGj/qgHcrherq8ONkzRBkTt9PKYutzOVaC cyCn2YBpY1/5DIwoNxR1W/ZZUm6eM22InaR2M1fn+xbGeEjfNX6WlfPboRP/PbtxRh2H 8yFQ== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr8957274wic.32.1367514302549; Thu, 02 May 2013 10:05:02 -0700 (PDT) Received: by 10.216.173.134 with HTTP; Thu, 2 May 2013 10:05:02 -0700 (PDT) In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Thu, 2 May 2013 12:05:02 -0500 Message-ID: From: Alan Johnston To: "Schwarz, Albrecht (Albrecht)" Content-Type: multipart/alternative; boundary=001a11c348303a973404dbbf3c85 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 17:05:06 -0000 --001a11c348303a973404dbbf3c85 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SRTP. = Is this attribute really needed? How do things work if one or both browsers don't include it? - Alan - On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) < albrecht.schwarz@alcatel-lucent.com> wrote: > The RFC situation is not really clear, even confusing concerning > client/server role negotiations (in case of transport security sessions > over connection-oriented IP transport protocols).**** > > ** ** > > **=B7 **RFC 4145 is only about TCP, i.e., TCP client/server role > assignments. Thus, the RFC 4145 introduced SDP attribute is TCP specific.= * > *** > > **=B7 **draft-ietf-mmusic-sctp-sdp: seems to profile the =93a=3Ds= etup:=94 > attribute for SCTP path establishment directions =85 (?)**** > > **=B7 **RFC 5763 uses the TCP SDP attribute for DTLS session > establishment, i.e. DTLS client/server role assignments; that=92s actuall= y a > semantical change of this SDP element vs RFC 4145 **** > > ** ** > > =85 and DTLS is TLS based, leading to the question of role/assignments in > case of TLS/TCP sessions?**** > > I.e., the TCP client/server and also TLS client/server roles? Keeping in > mind that the role assignments at IP transport layer and security session > layer may principally be different!**** > > ** ** > > The =93a=3Dsetup=94 definition by RFC 4145 is unfortunate in my opinion.*= *** > > Required seems to be a generic SDP specification (i.e., outside RFC 4145)= , > which may be then tight to the concerned protocol. Sth like an explicit > indication =93a=3Dsetup:PROTOCOL:=94 or an implicit indication by adding = an > identifier.**** > > ** ** > > The =93m=3D=94 line element does not really help to reduce ambigu= ity (as > Paul reminded again: =93=93Unfortunately SDP has a pretty confusing idea = of > "transport". The proto field identifies a whole stack of protocol layers. > =94).**** > > ** ** > > Albrecht**** > > PS**** > > I would see following parameter values for a SDP =93a=3Dsetup:PROTOCOL:= =94 > attribute extension:**** > > L4: TCP, SCTP, DCCP(?)**** > > L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling =85)**** > > ** ** > > ** ** > > ** ** > > *From:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Mo Zanaty (mzanaty) > *Sent:* Donnerstag, 2. Mai 2013 06:04 > *To:* Justin Uberti > *Cc:* Paul Kyzivat; mmusic@ietf.org > *Subject:* Re: [MMUSIC] DTLS-SRTP client/server role negotiation**** > > ** ** > > A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so th= e > other leg will answer with active or passive but not actpass.**** > > ** ** > > A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze > and alter SDP in complex ways to generate two answers from two offers, pa= rt > of which is deciding which answer should become active and which should > become passive.**** > > ** ** > > The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded > unaltered by a B2BUA which delays offers on both legs. Generating two > answers from two offers is much more complex than simply forwarding the > offers as answers. **** > > ** ** > > DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be > actpass. TCP is harder since RFC 4145 allows offers to be active, passive= , > or actpass, causing more complex reinvites to resolve active/active or > passive/passive conflicts.**** > > ** ** > > Mo**** > > > > On May 1, 2013, at 6:28 PM, "Justin Uberti" wrote:**= * > * > > I think Paul means the active/passive attributes in RFC 5763, but I'm > still not sure about how 3rd party call control would be handled in this > case, i.e. when both endpoints think they are offerers and set > a=3Dsetup:actpass. **** > > ** ** > > ICE has logic to determine roles in this scenario, as shows in RFC 5245, > B.11. **** > > ** ** > > On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa wrote:*= *** > > I saw it, but that is all about TCP client/server role and not DTLS > client/server role. Are we supposed to use the same "setup" attribute f= or > dtls role negotiation even if it is over UDP? > > I think there is no reason to tie TCP and DTLS roles, but perhaps I'm > misunderstanding something.**** > > > On 01/05/2013, at 13:56, Paul Kyzivat wrote: > > > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: > >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and > which side is the DTLS server must be established via some out-of-band > mechanism such as SDP." > >> > >> What is the specification on how to signal that in SDP? > >> > >> Specifically in case of 3pcc where both endpoints are SDP offerers > which one should take the client and server roles for DTLS? Should we > tie that role to ICE controlled/controlling roles or should we negotiate = it > in the SDP somehow? > > > > See RFC4145. > > > > _______________________________________________ > > 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 > > --001a11c348303a973404dbbf3c85 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Interestingly, I have yet to see any browser use a=3Dsetup= for DTLS-SRTP. =A0Is this attribute really needed? =A0How do things work i= f one or both browsers don't include it?

- Alan -


On Thu, May 2, 2013 at 2:15 AM, Schwarz,= Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.co= m> wrote:

The RFC situation is not real= ly clear, even confusing concerning client/server role negotiations (in cas= e of transport security sessions over connection-oriented IP transport protocols).

=A0

=B7=A0=A0=A0=A0=A0=A0=A0=A0 RFC 4145 is only about T= CP, i.e., TCP client/server role assignments. Thus, the RFC 4145 introduced= SDP attribute is TCP specific.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 draft-ietf-mmusic-sctp-s= dp: seems to profile the =93a=3Dsetup:=94 attribute for SCTP path establish= ment directions =85 (?)

=B7=A0=A0=A0=A0=A0=A0=A0=A0 RFC 5763 uses the TCP SD= P attribute for DTLS session establishment, i.e. DTLS client/server role as= signments; that=92s actually a semantical change of this SDP element vs RFC 4145

=A0

=85 and DTLS is TLS based, le= ading to the question of role/assignments in case of TLS/TCP sessions?

I.e., the TCP client/server a= nd also TLS client/server roles? Keeping in mind that the role assignments = at IP transport layer and security session layer may principally be different!

=A0

The =93a=3Dsetup=94 definitio= n by RFC 4145 is unfortunate in my opinion.

Required seems to be a generi= c SDP specification (i.e., outside RFC 4145), which may be then tight to th= e concerned protocol. Sth like an explicit indication =93a=3Dsetup:PROTOCOL:=94 or an implicit indication by adding an identifie= r.

=A0

The =93m=3D=94 line <proto> element does no= t really help to reduce ambiguity (as Paul reminded again: =93=93Unfortunately SDP has a pretty confusing idea of "transport". The proto field = identifies a whole stack of protocol layers.= =94).

=A0

Albrecht=

PS

I would see following paramet= er values for a SDP =93a=3Dsetup:PROTOCOL:=94 attribute extension:

L4: TCP, SCTP, DCCP(?)=

L4+: TLS, DTLS, DTLS-SRTP(?, = due to RFC 5764 SDP profiling =85)

=A0

=A0

=A0

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

=A0

A simple 3PCC/B2BUA only delays offers toward one le= g like RFC3725, so the other leg will answer with active or passive but not= actpass.

=A0

A complex 3PCC/B2BUA delays offers toward both legs,= so it must analyze and alter SDP in complex ways to generate two answers f= rom two offers, part of which is deciding which answer should become active= and which should become passive.

=A0

The flow in RFC 5245 B.11 is oversimplified. SDP can= 't be forwarded unaltered by a B2BUA which delays offers on both legs. = Generating two answers from two offers is much more complex than simply for= warding the offers as answers.

=A0

DTLS-SRTP is actually an easy case since RFC 5763 re= quires offers to be actpass. TCP is harder since RFC 4145 allows offers to = be active, passive, or actpass, causing more complex reinvites to resolve a= ctive/active or passive/passive conflicts.

=A0

Mo



On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> wrote:=

I think Paul means the active/passive attributes in = RFC 5763, but I'm still not sure about how 3rd party call control would= be handled in this case, i.e. when both endpoints think they are offerers = and set a=3Dsetup:actpass.

=A0

ICE has logic to determine roles in this scenario, a= s shows in RFC 5245, B.11.=A0

=A0

On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa <= ;ggb@tokbox.com>= wrote:

I saw it, but that is all about TCP client/server ro= le and not DTLS client/server role. =A0 Are we supposed to use the same &qu= ot;setup" attribute for dtls role negotiation even if it is over UDP?<= br>
I think there is no reason to tie TCP and DTLS roles, but perhaps I'm m= isunderstanding something.


On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote:
>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS clien= t and which side is the DTLS server must be established via some out-of-ban= d mechanism such as SDP."
>>
>> What is the specification on how to signal that in SDP?
>>
>> Specifically in case of 3pcc where both endpoints are SDP offerers= which one should take the client and server roles for DTLS? =A0 =A0Should = we tie that role to ICE controlled/controlling roles or should we negotiate= it in the SDP somehow?
>
> See RFC4145.
>
> _______________________________________________
> 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

=A0

_______________________________________________
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


--001a11c348303a973404dbbf3c85-- From prvs=8834794abc=christer.holmberg@ericsson.com Thu May 2 10:31:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C4721F90DF for ; Thu, 2 May 2013 10:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHT6m9ckO2Xj for ; Thu, 2 May 2013 10:31:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B0EA521F8FF0 for ; Thu, 2 May 2013 10:31:20 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-78-5182a2e751e0 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D7.61.28165.7E2A2815; Thu, 2 May 2013 19:31:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Thu, 2 May 2013 19:31:17 +0200 From: Christer Holmberg To: Alan Johnston , "Schwarz, Albrecht (Albrecht)" Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpmC/JMg42bB/EOYWhKkPbD8pZjwrh2AgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIAAKEfF Date: Thu, 2 May 2013 17:31:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.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.17] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvre7zRU2BBvOWiFrMbG1lsfjT+ovR YuryxywWKzYcYHVg8Wh9tpfV4+/7D0weO2fdZfdYsuQnUwBLFLdNUmJJWXBmep6+XQJ3xqMt f9kKLuhX7Fh8hbmBcZJ6FyMnh4SAicTeyX9ZIWwxiQv31rN1MXJxCAkcZpSYcn05M4SzmFHi 2vZZjF2MHBxsAhYS3f+0QRpEBEolJn+fzgRiMwv4Srz/OZ0dxBYWsJOYMb+DCaLGXuJsxyI2 CDtKomn6FzCbRUBF4vT0h8wgNi9Q78rGxVCLFzNLLF5xAayZUyBQYsu1DWANjEDXfT+1BmqZ uMStJ/OZIK4WkFiy5zwzhC0q8fLxP1aQOyUEFCWW98tBlBtIvD83nxnC1pZYtvA11F5BiZMz n7BMYBSbhWTqLCQts5C0zELSsoCRZRUje25iZk56ueEmRmA0HdzyW3cH46lzIocYpTlYlMR5 k7gaA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwggguqQbGac//nokLbD69VDgzWZ1b361/cXnW 9M+9lf2TmViruy8E/M5TPeJweZop7/JlMucZljzbbBw7l9Hwhb7243Wu/g8Pysnm5L+6nrXs +OlHtjL1pt3hNu5xvCdOX53KXPp7vebnkirefp59BtYBHBtqj/BOje82OLFtlejP1TtW70m5 Mttp2ikVJZbijERDLeai4kQAEAisOHkCAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 17:31:26 -0000 Hi, RFC 4572 specifies that the "active" endpoint also takes the role as TLS cl= ient. At least MSRP refers to RFC 4572. AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act = as TLS client - ie it separates the TCP setup from TLS roles - which I thin= k is very good.=20 Regards, Christer ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Alan J= ohnston [alan.b.johnston@gmail.com] Sent: Thursday, 02 May 2013 8:05 PM To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SRTP. = Is this attribute really needed? How do things work if one or both browser= s don't include it? - Alan - On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) > wrote: The RFC situation is not really clear, even confusing concerning client/ser= ver role negotiations (in case of transport security sessions over connecti= on-oriented IP transport protocols). =95 RFC 4145 is only about TCP, i.e., TCP client/server role assign= ments. Thus, the RFC 4145 introduced SDP attribute is TCP specific. =95 draft-ietf-mmusic-sctp-sdp: seems to profile the =93a=3Dsetup:= =94 attribute for SCTP path establishment directions =85 (?) =95 RFC 5763 uses the TCP SDP attribute for DTLS session establishm= ent, i.e. DTLS client/server role assignments; that=92s actually a semantic= al change of this SDP element vs RFC 4145 =85 and DTLS is TLS based, leading to the question of role/assignments in c= ase of TLS/TCP sessions? I.e., the TCP client/server and also TLS client/server roles? Keeping in mi= nd that the role assignments at IP transport layer and security session lay= er may principally be different! The =93a=3Dsetup=94 definition by RFC 4145 is unfortunate in my opinion. Required seems to be a generic SDP specification (i.e., outside RFC 4145), = which may be then tight to the concerned protocol. Sth like an explicit ind= ication =93a=3Dsetup:PROTOCOL:=94 or an implicit indication by adding an id= entifier. The =93m=3D=94 line element does not really help to reduce ambiguit= y (as Paul reminded again: =93=93Unfortunately SDP has a pretty confusing i= dea of "transport". The proto field identifies a whole stack of protocol la= yers.=94). Albrecht PS I would see following parameter values for a SDP =93a=3Dsetup:PROTOCOL:=94 = attribute extension: L4: TCP, SCTP, DCCP(?) L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling =85) From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Mo Zanaty = (mzanaty) Sent: Donnerstag, 2. Mai 2013 06:04 To: Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 ggb@tokbox.com Thu May 2 10:36:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D10621F901D for ; Thu, 2 May 2013 10:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.301 X-Spam-Level: X-Spam-Status: No, score=-5.301 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kivu4sWkjlAZ for ; Thu, 2 May 2013 10:36:49 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with SMTP id 0A0F221F8FFA for ; Thu, 2 May 2013 10:36:48 -0700 (PDT) Received: from mail-da0-f72.google.com ([209.85.210.72]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKUYKkMHv3s5EOHxQKdlXBuN/PchilQHzw@postini.com; Thu, 02 May 2013 10:36:49 PDT Received: by mail-da0-f72.google.com with SMTP id a4so805743dad.11 for ; Thu, 02 May 2013 10:36:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=oEvuV+c3D9zsVbGbNXvEf9NT3iFYmo+aeI5nt469DmY=; b=VvmpOJ0fMbruEe+NsZ33jzlc7w8053F3SlCZPlr01EYr1Nfy+Vo9Omm7wLkfEV57i6 rGYQCbhoKjwoDVzbUqiXB+Gy6UWJvx+0ye2XxhkiGFoTLw5s23jGdZ6HBYY+1w7jyExT Lrk2TvMc2oIQrLZsH6wi7TgblSIqRsNhYf905nrjYsvfCwP/A2bxs5fTs0uVYoiDa97z liOFpIt9HhWVIXxm/wNyIINwPx1xC4/TXo9Y3jQLzeJF0kj0B6SaGTmU0IjT5xXcBDeE RG8Gs7yse+1BzE6o7nEAh1lUFgZtKJ98DHKWrH6HZM7AmZmXiOdlzHJCFkalL/D/B+xS Vxfw== X-Received: by 10.68.92.100 with SMTP id cl4mr10041880pbb.130.1367516208192; Thu, 02 May 2013 10:36:48 -0700 (PDT) X-Received: by 10.68.92.100 with SMTP id cl4mr10041876pbb.130.1367516208119; Thu, 02 May 2013 10:36:48 -0700 (PDT) Received: from [192.168.10.114] (ginger.tokbox.com. [216.38.134.117]) by mx.google.com with ESMTPSA id ih1sm8071087pbb.44.2013.05.02.10.36.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 May 2013 10:36:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= In-Reply-To: Date: Thu, 2 May 2013 10:36:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> To: Alan Johnston X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlDlxiY/1HipFklz6RvZHDozMVsDON39SjefaF0kyC9EfHQvVX9hUgPwaXbBTfvT41frVx15NUju3XYDBU9QuvI+0Vid5OKrg5x8BD5DIJul9DqTxau/2Ry9e7Ub3BAK+sCb2rowQ3gTTJd/Obt/XIRaPQuxQ== Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 17:36:54 -0000 In previous versions of Chrome the offerer was always the DTLS server. In newest version of Chrome the ICE controlling agent is always the DTLS = server. (controlling and offerer are not the same in case of offerer = being ice-lite implementation) I think in case of 3pcc we need "a=3Dsetup" with proxy/B2BUA modifying = the SDPs or using the ICE roles to resolve the conflicts. I prefer to = not use ICE to solve this and decouple ICE and DTLS roles. G. On 02/05/2013, at 10:05, Alan Johnston wrote: > Interestingly, I have yet to see any browser use a=3Dsetup for = DTLS-SRTP. Is this attribute really needed? How do things work if one = or both browsers don't include it? >=20 > - Alan - >=20 >=20 > On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) = wrote: > The RFC situation is not really clear, even confusing concerning = client/server role negotiations (in case of transport security sessions = over connection-oriented IP transport protocols). >=20 > =20 >=20 > =B7 RFC 4145 is only about TCP, i.e., TCP client/server role = assignments. Thus, the RFC 4145 introduced SDP attribute is TCP = specific. >=20 > =B7 draft-ietf-mmusic-sctp-sdp: seems to profile the = =93a=3Dsetup:=94 attribute for SCTP path establishment directions =85 = (?) >=20 > =B7 RFC 5763 uses the TCP SDP attribute for DTLS session = establishment, i.e. DTLS client/server role assignments; that=92s = actually a semantical change of this SDP element vs RFC 4145 >=20 > =20 >=20 > =85 and DTLS is TLS based, leading to the question of role/assignments = in case of TLS/TCP sessions? >=20 > I.e., the TCP client/server and also TLS client/server roles? Keeping = in mind that the role assignments at IP transport layer and security = session layer may principally be different! >=20 > =20 >=20 > The =93a=3Dsetup=94 definition by RFC 4145 is unfortunate in my = opinion. >=20 > Required seems to be a generic SDP specification (i.e., outside RFC = 4145), which may be then tight to the concerned protocol. Sth like an = explicit indication =93a=3Dsetup:PROTOCOL:=94 or an implicit indication = by adding an identifier. >=20 > =20 >=20 > The =93m=3D=94 line element does not really help to reduce = ambiguity (as Paul reminded again: =93=93Unfortunately SDP has a pretty = confusing idea of "transport". The proto field identifies a whole stack = of protocol layers.=94). >=20 > =20 >=20 > Albrecht >=20 > PS >=20 > I would see following parameter values for a SDP =93a=3Dsetup:PROTOCOL:=94= attribute extension: >=20 > L4: TCP, SCTP, DCCP(?) >=20 > L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling =85) >=20 > =20 >=20 > =20 >=20 > =20 >=20 > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Mo Zanaty (mzanaty) > Sent: Donnerstag, 2. Mai 2013 06:04 > To: Justin Uberti > Cc: Paul Kyzivat; mmusic@ietf.org > Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation >=20 > =20 >=20 > A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so = the other leg will answer with active or passive but not actpass. >=20 > =20 >=20 > A complex 3PCC/B2BUA delays offers toward both legs, so it must = analyze and alter SDP in complex ways to generate two answers from two = offers, part of which is deciding which answer should become active and = which should become passive. >=20 > =20 >=20 > The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded = unaltered by a B2BUA which delays offers on both legs. Generating two = answers from two offers is much more complex than simply forwarding the = offers as answers. >=20 > =20 >=20 > DTLS-SRTP is actually an easy case since RFC 5763 requires offers to = be actpass. TCP is harder since RFC 4145 allows offers to be active, = passive, or actpass, causing more complex reinvites to resolve = active/active or passive/passive conflicts. >=20 > =20 >=20 > Mo >=20 >=20 >=20 > On May 1, 2013, at 6:28 PM, "Justin Uberti" = wrote: >=20 > I think Paul means the active/passive attributes in RFC 5763, but I'm = still not sure about how 3rd party call control would be handled in this = case, i.e. when both endpoints think they are offerers and set = a=3Dsetup:actpass. >=20 > =20 >=20 > ICE has logic to determine roles in this scenario, as shows in RFC = 5245, B.11.=20 >=20 > =20 >=20 > On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa = wrote: >=20 > I saw it, but that is all about TCP client/server role and not DTLS = client/server role. Are we supposed to use the same "setup" attribute = for dtls role negotiation even if it is over UDP? >=20 > I think there is no reason to tie TCP and DTLS roles, but perhaps I'm = misunderstanding something. >=20 >=20 > On 01/05/2013, at 13:56, Paul Kyzivat wrote: >=20 > > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: > >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and = which side is the DTLS server must be established via some out-of-band = mechanism such as SDP." > >> > >> What is the specification on how to signal that in SDP? > >> > >> Specifically in case of 3pcc where both endpoints are SDP offerers = which one should take the client and server roles for DTLS? Should we = tie that role to ICE controlled/controlling roles or should we negotiate = it in the SDP somehow? > > > > See RFC4145. > > > > _______________________________________________ > > 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 >=20 > =20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From prvs=5834b24b49=christer.holmberg@ericsson.com Thu May 2 10:42:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB85A21F8FB3 for ; Thu, 2 May 2013 10:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8svaiXcrelMG for ; Thu, 2 May 2013 10:42:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BA06021F90F1 for ; Thu, 2 May 2013 10:42:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-8c-5182a5715ce5 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C0.94.28165.175A2815; Thu, 2 May 2013 19:42:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Thu, 2 May 2013 19:42:09 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE and ZERO PORT VALUE Thread-Index: Ac5HLpsHDAej8eBpR9CrVaLIOw2gaQABOGUAAAoQgo8= Date: Thu, 2 May 2013 17:42:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369BD3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C369973@ESESSMB209.ericsson.se>, <51827CFA.2030109@alum.mit.edu> In-Reply-To: <51827CFA.2030109@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.17] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+JvrW7h0qZAg+5v5hZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxW2TlFhSFpyZnqdvl8Cd8a5tH2vBapmKmzP7mBsY14h1MXJwSAiY SCz+m9zFyAlkiklcuLeerYuRi0NI4DCjxI3dS1ggnMWMEmv2bWEFaWATsJDo/qcN0iAi4Cvx 7PFtNhBbWMBAor35MiNE3FDi4MKD7CDlIgJWEv96IkHCLAIqEqeevmUFsXmBWp/e+skMYgsJ 5Eos+fqKBcTmFNCRuHb0C9gYRqB7vp9awwRiMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4V4 RVFieb8cRLmBxPtz85khbG2JZQtfM0OsFZQ4OfMJywRG0VlIps5C0jILScssJC0LGFlWMbLn JmbmpJcbbmIExsHBLb91dzCeOidyiFGag0VJnDeJqzFQSCA9sSQ1OzW1ILUovqg0J7X4ECMT ByeI4JJqYGT8+N8sbMWV+t/ON38k6HBs/FRtqCvTZzLhpe7C/QZnji1ex9weqV517ldNY9KJ KZuiejb5B3lx8K6sWXhsSoppsUpWXqKGgejZQDsNxp7VK+JEmy+azdH6vqtUjfX9959/lBJn 7fmmLF17MLX8/Sa97hLPzqOisdfmsj6/f1eYM/7Y1oM9IkosxRmJhlrMRcWJAPNtac5WAgAA Subject: Re: [MMUSIC] BUNDLE and ZERO PORT VALUE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 17:42:22 -0000 Hi, > I think what you suggest should work. > > An implication is that you can't signal how you would like to bundle a > hypothetical m-line (currently with port zero) were it to subsequently > be offered with a non-zero port. I think that is ok. I was thinking about that also, and if someone can come up with a reason wh= y it would be needed I'd like to hear it. And, IF there is a good use-case, we could e.g. define an SDP media level a= ttribute for indicating such thing. m=3Daudio 0 .... a=3Dmaybe-I-want-to-be-part-of-the-following-bundle-group: BGROUP1 > My take has always been that the mechanism of signaling a > rejected/unused m-line with a zero port was intended to imply that none > of the accompanying media section lines need to be valid, and ones that > otherwise might have been required are not required in this case. That > is necessary so that an answerer can successfully refuse an offered > m-line that it doesn't understand, and so can't construct a consistent > answer. So the recipient must be very tolerant about what it receives in > this case. That means it isn't appropriate to specify *anything* about > what goes into the media section of a rejected m-line. Agree. Good point. Regards, Christer On 5/2/13 8:55 AM, Christer Holmberg wrote: > Hi, > > One of the open issues is the usage of m- lines with port value zero > within a BUNDLE group. > > As Paul has indicated, RFC 5888 does not currently allow it. > > One suggestion has been to update RFC 5888. But, before we go down that > path, I think we need to see whether NOT allowing zero port m- lines in > BUNDLE groups would work. > > So, how would it impact BUNDLE? > > Zero port value in answer: > > If an m- line in the offer contains a non-zero port value, but the > associated m- line in the answer contains a zero port value (read: the > answerer rejected the offered media associated with the m- line), the > number of m- lines associated with the BUNDLE group would differ in the > offer and answer. > > As the media is rejected, no matter whether it would be part of a BUNDLE > group or not, I can=92t think of any issues. > > Zero port value in offer: > > If an m- line in the offer contains a zero port value, the associated m- > line in the answer MUST also contain a zero port value. > > If the m- line has previously been part of a BUNDLE group, with a > non-zero port value, it means that the number of m- lines in the BUNDLE > group will be reduced. But, again, as the media is rejected, no matter > whether it would be part of a BUNDLE group or not, I can=92t think of any > issues. > > Then, if one later wants assign a non-zero value to the m- line, and > insert it into a BUNDLE group, the number of m- lines in the BUNDLE > group would increase. I don=92t see any issues as such with that. One > question, however, is whether the answerer is allowed to accept the m- > line, but reject it being part of a BUNDLE group. But, let=92s discuss > that in a separate thread. > > SUGGESTION: > > My suggestion is that we do NOT allow m- lines with zero port value in a > BUNDLE group. Please indicate whether you are aware of restrictions, or > problems, that this would bring, and we will document those. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Thu May 2 10:53:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D09221F921B for ; Thu, 2 May 2013 10:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8UwOolxOnOG for ; Thu, 2 May 2013 10:53:12 -0700 (PDT) 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 9E1CB21F91CA for ; Thu, 2 May 2013 10:53:07 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta02.westchester.pa.mail.comcast.net with comcast id X5qA1l00G1ZXKqc515t7z4; Thu, 02 May 2013 17:53:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id X5t71l0043ZTu2S3h5t790; Thu, 02 May 2013 17:53:07 +0000 Message-ID: <5182A802.9020003@alum.mit.edu> Date: Thu, 02 May 2013 13:53:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C369B4F@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=1367517187; bh=E2cct/9EgRp2oM76anO0rvhglvcC0BaPBF7vj+G5GAA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hg5uhq0Xwle4x/NWdeE01uCkKX3hvlyfsM1ToK/C3imHKohgOmjJPSFg+d7fAdCUR jS9gR83RkC0PbrdCPOxxqiVVLsIrnVCTqbkdcPb80XygRV/FX2SigYq8fpim8dQ824 4cAk/009KbkbOtftInRmRhq3h9mEOEhmNRJD7lWBPbdA5q9srXwNrvtZv+gg+mtL6U km4yjLiRnGj32RH0DmSBzQF4qx2UP+2k0gCLKNjftLgRkWOGqslhJQxZne17ziN3Pj Z/FLtTohlghJA1q0uZ7cX5E/BWGGlLR3ST5NNEMsYOJ+R3XIiffdeAfftzi3nCncLw 7T4mssoBWDVdg== Cc: Alan Johnston , "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 17:53:19 -0000 On 5/2/13 1:31 PM, Christer Holmberg wrote: > > Hi, > > RFC 4572 specifies that the "active" endpoint also takes the role as TLS client. At least MSRP refers to RFC 4572. > > AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act as TLS client - ie it separates the TCP setup from TLS roles - which I think is very good. I think that approach has limitations. What does one do when doing a subsequent o/a, especially in the opposite direction? And how does one distinguish when in a subsequent o/a you do/don't want to reestablish the connection rather than retaining the existing one? Thanks, Paul > Regards, > > Christer > > > > ________________________________________ > From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Alan Johnston [alan.b.johnston@gmail.com] > Sent: Thursday, 02 May 2013 8:05 PM > To: Schwarz, Albrecht (Albrecht) > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation > > Interestingly, I have yet to see any browser use a=setup for DTLS-SRTP. Is this attribute really needed? How do things work if one or both browsers don't include it? > > - Alan - > > > On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) > wrote: > The RFC situation is not really clear, even confusing concerning client/server role negotiations (in case of transport security sessions over connection-oriented IP transport protocols). > > > • RFC 4145 is only about TCP, i.e., TCP client/server role assignments. Thus, the RFC 4145 introduced SDP attribute is TCP specific. > > • draft-ietf-mmusic-sctp-sdp: seems to profile the “a=setup:” attribute for SCTP path establishment directions … (?) > > • RFC 5763 uses the TCP SDP attribute for DTLS session establishment, i.e. DTLS client/server role assignments; that’s actually a semantical change of this SDP element vs RFC 4145 > > … and DTLS is TLS based, leading to the question of role/assignments in case of TLS/TCP sessions? > I.e., the TCP client/server and also TLS client/server roles? Keeping in mind that the role assignments at IP transport layer and security session layer may principally be different! > > The “a=setup” definition by RFC 4145 is unfortunate in my opinion. > Required seems to be a generic SDP specification (i.e., outside RFC 4145), which may be then tight to the concerned protocol. Sth like an explicit indication “a=setup:PROTOCOL:” or an implicit indication by adding an identifier. > > > The “m=” line element does not really help to reduce ambiguity (as Paul reminded again: ““Unfortunately SDP has a pretty confusing idea of "transport". The proto field identifies a whole stack of protocol layers.”). > > Albrecht > PS > I would see following parameter values for a SDP “a=setup:PROTOCOL:” attribute extension: > L4: TCP, SCTP, DCCP(?) > L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling …) > > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty) > Sent: Donnerstag, 2. Mai 2013 06:04 > To: Justin Uberti > Cc: Paul Kyzivat; mmusic@ietf.org > Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation > > A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the other leg will answer with active or passive but not actpass. > > A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and alter SDP in complex ways to generate two answers from two offers, part of which is deciding which answer should become active and which should become passive. > > The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unaltered by a B2BUA which delays offers on both legs. Generating two answers from two offers is much more complex than simply forwarding the offers as answers. > > DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be actpass. TCP is harder since RFC 4145 allows offers to be active, passive, or actpass, causing more complex reinvites to resolve active/active or passive/passive conflicts. > > Mo > > > On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: > I think Paul means the active/passive attributes in RFC 5763, but I'm still not sure about how 3rd party call control would be handled in this case, i.e. when both endpoints think they are offerers and set a=setup:actpass. > > ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.11. > > On Wed, May 1, 2013 at 2:10 PM, Gustavo García > wrote: > I saw it, but that is all about TCP client/server role and not DTLS client/server role. Are we supposed to use the same "setup" attribute for dtls role negotiation even if it is over UDP? > > I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misunderstanding something. > > On 01/05/2013, at 13:56, Paul Kyzivat wrote: > >> On 5/1/13 2:26 PM, Gustavo García wrote: >>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which side is the DTLS server must be established via some out-of-band mechanism such as SDP." >>> >>> What is the specification on how to signal that in SDP? >>> >>> Specifically in case of 3pcc where both endpoints are SDP offerers which one should take the client and server roles for DTLS? Should we tie that role to ICE controlled/controlling roles or should we negotiate it in the SDP somehow? >> >> See RFC4145. >> >> _______________________________________________ >> 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 francois.audet@skype.net Thu May 2 10:53:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D377121F925A for ; Thu, 2 May 2013 10:53:24 -0700 (PDT) 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=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RhxS0DkV0gO for ; Thu, 2 May 2013 10:53:18 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.28]) by ietfa.amsl.com (Postfix) with ESMTP id AD63A21F91D9 for ; Thu, 2 May 2013 10:53:12 -0700 (PDT) Received: from CH1SR01CA105.namsdf01.sdf.exchangelabs.com (10.255.157.22) by CH1SR01MB598.namsdf01.sdf.exchangelabs.com (10.255.157.35) with Microsoft SMTP Server (TLS) id 15.0.692.5; Thu, 2 May 2013 17:53:08 +0000 Received: from BY1FFOFD001.ffo.gbl (64.4.22.88) by CH1SR01CA105.outlook.office365.com (10.255.157.22) with Microsoft SMTP Server (TLS) id 15.0.692.5 via Frontend Transport; Thu, 2 May 2013 17:53:08 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.27) by BY1FFOFD001.mail.o365filtering.com (10.1.16.83) with Microsoft SMTP Server (TLS) id 15.0.687.1 via Frontend Transport; Thu, 2 May 2013 17:53:08 +0000 Received: from DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.123.1; Thu, 2 May 2013 17:52:35 +0000 Received: from DFM-DB3MBX15-05.exchange.corp.microsoft.com (10.166.18.223) by DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) with Microsoft SMTP Server (TLS) id 15.0.620.25; Thu, 2 May 2013 10:52:28 -0700 Received: from DFM-DB3MBX15-06.exchange.corp.microsoft.com (10.166.18.224) by DFM-DB3MBX15-05.exchange.corp.microsoft.com (10.166.18.223) with Microsoft SMTP Server (TLS) id 15.0.620.29; Thu, 2 May 2013 10:52:25 -0700 Received: from DFM-DB3MBX15-06.exchange.corp.microsoft.com ([169.254.10.115]) by DFM-DB3MBX15-06.exchange.corp.microsoft.com ([169.254.10.115]) with mapi id 15.00.0620.020; Thu, 2 May 2013 10:52:25 -0700 From: Francois Audet To: Christer Holmberg , Alan Johnston , "Schwarz, Albrecht (Albrecht)" Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpmVEvURY9bfg0yzsnNI9CMT4pjxRP2AgAAD2gCAABUxgIAAXkyAgAA1VwCAAKTYAIAAB1UA//+P8KA= Date: Thu, 2 May 2013 17:52:24 +0000 Message-ID: <8d9d933dfa7f4b2182144018905e1514@DFM-DB3MBX15-06.exchange.corp.microsoft.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454001)(13464002)(51704004)(479174001)(24454001)(199002)(44976003)(74876001)(46102001)(51856001)(74662001)(50466002)(23756003)(53806001)(74706001)(47446002)(74502001)(74366001)(54356001)(54316002)(6806003)(79102001)(33646001)(81342001)(76482001)(31966008)(66066001)(47736001)(56816002)(56776001)(81542001)(20776003)(47776003)(63696002)(59766001)(49866001)(50986001)(80022001)(47976001)(69226001)(77982001)(65816001)(4396001)(16406001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CH1SR01MB598; H:hybrid.exchange.microsoft.com; RD:mail7.exchange.microsoft.com; MX:1; A:1; LANG:en; X-Forefront-PRVS: 0834BAF534 X-OriginatorOrg: msft.ccsctp.net Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 17:53:25 -0000 You think a rule the binds TLS client role to offer/answer is *good*.... Re= ally, why? -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 2 May, 2013 10:31 To: Alan Johnston; Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation Hi, RFC 4572 specifies that the "active" endpoint also takes the role as TLS cl= ient. At least MSRP refers to RFC 4572. AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act = as TLS client - ie it separates the TCP setup from TLS roles - which I thin= k is very good.=20 Regards, Christer ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Alan J= ohnston [alan.b.johnston@gmail.com] Sent: Thursday, 02 May 2013 8:05 PM To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SRTP. = Is this attribute really needed? How do things work if one or both browser= s don't include it? - Alan - On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) > wrote: The RFC situation is not really clear, even confusing concerning client/ser= ver role negotiations (in case of transport security sessions over connecti= on-oriented IP transport protocols). . RFC 4145 is only about TCP, i.e., TCP client/server role assignme= nts. Thus, the RFC 4145 introduced SDP attribute is TCP specific. . draft-ietf-mmusic-sctp-sdp: seems to profile the "a=3Dsetup:" att= ribute for SCTP path establishment directions . (?) . RFC 5763 uses the TCP SDP attribute for DTLS session establishmen= t, i.e. DTLS client/server role assignments; that's actually a semantical c= hange of this SDP element vs RFC 4145 . and DTLS is TLS based, leading to the question of role/assignments in cas= e of TLS/TCP sessions? I.e., the TCP client/server and also TLS client/server roles? Keeping in mi= nd that the role assignments at IP transport layer and security session lay= er may principally be different! The "a=3Dsetup" definition by RFC 4145 is unfortunate in my opinion. Required seems to be a generic SDP specification (i.e., outside RFC 4145), = which may be then tight to the concerned protocol. Sth like an explicit ind= ication "a=3Dsetup:PROTOCOL:" or an implicit indication by adding an identi= fier. The "m=3D" line element does not really help to reduce ambiguity (a= s Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "= transport". The proto field identifies a whole stack of protocol layers."). Albrecht PS I would see following parameter values for a SDP "a=3Dsetup:PROTOCOL:" attr= ibute extension: L4: TCP, SCTP, DCCP(?) L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling .) From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Mo Zanaty = (mzanaty) Sent: Donnerstag, 2. Mai 2013 06:04 To: Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 prvs=7834fac474=christer.holmberg@ericsson.com Thu May 2 11:09:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F80421F8FA7 for ; Thu, 2 May 2013 11:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlElZLhfMQeG for ; Thu, 2 May 2013 11:09:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D394021F8EB3 for ; Thu, 2 May 2013 11:09:40 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-0f-5182abe3d90a Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A7.2A.01956.3EBA2815; Thu, 2 May 2013 20:09:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Thu, 2 May 2013 20:09:39 +0200 From: Christer Holmberg To: Francois Audet , Alan Johnston , "Schwarz, Albrecht (Albrecht)" Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpmC/JMg42bB/EOYWhKkPbD8pZjwrh2AgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIAAKEfF///k9QCAACTW+w== Date: Thu, 2 May 2013 18:09:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369C11@ESESSMB209.ericsson.se> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se>, <8d9d933dfa7f4b2182144018905e1514@DFM-DB3MBX15-06.exchange.corp.microsoft.com> In-Reply-To: <8d9d933dfa7f4b2182144018905e1514@DFM-DB3MBX15-06.exchange.corp.microsoft.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvre7j1U2BBq8emljMbG1lsfjT+ovR omM1i8XU5Y9ZLFZsOMDqwOrR+mwvq8ff9x+YPHbOusvusWTJTyaPWw8msQWwRnHbJCWWlAVn pufp2yVwZyw+tZat4JRVxezlE1kaGCcbdDFyckgImEi8+HaECcIWk7hwbz1bFyMXh5DAYUaJ 02cfsoEkhAQWM0r0HrfoYuTgYBOwkOj+pw1SIyKwiFHi4vMTrCA1zAK+Eu9/TmcHsYUF7CRm zO8AGyoiYC9xtmMRG4SdJbG27yILyBwWARWJh8sLQMK8QK3LNs9hgti7k0Xi8tfLYPWcAtES 8x5cA7MZgY77fmoNE8QucYlbT+ZDHS0gsWTPeWYIW1Ti5eN/rCDzJQQUJZb3y0GU60ncmDqF DcLWlli28DUzxF5BiZMzn7BMYBSbhWTqLCQts5C0zELSsoCRZRUje25iZk56ufkmRmB0Hdzy 22AH46b7YocYpTlYlMR5k7kaA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwggguqQZGvkWfa+LO GlwIy9HpC2SXzDjtmfXZ2P7hVsYwxsq9jw5at+TkHL17vERvRdGkbR/8lVjOB2/gMCmdsHl7 W4eTu+zq/cyyjxZb3LjAXP2db2ZlTf1qyYbqt18UPG1zDh32vTj3GG+xjOX9ORybPjw5eqNo QcTGcwZTC3a0BOYJXD69L0N+p4WvEktxRqKhFnNRcSIAcPo3ZoECAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 18:09:46 -0000 Hi, One good reason is if both clients are behind NATs, connected to SBCs. The = SBCs will typically make the clients "active", in order to make the TCP con= nection traverse the NAT. Hence both clients will also become TLS clients. = But, TLS does not define a mechanism to handle "collisions" when both endpo= ints act as TLS client, which means some intermediary needs to act as TLS s= erver towards the clients. Now, I realize that may not be a "valid" reason in IETF, and with ICE it ma= y not be a long-term problem :)=20 But, is there a reason why it is NOT be a good idea? Regards, Christer ________________________________________ From: Francois Audet [francois.audet@skype.net] Sent: Thursday, 02 May 2013 8:52 PM To: Christer Holmberg; Alan Johnston; Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation You think a rule the binds TLS client role to offer/answer is *good*.... Re= ally, why? -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 2 May, 2013 10:31 To: Alan Johnston; Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation Hi, RFC 4572 specifies that the "active" endpoint also takes the role as TLS cl= ient. At least MSRP refers to RFC 4572. AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act = as TLS client - ie it separates the TCP setup from TLS roles - which I thin= k is very good. Regards, Christer ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Alan J= ohnston [alan.b.johnston@gmail.com] Sent: Thursday, 02 May 2013 8:05 PM To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SRTP. = Is this attribute really needed? How do things work if one or both browser= s don't include it? - Alan - On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) > wrote: The RFC situation is not really clear, even confusing concerning client/ser= ver role negotiations (in case of transport security sessions over connecti= on-oriented IP transport protocols). . RFC 4145 is only about TCP, i.e., TCP client/server role assignme= nts. Thus, the RFC 4145 introduced SDP attribute is TCP specific. . draft-ietf-mmusic-sctp-sdp: seems to profile the "a=3Dsetup:" att= ribute for SCTP path establishment directions . (?) . RFC 5763 uses the TCP SDP attribute for DTLS session establishmen= t, i.e. DTLS client/server role assignments; that's actually a semantical c= hange of this SDP element vs RFC 4145 . and DTLS is TLS based, leading to the question of role/assignments in cas= e of TLS/TCP sessions? I.e., the TCP client/server and also TLS client/server roles? Keeping in mi= nd that the role assignments at IP transport layer and security session lay= er may principally be different! The "a=3Dsetup" definition by RFC 4145 is unfortunate in my opinion. Required seems to be a generic SDP specification (i.e., outside RFC 4145), = which may be then tight to the concerned protocol. Sth like an explicit ind= ication "a=3Dsetup:PROTOCOL:" or an implicit indication by adding an identi= fier. The "m=3D" line element does not really help to reduce ambiguity (a= s Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "= transport". The proto field identifies a whole stack of protocol layers."). Albrecht PS I would see following parameter values for a SDP "a=3Dsetup:PROTOCOL:" attr= ibute extension: L4: TCP, SCTP, DCCP(?) L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling .) From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Mo Zanaty = (mzanaty) Sent: Donnerstag, 2. Mai 2013 06:04 To: Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 mzanaty@cisco.com Thu May 2 13:06:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0E921F8D27 for ; Thu, 2 May 2013 13:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl1Mp0KXV+aL for ; Thu, 2 May 2013 13:05:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F020821F8DCF for ; Thu, 2 May 2013 13:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24561; q=dns/txt; s=iport; t=1367525156; x=1368734756; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vYu5Fci0xApkcncbvnRHYiYuzWN5PfZ1xKGvMCFIicE=; b=OHUMJb80lE0hbrFQ/cfOzyhfLigzrHtNFdjLAaa+Sk0Gwd/XgvJZYsyE ezeinhw9zCQj5mJnuD05pqkTTYXyhQTIfEun6+B9V+RdaxCZMkfzL+Bql H9uO/mCM0YLbYtdonrJe7eSd87MzuCMmjhYpdDBeh9ndrM58eDhdmWJP1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGfGglGtJXG//2dsb2JhbABSgkNEN78ofxZ0gh8BAQEDAQEBASpBCwULAgEIEQQBAQEKFgcHJwsUCQgCBAENBQiHfgYMwVQEjnUtBAYBgnJhA4hfn36DDYIn X-IronPort-AV: E=Sophos;i="4.87,597,1363132800"; d="scan'208,217";a="202831566" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 02 May 2013 20:05:55 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r42K5t3l001291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 20:05:55 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.250]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 2 May 2013 15:05:54 -0500 From: "Mo Zanaty (mzanaty)" To: "Schwarz, Albrecht (Albrecht)" , Justin Uberti Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORq6jUvZFEriikUyEO6sxlAqo8pjxJyYAgAAVMYCAAAp7+oAAiSgAgAAzPTA= Date: Thu, 2 May 2013 20:05:54 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D45A655@xmb-aln-x14.cisco.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>, <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.88.107] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D45A655xmbalnx14ciscoc_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 20:06:03 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D45A655xmbalnx14ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > role assignments at IP transport layer and security session layer may pri= ncipally be different! If you mean TCP and TLS client/server roles can differ, I don't see that fl= exibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense fo= r SDP to describe flexibility which is not supported in the underlying prot= ocol. I agree it is somewhat confusing for DTLS-SRTP to use an attribute original= ly defined for TCP, but I don't see any practical problem or deficiency tha= t would be solved by the proposed "a=3Dsetup:PROTOCOL:" attribute extension= . Mo From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: Thursday, May 02, 2013 3:15 AM To: Mo Zanaty (mzanaty); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation The RFC situation is not really clear, even confusing concerning client/ser= ver role negotiations (in case of transport security sessions over connecti= on-oriented IP transport protocols). =B7 RFC 4145 is only about TCP, i.e., TCP client/server role assign= ments. Thus, the RFC 4145 introduced SDP attribute is TCP specific. =B7 draft-ietf-mmusic-sctp-sdp: seems to profile the "a=3Dsetup:" a= ttribute for SCTP path establishment directions ... (?) =B7 RFC 5763 uses the TCP SDP attribute for DTLS session establishm= ent, i.e. DTLS client/server role assignments; that's actually a semantical= change of this SDP element vs RFC 4145 ... and DTLS is TLS based, leading to the question of role/assignments in c= ase of TLS/TCP sessions? I.e., the TCP client/server and also TLS client/server roles? Keeping in mi= nd that the role assignments at IP transport layer and security session lay= er may principally be different! The "a=3Dsetup" definition by RFC 4145 is unfortunate in my opinion. Required seems to be a generic SDP specification (i.e., outside RFC 4145), = which may be then tight to the concerned protocol. Sth like an explicit ind= ication "a=3Dsetup:PROTOCOL:" or an implicit indication by adding an identi= fier. The "m=3D" line element does not really help to reduce ambiguity (a= s Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "= transport". The proto field identifies a whole stack of protocol layers."). Albrecht PS I would see following parameter values for a SDP "a=3Dsetup:PROTOCOL:" attr= ibute extension: L4: TCP, SCTP, DCCP(?) L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling ...) From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Mo Zanaty (mzanaty) Sent: Donnerstag, 2. Mai 2013 06:04 To: Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D45A655xmbalnx14ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> role assignments at IP transport l= ayer and security session layer may principally be different!

 

If you mean TCP and TLS client/server r= oles can differ, I don’t see that flexibility in TLS itself (RFC 5246= section 7.4), so it doesn’t make sense for SDP to describe flexibili= ty which is not supported in the underlying protocol.

 

I agree it is somewhat confusing for DT= LS-SRTP to use an attribute originally defined for TCP, but I don’t s= ee any practical problem or deficiency that would be solved by the proposed “a=3Dsetup:PROTOCOL:” attribute extension.

 

Mo

 

 

From: Schwarz,= Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Sent: Thursday, May 02, 2013 3:15 AM
To: Mo Zanaty (mzanaty); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

The RFC situation is not really clear, even = confusing concerning client/server role negotiations (in case of transport = security sessions over connection-oriented IP transport protocols).

 

=B7      &nbs= p;  RFC 4145 is only about TCP, i.e., TC= P client/server role assignments. Thus, the RFC 4145 introduced SDP attribu= te is TCP specific.

=B7      &nbs= p;  draft-ietf-mmusic-sctp-sdp: seems to= profile the “a=3Dsetup:” attribute for SCTP path establishment= directions … (?)

=B7      &nbs= p;  RFC 5763 uses the TCP SDP attribute = for DTLS session establishment, i.e. DTLS client/server role assignments; t= hat’s actually a semantical change of this SDP element vs RFC 4145

 

… and DTLS is TLS based, leading to th= e question of role/assignments in case of TLS/TCP sessions?

I.e., the TCP client/server and also TLS cli= ent/server roles? Keeping in mind that the role assignments at IP transport= layer and security session layer may principally be different!

 

The “a=3Dsetup” definition by RF= C 4145 is unfortunate in my opinion.

Required seems to be a generic SDP specifica= tion (i.e., outside RFC 4145), which may be then tight to the concerned pro= tocol. Sth like an explicit indication “a=3Dsetup:PROTOCOL:” or an implicit indication by adding an identifier.

 

The “m=3D” line <proto>= element does not really help to reduce ambiguity (as Paul reminded again: = ““Unfortunately SDP has a pretty confusing idea of "transport". The proto field = identifies a whole stack of protocol layers.”).=

 

Albrecht

PS

I would see following parameter values for a= SDP “a=3Dsetup:PROTOCOL:” attribute extension:

L4: TCP, SCTP, DCCP(?)

L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC = 5764 SDP profiling …)

 

 

 

From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

A simple 3PCC/B2BUA only delays of= fers toward one leg like RFC3725, so the other leg will answer with active = or passive but not actpass.

 

A complex 3PCC/B2BUA delays offers= toward both legs, so it must analyze and alter SDP in complex ways to gene= rate two answers from two offers, part of which is deciding which answer sh= ould become active and which should become passive.

 

The flow in RFC 5245 B.11 is overs= implified. SDP can't be forwarded unaltered by a B2BUA which delays offers = on both legs. Generating two answers from two offers is much more complex t= han simply forwarding the offers as answers.

 

DTLS-SRTP is actually an easy case= since RFC 5763 requires offers to be actpass. TCP is harder since RFC 4145= allows offers to be active, passive, or actpass, causing more complex rein= vites to resolve active/active or passive/passive conflicts.

 

Mo


On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> wrote:

I think Paul means the active/pass= ive attributes in RFC 5763, but I'm still not sure about how 3rd party call= control would be handled in this case, i.e. when both endpoints think they= are offerers and set a=3Dsetup:actpass.

 

ICE has logic to determine roles i= n this scenario, as shows in RFC 5245, B.11. 

 

On Wed, May 1, 2013 at 2:10 PM, Gu= stavo Garc=EDa <ggb@= tokbox.com> wrote:

I saw it, but that is all about TC= P client/server role and not DTLS client/server role.   Are we suppose= d to use the same "setup" attribute for dtls role negotiation eve= n if it is over UDP?

I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something.


On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote:
>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS clien= t and which side is the DTLS server must be established via some out-of-ban= d mechanism such as SDP."
>>
>> What is the specification on how to signal that in SDP?
>>
>> Specifically in case of 3pcc where both endpoints are SDP offerers= which one should take the client and server roles for DTLS?    S= hould we tie that role to ICE controlled/controlling roles or should we neg= otiate it in the SDP somehow?
>
> See RFC4145.
>
> _______________________________________________
> 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.o= rg/mailman/listinfo/mmusic

--_000_3879D71E758A7E4AA99A35DD8D41D3D91D45A655xmbalnx14ciscoc_-- From mzanaty@cisco.com Thu May 2 13:36:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2932A21F8DD6 for ; Thu, 2 May 2013 13:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHGJBENktGxv for ; Thu, 2 May 2013 13:36:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C832B21F87C5 for ; Thu, 2 May 2013 13:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6731; q=dns/txt; s=iport; t=1367526968; x=1368736568; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=czNwcSfZIr6olL1cHnWeM1Fg8QBs2jcnymn7b7sRucU=; b=cd9XROI7toNTLwy1zF3mmGwW+leydnIs72cvkFEAu0yC8eCUn+dlJ5VQ jM/pB5oyxoyR4Sa9QYdqlguLfn+dEym9TWymsfY8KaE3RlNmHvvgnMOTu opDptrIcuprfoW8qRU/se74FShfVRoZKiyvg9tHsWTMLTzfNP9MyuJkJD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJ7NglGtJV2Y/2dsb2JhbABSgwc3vyh/FnSCHwEBAQMBAQEBawsFBwQCAQgRBAEBAQodByEGCxQJCAIEAQ0FCIdyAwkGDLlBDYd4BIxPgiYxBwaCbGEDiF+MaI11hSGDDYIn X-IronPort-AV: E=Sophos;i="4.87,599,1363132800"; d="scan'208";a="205811281" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 02 May 2013 20:36:07 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r42Ka7Pr015924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 20:36:07 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.250]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 2 May 2013 15:36:07 -0500 From: "Mo Zanaty (mzanaty)" To: Christer Holmberg , Alan Johnston , "Schwarz, Albrecht (Albrecht)" Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHOR1cvUvZFEriikUyEO6sxlAqo8pjyetYA///XixA= Date: Thu, 2 May 2013 20:36:06 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D45A6B9@xmb-aln-x14.cisco.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.88.107] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 20:36:13 -0000 I think the TLS client/server role rule in BFCP over TCP/TLS is unfortunate= since it contradicts BFCP over UDP/DTLS as well as TLS itself. Perhaps one= reason why there is no known BFCP over TCP/TLS implementation. Mo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: Thursday, May 02, 2013 1:31 PM To: Alan Johnston; Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation Hi, RFC 4572 specifies that the "active" endpoint also takes the role as TLS cl= ient. At least MSRP refers to RFC 4572. AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act = as TLS client - ie it separates the TCP setup from TLS roles - which I thin= k is very good.=20 Regards, Christer ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Alan J= ohnston [alan.b.johnston@gmail.com] Sent: Thursday, 02 May 2013 8:05 PM To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SRTP. = Is this attribute really needed? How do things work if one or both browser= s don't include it? - Alan - On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) > wrote: The RFC situation is not really clear, even confusing concerning client/ser= ver role negotiations (in case of transport security sessions over connecti= on-oriented IP transport protocols). . RFC 4145 is only about TCP, i.e., TCP client/server role assignme= nts. Thus, the RFC 4145 introduced SDP attribute is TCP specific. . draft-ietf-mmusic-sctp-sdp: seems to profile the "a=3Dsetup:" att= ribute for SCTP path establishment directions . (?) . RFC 5763 uses the TCP SDP attribute for DTLS session establishmen= t, i.e. DTLS client/server role assignments; that's actually a semantical c= hange of this SDP element vs RFC 4145 . and DTLS is TLS based, leading to the question of role/assignments in cas= e of TLS/TCP sessions? I.e., the TCP client/server and also TLS client/server roles? Keeping in mi= nd that the role assignments at IP transport layer and security session lay= er may principally be different! The "a=3Dsetup" definition by RFC 4145 is unfortunate in my opinion. Required seems to be a generic SDP specification (i.e., outside RFC 4145), = which may be then tight to the concerned protocol. Sth like an explicit ind= ication "a=3Dsetup:PROTOCOL:" or an implicit indication by adding an identi= fier. The "m=3D" line element does not really help to reduce ambiguity (a= s Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "= transport". The proto field identifies a whole stack of protocol layers."). Albrecht PS I would see following parameter values for a SDP "a=3Dsetup:PROTOCOL:" attr= ibute extension: L4: TCP, SCTP, DCCP(?) L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling .) From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Mo Zanaty = (mzanaty) Sent: Donnerstag, 2. Mai 2013 06:04 To: Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 worley@shell01.TheWorld.com Thu May 2 18:16:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB67A21F8554 for ; Thu, 2 May 2013 18:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5wa2i5lZZOW for ; Thu, 2 May 2013 18:16:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0109621F8540 for ; Thu, 2 May 2013 18:16:01 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r431Fjd8003549; Thu, 2 May 2013 21:15:47 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r431FjmF4004282; Thu, 2 May 2013 21:15:45 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r431Fis33999826; Thu, 2 May 2013 21:15:44 -0400 (EDT) Date: Thu, 2 May 2013 21:15:44 -0400 (EDT) Message-Id: <201305030115.r431Fis33999826@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> <517FFB7E.8050801@alum.mit.edu> <51801BBD.1010505@alum.mit.edu> , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 01:16:08 -0000 > From: Christer Holmberg > > In fact, I noticed that, in the second offer, BUNDLE already > mandates it in both the offer and answer :) > > So, the only addition would be to mandate it also in the first answer. I can see why it would be useful to mandate rtcp-mux in the bundled offer/answer, because it is more port-efficient, and the code that handles the multiplexing and demultiplexing the constituent streams only has to handle the case where the RTCP is multiplexed with the RTP. But it doesn't seem that there is much to gain by mandating rtcp-mux in the first offer/answer, the one where actual bundling is not being done. All of the RTP/RTCP routing code that is active at that point has to support non-rtcp-mux operation already. Dale From juberti@google.com Thu May 2 18:57:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7720921F9058 for ; Thu, 2 May 2013 18:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.649 X-Spam-Level: X-Spam-Status: No, score=-101.649 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FqKOi68UZIz for ; Thu, 2 May 2013 18:57:15 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id D792021F9019 for ; Thu, 2 May 2013 18:57:14 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id l29so999336iag.28 for ; Thu, 02 May 2013 18:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QszjNh6shWx5ealA1zOJYM00kJiSnfsAFdJX/NesfOc=; b=OAPfoAzuD7cWnNlUxPpUuAIcKZu7y3ZcjLTBpb/PeGY5AKI5MZ507W+nI6U186k1Br 4NjyMhYzJH3WAuPnj3fAZxdFH8266vr7MgxFGbGMWm8tGxbRCTODlpDhMvNdXFL0dHBj /AkYh/t6ZzBbvoVU89FBUiCMIgyXP0+ryT1tNunryAboqcN8RosTzLSLufIW4W4x5Rfm OPBfszAlFECq5xR66wjuJwmuRuhP+A7tEPpkOYbqVsC7qJz/htjYjuklX8DZENuNanjR g+VyouTuV+K24UR7dEorWpFzDdAGND0UxbEocm4TT4jFFEh6UXp3v0RVTeZ67HnYdbtX 5yDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=QszjNh6shWx5ealA1zOJYM00kJiSnfsAFdJX/NesfOc=; b=DaWyu5MmQ7usglYuEaDq4bPBbwuaugTdv6VRzLoke0DAojBErk3iHm5XxVvqlRWKEa ngd+gEa8UIiTb0KFPTY574opEwesX2XpJ/1zkWoBQowUPIlyr3y2QthGp2awO48VpFri tzNpAKoEXOghWfEouvLgC11uXe4wCShTlpDBu189xbRsQhKoWGKsbgM3IirTYHjIC5V9 V4h3FbstfzTat7NTfOKQpp85z8Pm92r6SFCWUmdNTMmwXiocKKoMKycKsmluRdn4nZdD ZybR7Hip+rPRrbOAXp4i2cTdOcxG94e+RHvthfzcF81g0+p7QWzbsXycnuX954ceeijL hAVg== X-Received: by 10.50.32.4 with SMTP id e4mr15390082igi.95.1367546234506; Thu, 02 May 2013 18:57:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Thu, 2 May 2013 18:56:54 -0700 (PDT) In-Reply-To: <201305030115.r431Fis33999826@shell01.TheWorld.com> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> <517FFB7E.8050801@alum.mit.edu> <51801BBD.1010505@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se> <201305030115.r431Fis33999826@shell01.TheWorld.com> From: Justin Uberti Date: Thu, 2 May 2013 18:56:54 -0700 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=e89a8f3ba56d85a40c04dbc6aba0 X-Gm-Message-State: ALoCoQmeYmP3ItFDia4EhHRFNj4y9fd5SKcV+ChviMgwzdqR/y4EUsKf3N7fy+6+23to25QsE1i3if9TFGk3eL9x1lcPfe+NBrAuZPOtlt7rU2qa9DFnl8AhfHvBuu7+SEDQ+SsVKrrHX77F0R6tGoR51o/T+ZL/fW6ooxruxZ071lq88G5hdMt1XGeIrSevgaRuoKxqJZwt Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 01:57:15 -0000 --e89a8f3ba56d85a40c04dbc6aba0 Content-Type: text/plain; charset=UTF-8 Bundling is done during the first offer/answer. Any subsequent ones are just for the benefit of middleboxes. Mandating rtcp-mux for BUNDLE, even in the first offer/answer, avoids a couple ugly edge cases. On Thu, May 2, 2013 at 6:15 PM, Dale R. Worley wrote: > > From: Christer Holmberg > > > > In fact, I noticed that, in the second offer, BUNDLE already > > mandates it in both the offer and answer :) > > > > So, the only addition would be to mandate it also in the first answer. > > I can see why it would be useful to mandate rtcp-mux in the bundled > offer/answer, because it is more port-efficient, and the code that > handles the multiplexing and demultiplexing the constituent streams > only has to handle the case where the RTCP is multiplexed with the > RTP. > > But it doesn't seem that there is much to gain by mandating rtcp-mux > in the first offer/answer, the one where actual bundling is not being > done. All of the RTP/RTCP routing code that is active at that point > has to support non-rtcp-mux operation already. > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --e89a8f3ba56d85a40c04dbc6aba0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bundling is done during the first offer/answer. Any subseq= uent ones are just for the benefit of middleboxes.

Mandating rtcp-mux for BUNDLE, even in the first offer/answer, avoid= s a couple ugly edge cases.


On Thu,= May 2, 2013 at 6:15 PM, Dale R. Worley <worley@ariadne.com> wrote:
> From: Christer Holmberg <christer.holmberg@ericsson.com&g= t;
>
> In fact, I noticed that, in the second offer, BUNDLE already
> mandates it in both the offer and answer :)
>
> So, the only addition would be to mandate it also in the first answer.=

I can see why it would be useful to mandate rtcp-mux in the bundled offer/answer, because it is more port-efficient, and the code that
handles the multiplexing and demultiplexing the constituent streams
only has to handle the case where the RTCP is multiplexed with the
RTP.

But it doesn't seem that there is much to gain by mandating rtcp-mux in the first offer/answer, the one where actual bundling is not being
done. =C2=A0All of the RTP/RTCP routing code that is active at that point has to support non-rtcp-mux operation already.

Dale
_____________________= __________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--e89a8f3ba56d85a40c04dbc6aba0-- From bernard_aboba@hotmail.com Thu May 2 22:13:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B9C21F8E62 for ; Thu, 2 May 2013 22:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL1CUHh4sGhv for ; Thu, 2 May 2013 22:13:21 -0700 (PDT) Received: from blu0-omc1-s4.blu0.hotmail.com (blu0-omc1-s4.blu0.hotmail.com [65.55.116.15]) by ietfa.amsl.com (Postfix) with ESMTP id DB9C521F92BB for ; Thu, 2 May 2013 22:13:20 -0700 (PDT) Received: from BLU169-W131 ([65.55.116.7]) by blu0-omc1-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 May 2013 22:13:20 -0700 X-EIP: [hs4BJt4tk/Karh4oFb1B2xfFpTNaClwR] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_fe64c10f-71e4-4453-9687-720dd0bd9cce_" From: Bernard Aboba To: "Dale R. Worley" , Christer Holmberg Date: Thu, 2 May 2013 22:13:20 -0700 Importance: Normal In-Reply-To: <201305030115.r431Fis33999826@shell01.TheWorld.com> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se>, <517FFB7E.8050801@alum.mit.edu>, , <51801BBD.1010505@alum.mit.edu>, , , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se>, <201305030115.r431Fis33999826@shell01.TheWorld.com> MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2013 05:13:20.0392 (UTC) FILETIME=[ED79A880:01CE47BC] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 05:13:27 -0000 --_fe64c10f-71e4-4453-9687-720dd0bd9cce_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > But it doesn't seem that there is much to gain by mandating rtcp-mux > in the first offer/answer=2C the one where actual bundling is not being > done. All of the RTP/RTCP routing code that is active at that point > has to support non-rtcp-mux operation already. [BA] Support for rtcp-mux in the first offer/answer is mandated by RFC 576= 1 Section 5.1.3: The initial SDP offer MUST include this=0A= attribute at the media level to request multiplexing of RTP and RTCP=0A= on a single port.=20 [RFC5761] Section 5.1.3 also requires a fallback port for RTCP in the offe= r=2C in case the answerer doesn't support RTCP-mux: =20 If it is desired to use both ICE and multiplexed RTP and RTCP=2C the=0A= initial offer MUST contain an "a=3Drtcp-mux" attribute to indicate that= =0A= RTP and RTCP multiplexing is desired and MUST contain "a=3Dcandidate:"= =0A= lines for both RTP and RTCP along with an "a=3Drtcp:" line indicating a= =0A= fallback port for RTCP in the case that the answerer does not support=0A= RTP and RTCP multiplexing. This MUST be done for each media where=0A= RTP and RTCP multiplexing is desired. Given the existing normative text=2C and all the other problems we need to= solve=2C I think the burden of proof is on those who advocate deviation fr= om RFC 5761. = --_fe64c10f-71e4-4453-9687-720dd0bd9cce_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B But it doesn't seem that there is much to gain by mandating rtc= p-mux
>=3B in the first offer/answer=2C the one where actu= al bundling is not being
>=3B done. All of the RTP/RTCP routing code = that is active at that point
>=3B has to support non-rtcp-mux operatio= n already.

[BA]  =3BSupport for rtcp-mux in th= e =3Bfirst offer/answer is mandated = by RFC 5761 Section 5.1.3:

   The initial SDP offer MUST include this=0A=
   attribute at the media level to request multiplexing of RTP and RTCP=0A=
   on a single port.

[RFC5761]  =3BSection 5.1.3 also requires a fallback port = for RTCP in the offer=2C in case the answerer doesn't support RTCP-mux: =3B =3B
   If it is desir=
ed to use both ICE and multiplexed RTP and RTCP=2C the=0A=
   initial offer MUST contain an "a=3Drtcp-mux" attribute to indicate that=
=0A=
   RTP and RTCP multiplexing is desired and MUST contain "a=3Dcandidate:"=
=0A=
   lines for both RTP and RTCP along with an "a=3Drtcp:" line indicating a=
=0A=
   fallback port for RTCP in the case that the answerer does not support=0A=
   RTP and RTCP multiplexing.  This MUST be done for each media where=0A=
   RTP and RTCP multiplexing is desired.

=
Given the existing normative text=2C  =3Band all the other problems we=
 need to solve=2C I think the burden of proof is on those who advocate devi=
ation from RFC 5761. =3B
= --_fe64c10f-71e4-4453-9687-720dd0bd9cce_-- From juberti@google.com Thu May 2 22:54:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E26A21F89AF for ; Thu, 2 May 2013 22:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.281 X-Spam-Level: X-Spam-Status: No, score=-101.281 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbPbNcdbl+MW for ; Thu, 2 May 2013 22:54:11 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6726521F8523 for ; Thu, 2 May 2013 22:54:10 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id e36so1089122iag.33 for ; Thu, 02 May 2013 22:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=mW1r2oTvtsNroG2sfdn8S01HUpFe0ylf+lUuqH5DcsY=; b=hnuroUsBCGhN28olr2QA1fkV2olCe30RrJCImenp29KIbAiyzUrTeVyQs0c5P6iXFK R/wtp9UuPUAOzfNiuUG9lkJ7edSCZHYMTZ8UgCCLsLqMNHn+Se/tc2e5+HkXKrdcXhyt gLjqNzLfeDcx8Qo1QRAPEEMMV78F/XJi+svOWKxsmSjkmUkBuYGS+o7CTzUp/vH826PV UyvafxwQzFpSqyt4Gt7RKZcZo6shy+oPt77kntF/6fooNLUOM/KfWDDvaOz0gAovfoEg mhJId/V+IcmE0hg0OjAsEkWHq4lY6OScoYElp/bCpTkNEqr6WyiDTsZEKJ21Y9AEdYhs /XUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=mW1r2oTvtsNroG2sfdn8S01HUpFe0ylf+lUuqH5DcsY=; b=StCKsu5h/MSAqvU8y/s2EGTFpU5gQCZ1zoyLYaizJNKSZ6ni6S/l2GBAu0pRy/dvt3 Wh20+0qpHysbfkGKFCrKXFbkYlfKzx69CZGZ7RpAQnM29b6zOl5AmsmjT3PWZ4IOu5bu pwA/FWmhqJNxckwFXrE92D+khAcdSJ4Kcpzil/PF8Enw33azVPDqUk2kjv+4YfGFfGv2 XpajkX7HWUoJj+wBwbSneTK0hIA9AenLGuEjSHc15VEfnlkrBMLi5D6Tyhez6B9fA9IX SDDmuRRcycKsSNbr8jbjG8aOsziw3BuVemoCgXoGiZRCXXsYX6tSKX0XCHQhfVrCjXwy YSNg== X-Received: by 10.50.17.166 with SMTP id p6mr10113314igd.12.1367560449548; Thu, 02 May 2013 22:54:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Thu, 2 May 2013 22:53:49 -0700 (PDT) In-Reply-To: References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> From: Justin Uberti Date: Thu, 2 May 2013 22:53:49 -0700 Message-ID: To: =?UTF-8?Q?Gustavo_Garc=C3=ADa?= Content-Type: multipart/alternative; boundary=14dae9340cc9ce04da04dbc9fa09 X-Gm-Message-State: ALoCoQn2dCIxdIk9u3GDJ8izO1eS7faA5V48+dV7qYqkc8CuIut4yoqYEqYoGLd0tqh5/Eli/vm4UW3Njg9U09nR38zTrGBUTZ2DlyTaM9YnqU2ELTGzTI5hfA76icXkmkBLHhEdU/IJjYaWUhtG+nMhqEiU14e8zFmstsn9rdpk/Q/KEoSVF33GM6aFm5xtznfic+AqChQk Cc: Alan Johnston , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 05:54:12 -0000 --14dae9340cc9ce04da04dbc9fa09 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is where the OP's question came from - the differing policy between Chrome and Firefox. I (regarding Chrome) had figured that if ICE had made a determination regarding which side was in charge, the other layers in the stack should do the same, but it sounds like there are already established rules on how to do this. >From this thread, it sounds like the recommendation is to use a=3Dsetup:actpass in the offer, and then the answerer can use a=3Dsetup:act= ive to choose the client role. In 3pcc cases, the B2BUA can select a=3Dsetup appropriately to avoid any issue. Is that an accurate summary, and is there consensus on this? On Thu, May 2, 2013 at 10:36 AM, Gustavo Garc=C3=ADa wrote= : > In previous versions of Chrome the offerer was always the DTLS server. > > In newest version of Chrome the ICE controlling agent is always the DTLS > server. (controlling and offerer are not the same in case of offerer bei= ng > ice-lite implementation) > > I think in case of 3pcc we need "a=3Dsetup" with proxy/B2BUA modifying th= e > SDPs or using the ICE roles to resolve the conflicts. I prefer to not > use ICE to solve this and decouple ICE and DTLS roles. > > G. > > On 02/05/2013, at 10:05, Alan Johnston wrote: > > > Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SRT= P. > Is this attribute really needed? How do things work if one or both > browsers don't include it? > > > > - Alan - > > > > > > On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) < > albrecht.schwarz@alcatel-lucent.com> wrote: > > The RFC situation is not really clear, even confusing concerning > client/server role negotiations (in case of transport security sessions > over connection-oriented IP transport protocols). > > > > > > > > =C2=B7 RFC 4145 is only about TCP, i.e., TCP client/server role > assignments. Thus, the RFC 4145 introduced SDP attribute is TCP specific. > > > > =C2=B7 draft-ietf-mmusic-sctp-sdp: seems to profile the =E2=80= =9Ca=3Dsetup:=E2=80=9D > attribute for SCTP path establishment directions =E2=80=A6 (?) > > > > =C2=B7 RFC 5763 uses the TCP SDP attribute for DTLS session > establishment, i.e. DTLS client/server role assignments; that=E2=80=99s a= ctually a > semantical change of this SDP element vs RFC 4145 > > > > > > > > =E2=80=A6 and DTLS is TLS based, leading to the question of role/assign= ments in > case of TLS/TCP sessions? > > > > I.e., the TCP client/server and also TLS client/server roles? Keeping i= n > mind that the role assignments at IP transport layer and security session > layer may principally be different! > > > > > > > > The =E2=80=9Ca=3Dsetup=E2=80=9D definition by RFC 4145 is unfortunate i= n my opinion. > > > > Required seems to be a generic SDP specification (i.e., outside RFC > 4145), which may be then tight to the concerned protocol. Sth like an > explicit indication =E2=80=9Ca=3Dsetup:PROTOCOL:=E2=80=9D or an implicit = indication by adding > an identifier. > > > > > > > > The =E2=80=9Cm=3D=E2=80=9D line element does not really help to= reduce ambiguity > (as Paul reminded again: =E2=80=9C=E2=80=9CUnfortunately SDP has a pretty= confusing idea of > "transport". The proto field identifies a whole stack of protocol layers.= =E2=80=9D). > > > > > > > > Albrecht > > > > PS > > > > I would see following parameter values for a SDP =E2=80=9Ca=3Dsetup:PRO= TOCOL:=E2=80=9D > attribute extension: > > > > L4: TCP, SCTP, DCCP(?) > > > > L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling =E2=80=A6) > > > > > > > > > > > > > > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Mo Zanaty (mzanaty) > > Sent: Donnerstag, 2. Mai 2013 06:04 > > To: Justin Uberti > > Cc: Paul Kyzivat; mmusic@ietf.org > > Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation > > > > > > > > A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so > the other leg will answer with active or passive but not actpass. > > > > > > > > A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze > and alter SDP in complex ways to generate two answers from two offers, pa= rt > of which is deciding which answer should become active and which should > become passive. > > > > > > > > The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded > unaltered by a B2BUA which delays offers on both legs. Generating two > answers from two offers is much more complex than simply forwarding the > offers as answers. > > > > > > > > DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be > actpass. TCP is harder since RFC 4145 allows offers to be active, passive= , > or actpass, causing more complex reinvites to resolve active/active or > passive/passive conflicts. > > > > > > > > Mo > > > > > > > > On May 1, 2013, at 6:28 PM, "Justin Uberti" wrote: > > > > I think Paul means the active/passive attributes in RFC 5763, but I'm > still not sure about how 3rd party call control would be handled in this > case, i.e. when both endpoints think they are offerers and set > a=3Dsetup:actpass. > > > > > > > > ICE has logic to determine roles in this scenario, as shows in RFC 5245= , > B.11. > > > > > > > > On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=C3=ADa wr= ote: > > > > I saw it, but that is all about TCP client/server role and not DTLS > client/server role. Are we supposed to use the same "setup" attribute f= or > dtls role negotiation even if it is over UDP? > > > > I think there is no reason to tie TCP and DTLS roles, but perhaps I'm > misunderstanding something. > > > > > > On 01/05/2013, at 13:56, Paul Kyzivat wrote: > > > > > On 5/1/13 2:26 PM, Gustavo Garc=C3=ADa wrote: > > >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and > which side is the DTLS server must be established via some out-of-band > mechanism such as SDP." > > >> > > >> What is the specification on how to signal that in SDP? > > >> > > >> Specifically in case of 3pcc where both endpoints are SDP offerers > which one should take the client and server roles for DTLS? Should we > tie that role to ICE controlled/controlling roles or should we negotiate = it > in the SDP somehow? > > > > > > See RFC4145. > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --14dae9340cc9ce04da04dbc9fa09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is where the OP's question came from - the differ= ing policy between Chrome and Firefox. I (regarding Chrome) had figured tha= t if ICE had made a determination regarding which side was in charge, the o= ther layers in the stack should do the same, but it sounds like there are a= lready established rules on how to do this.

From this thread, it sounds like the recommendation is= to use a=3Dsetup:actpass in the offer, and then the answerer can use a=3Ds= etup:active to choose the client role. In 3pcc cases, the B2BUA can select = a=3Dsetup appropriately to avoid any issue.

Is that an accurate summary, and is there c= onsensus on this?


On Thu, May 2, 2013 at 10:36 AM, Gustavo Garc=C3=ADa <ggb@to= kbox.com> wrote:
In previous versions of Chrome the offerer w= as always the DTLS server.

In newest version of Chrome the ICE controlling agent is always the DTLS se= rver. =C2=A0(controlling and offerer are not the same in case of offerer be= ing ice-lite implementation)

I think in case of 3pcc we need "a=3Dsetup" with proxy/B2BUA modi= fying the SDPs or using the ICE roles to resolve the conflicts. =C2=A0 =C2= =A0I prefer to not use ICE to solve this and decouple ICE and DTLS roles.
G.

On 02/05/2013, at 10:05, Alan Johnston wrote:

> Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SR= TP. =C2=A0Is this attribute really needed? =C2=A0How do things work if one = or both browsers don't include it?
>
> - Alan -
>
>
> On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-= lucent.com> wrote:
> The RFC situation is not really clear, even confusing concerning clien= t/server role negotiations (in case of transport security sessions over con= nection-oriented IP transport protocols).
>
>
>
> =C2=B7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 4145 is only about TCP, i.e., T= CP client/server role assignments. Thus, the RFC 4145 introduced SDP attrib= ute is TCP specific.
>
> =C2=B7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-mmusic-sctp-sdp: seems t= o profile the =E2=80=9Ca=3Dsetup:=E2=80=9D attribute for SCTP path establis= hment directions =E2=80=A6 (?)
>
> =C2=B7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 5763 uses the TCP SDP attribute= for DTLS session establishment, i.e. DTLS client/server role assignments; = that=E2=80=99s actually a semantical change of this SDP element vs RFC 4145=
>
>
>
> =E2=80=A6 and DTLS is TLS based, leading to the question of role/assig= nments in case of TLS/TCP sessions?
>
> I.e., the TCP client/server and also TLS client/server roles? Keeping = in mind that the role assignments at IP transport layer and security sessio= n layer =C2=A0may principally be different!
>
>
>
> The =E2=80=9Ca=3Dsetup=E2=80=9D definition by RFC 4145 is unfortunate = in my opinion.
>
> Required seems to be a generic SDP specification (i.e., outside RFC 41= 45), which may be then tight to the concerned protocol. Sth like an explici= t indication =E2=80=9Ca=3Dsetup:PROTOCOL:=E2=80=9D or an implicit indicatio= n by adding an identifier.
>
>
>
> The =E2=80=9Cm=3D=E2=80=9D line <proto> element does not really = help to reduce ambiguity (as Paul reminded again: =E2=80=9C=E2=80=9CUnfortu= nately SDP has a pretty confusing idea of "transport". The proto = field identifies a whole stack of protocol layers.=E2=80=9D).
>
>
>
> Albrecht
>
> PS
>
> I would see following parameter values for a SDP =E2=80=9Ca=3Dsetup:PR= OTOCOL:=E2=80=9D attribute extension:
>
> L4: TCP, SCTP, DCCP(?)
>
> L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling =E2=80=A6)<= br> >
>
>
>
>
>
>
> From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ie= tf.org] On Behalf Of Mo Zanaty (mzanaty)
> Sent: Donnerstag, 2. Mai 2013 06:04
> To: Justin Uberti
> Cc: Paul Kyzivat; mmusic@ietf.org
> Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
>
>
>
> A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so= the other leg will answer with active or passive but not actpass.
>
>
>
> A complex 3PCC/B2BUA delays offers toward both legs, so it must analyz= e and alter SDP in complex ways to generate two answers from two offers, pa= rt of which is deciding which answer should become active and which should = become passive.
>
>
>
> The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarde= d unaltered by a B2BUA which delays offers on both legs. Generating two ans= wers from two offers is much more complex than simply forwarding the offers= as answers.
>
>
>
> DTLS-SRTP is actually an easy case since RFC 5763 requires offers to b= e actpass. TCP is harder since RFC 4145 allows offers to be active, passive= , or actpass, causing more complex reinvites to resolve active/active or pa= ssive/passive conflicts.
>
>
>
> Mo
>
>
>
> On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> wrote:
>
> I think Paul means the active/passive attributes in RFC 5763, but I= 9;m still not sure about how 3rd party call control would be handled in thi= s case, i.e. when both endpoints think they are offerers and set a=3Dsetup:= actpass.
>
>
>
> ICE has logic to determine roles in this scenario, as shows in RFC 524= 5, B.11.
>
>
>
> On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=C3=ADa <ggb@tokbox.com> wrote:
>
> I saw it, but that is all about TCP client/server role and not DTLS cl= ient/server role. =C2=A0 Are we supposed to use the same "setup" = attribute for dtls role negotiation even if it is over UDP?
>
> I think there is no reason to tie TCP and DTLS roles, but perhaps I= 9;m misunderstanding something.
>
>
> On 01/05/2013, at 13:56, Paul Kyzivat wrote:
>
> > On 5/1/13 2:26 PM, Gustavo Garc=C3=ADa wrote:
> >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS = client and which side is the DTLS server must be established via some out-o= f-band mechanism such as SDP."
> >>
> >> What is the specification on how to signal that in SDP?
> >>
> >> Specifically in case of 3pcc where both endpoints are SDP off= erers which one should take the client and server roles for DTLS? =C2=A0 = =C2=A0Should we tie that role to ICE controlled/controlling roles or should= we negotiate it in the SDP somehow?
> >
> > See RFC4145.
> >
> > _______________________________________________
> > 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

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

--14dae9340cc9ce04da04dbc9fa09-- From juberti@google.com Thu May 2 23:09:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7921F9017 for ; Thu, 2 May 2013 23:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.772 X-Spam-Level: X-Spam-Status: No, score=-101.772 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Qms81gDAgAg for ; Thu, 2 May 2013 23:09:05 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 66EDD21F8F0E for ; Thu, 2 May 2013 23:09:05 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id ar20so1486279iec.39 for ; Thu, 02 May 2013 23:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=LKHTd3sB3AyU5YZMUngUtxOpxh9zJEDvrRKdqh4Rhts=; b=M/ACp9PCkBa5gN5MT4buiSsI5HWu2//wogadusMLVI2HBx8d7s87cNLapUcpKbVzsu +mBVtez7kGNBNpQF6i3Ti6BuhAT/svqYHsTZRrM7bIkGWqrel06U6fsxEAiqcn1gwS5C eEaIgEMM6XG/9BIONbNtkUYeqj/ynqCmSIVdYe4QX/rJxF6I2mwvLWzkXyOtDTlmIrhN +tmNoxuJt/GFt8gAOmZp1fiAiACYPp+aQID4ykR+TuCB9CwufIw4vnRGmmR443JV/U5I 3I/3ge/sBNWUE6uBFBuYvNA3PY7wM2qWwjhw7pv8VnLutH1drg5wyi9fAJ0ighOb3FCE Nquw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=LKHTd3sB3AyU5YZMUngUtxOpxh9zJEDvrRKdqh4Rhts=; b=kvAuxR2FWf7+0k+Jo7lJg66qJCdgeV6UkjtH5o/RUcmU/HKzIH8Fh0VGj919Bj+Vy8 hRHoPGTwTA+8RufKKq0ToA5DPRmGVdjn8LW7un8frTJzw4QR1C2HrG53v3a5zWX2ctoc Pud6OLggL7ztdKnNlcqg6zCY93PgfDv9swJIpdfF+B5+ePWiJ8bVB/ETZqLZjGI7XXrP KvnvmL0G6xwpXlTZ7qx079PmK+/xSuX7asea8e20M4d4NofuhVMWKBVv5bdloB8Ttp6W YxJR/uZmzpShA1GwnwH28cY34Kqyz6x10XJkP7Jl5OfQ4bs6GywEAWmYQFCOa4iFRR+Z Oo7w== X-Received: by 10.42.145.137 with SMTP id f9mr4154993icv.52.1367561344772; Thu, 02 May 2013 23:09:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Thu, 2 May 2013 23:08:43 -0700 (PDT) In-Reply-To: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Thu, 2 May 2013 23:08:43 -0700 Message-ID: To: "rtcweb@ietf.org" , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba6e8b502a062404dbca3051 X-Gm-Message-State: ALoCoQk6Q/mi0X/7N66cwjo9nCXdTGXV7iyXlETer+aujr7xI/o9JrZLEYsvkzGNp0L6ZjS4lGWRc6Q/ir97YLrF04GXSmamsITTXKTX7RxbWO3fDZ8mi8RqUk+TY/sLo/Z+AzsePISwizKPphix8LE3spPzpwgu/62v4YFYiTCZ0EvIeNSmNbfScjU5hNzB3Vl8jKl00UbA Subject: [MMUSIC] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 06:09:06 -0000 --90e6ba6e8b502a062404dbca3051 Content-Type: text/plain; charset=UTF-8 Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each. Hopefully this will make discussion of this topic easier. ---------- Forwarded message ---------- From: Date: Thu, May 2, 2013 at 10:46 PM Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: Justin Uberti A new version of I-D, draft-uberti-rtcweb-plan-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-rtcweb-plan Revision: 00 Title: Plan B: a proposal for signaling multiple media sources in WebRTC. Creation date: 2013-05-03 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 Abstract: This document explains how multiple media sources can be signaled in WebRTC using SDP, in a fashion that avoids many common problems and provides a simple control surface to the receiver. The IETF Secretariat --90e6ba6e8b502a062404dbca3051 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Scribbled down the basic concepts of what I have been refe= rring to as "Plan B" - a way to signal multiple MediaStreamTracks= in SDP without needing a separate m=3D line for each.

H= opefully this will make discussion of this topic easier.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for= draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>


A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-rtcweb-plan
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Plan B: a proposal for signaling = multiple media sources in WebRTC.
Creation date: =C2=A0 2013-05-03
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 15
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:= //www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatracker.ie= tf.org/doc/draft-uberti-rtcweb-plan
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/d= raft-uberti-rtcweb-plan-00


Abstract:
=C2=A0 =C2=A0This document explains how multiple media sources can be signa= led in
=C2=A0 =C2=A0WebRTC using SDP, in a fashion that avoids many common problem= s and
=C2=A0 =C2=A0provides a simple control surface to the receiver.




The IETF Secretariat



--90e6ba6e8b502a062404dbca3051-- From prvs=4835715ece=christer.holmberg@ericsson.com Thu May 2 23:22:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A4921F92EF for ; Thu, 2 May 2013 23:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iEAKszcbuJj for ; Thu, 2 May 2013 23:22:25 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D49A021F939C for ; Thu, 2 May 2013 23:22:23 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-32-5183579e44de Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 22.7E.28165.E9753815; Fri, 3 May 2013 08:22:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Fri, 3 May 2013 08:22:22 +0200 From: Christer Holmberg To: Bernard Aboba , "Dale R. Worley" Thread-Topic: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? Thread-Index: Ac5FpkrHryzI/aQNT0iUvXy00zH5hwADtcYAAAPFvoAAAQhZgAA4imSAABwqMXAABklLyAAANmRgABmo8HEABBaqAAAGjJaw Date: Fri, 3 May 2013 06:22:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369FB5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se>, <517FFB7E.8050801@alum.mit.edu>, , <51801BBD.1010505@alum.mit.edu>, , , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se>, <201305030115.r431Fis33999826@shell01.TheWorld.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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C369FB5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvre688OZAg+MLFCz2L7nMbDF1+WMW i5cnyhyYPSbv/8rs8bjnDJvHkiU/mQKYo7htkhJLyoIz0/P07RK4M27/fMJU0B9R0fvlM2sD 4yvfLkYODgkBE4mZl/i6GDmBTDGJC/fWs3UxcnEICRxmlDg1p4UZwlnMKHGwq5cVpIFNwEKi +582iCkiECaxdHMEiMksoC5xdXEQyBhhARuJph07mUFsEQFbiSn3brBDVOdJbGuvBwmzCKhI nJ33lhHE5hXwlejpPcwKsWgTi8SG26fYQBKcAtYS16cuBZvDCHTa91NrmEBsZgFxiVtP5jNB nCwgsWTPeWYIW1Ti5eN/rBC2osTV6cuh6vMl1v7uh1omKHFy5hOWCYyis5CMmoWkbBaSMoi4 jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03MTMnvdxwEyMwwg5u+a27g/HUOZFDjNIc LErivElcjYFCAumJJanZqakFqUXxRaU5qcWHGJk4OEEEl1QDo4VdanCp+40Vt8PuuIUpLUkp C7BSmGzcvIpl1oE+rRNR09iOd/pLrV5933zfltsHL782Y1A9mmfv8F1Ibe/7EzuC1SQ/sup4 btXf+nWF5db4+qSk9d6u5/Wdjs48c++RP6fJ/DnTT98y+R3CZnjAa8dl/+R/TL7cdwRPnQ0J 3MirIWmT3ZU3SYmlOCPRUIu5qDgRAA2nocODAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 06:22:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C369FB5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernard, I am not suggesting a deviation from RFC 5761. As the text says, the initial offer must contain candidates also for RTCP, = as it is still now known whether the answerer will support rtcp-mux. My suggestion is to mandate BUNDLE entities to support rtcp-mux. Regards, Christer From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: 3. toukokuuta 2013 8:13 To: Dale R. Worley; Christer Holmberg Cc: mmusic@ietf.org Subject: RE: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? > But it doesn't seem that there is much to gain by mandating rtcp-mux > in the first offer/answer, the one where actual bundling is not being > done. All of the RTP/RTCP routing code that is active at that point > has to support non-rtcp-mux operation already. [BA] Support for rtcp-mux in the first offer/answer is mandated by RFC 576= 1 Section 5.1.3: The initial SDP offer MUST include this attribute at the media level to request multiplexing of RTP and RTCP on a single port. [RFC5761] Section 5.1.3 also requires a fallback port for RTCP in the offe= r, in case the answerer doesn't support RTCP-mux: If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=3Drtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=3Dcandidate:" lines for both RTP and RTCP along with an "a=3Drtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired. Given the existing normative text, and all the other problems we need to s= olve, I think the burden of proof is on those who advocate deviation from R= FC 5761. --_000_7594FB04B1934943A5C02806D1A2204B1C369FB5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bernard,

 <= /p>

I am not suggesting a dev= iation from RFC 5761.

 <= /p>

As the text says, the ini= tial offer must contain candidates also for RTCP, as it is still now known = whether the answerer will support rtcp-mux.

 <= /p>

My suggestion is to manda= te BUNDLE entities to support rtcp-mux.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: 3. toukokuuta 2013 8:13
To: Dale R. Worley; Christer Holmberg
Cc: mmusic@ietf.org
Subject: RE: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

 

> But it doesn't seem that there is much to gain by m= andating rtcp-mux

> in the first offer/answer, the one where actual bun= dling is not being
> done. All of the RTP/RTCP routing code that is active at that point > has to support non-rtcp-mux operation already.

 

[BA]  Support for rtcp-mux in the first offer/= answer is mandated by RFC 5761 Section 5.1.3:

 

&n=
bsp;  The initial SDP offer MUST include this
&n=
bsp;  attribute at the media level to request multiplexing of RTP and =
RTCP
&n=
bsp;  on a single port.

 

[RFC5761]  Section 5.1.3 also requires a fallback p= ort for RTCP in the offer, in case the answerer doesn't support RTCP-mux:&n= bsp; 

 

&n=
bsp;  If it is desired to use both ICE and multiplexed RTP and RTCP, t=
he
&n=
bsp;  initial offer MUST contain an "a=3Drtcp-mux" attribute=
 to indicate that
&n=
bsp;  RTP and RTCP multiplexing is desired and MUST contain "a=3D=
candidate:"
&n=
bsp;  lines for both RTP and RTCP along with an "a=3Drtcp:" =
line indicating a
&n=
bsp;  fallback port for RTCP in the case that the answerer does not su=
pport
&n=
bsp;  RTP and RTCP multiplexing.  This MUST be done for each medi=
a where
&n=
bsp;  RTP and RTCP multiplexing is desired.

 
Given the existing nor=
mative text,  and all the other problems we need to solve, I think the=
 burden of proof is on those who advocate deviation from RFC 5761. 
--_000_7594FB04B1934943A5C02806D1A2204B1C369FB5ESESSMB209erics_-- From prvs=4835715ece=christer.holmberg@ericsson.com Thu May 2 23:39:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A08021F84F6 for ; Thu, 2 May 2013 23:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.715 X-Spam-Level: X-Spam-Status: No, score=-5.715 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giBzRXohl5Rw for ; Thu, 2 May 2013 23:39:11 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 875E721F84D6 for ; Thu, 2 May 2013 23:39:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-71-51835b8d4cdc Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 53.50.28165.D8B53815; Fri, 3 May 2013 08:39:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Fri, 3 May 2013 08:39:09 +0200 From: Christer Holmberg To: Justin Uberti , =?utf-8?B?R3VzdGF2byBHYXJjw61h?= Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpmC/JMg42bB/EOYWhKkPbD8pZjwrh2AgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIAACOAAgADN64CAAC2u8A== Date: Fri, 3 May 2013 06:39:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369FE3@ESESSMB209.ericsson.se> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C369FE3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Vrc3ujnQYNpJDYuZra0sFpOn7mS0 2DpVyGLq8scsFis2HGB1YPX4+/4Dk8fOWXfZPRZsKvVYsuQnk8eNuzeZAlijuG2SEkvKgjPT 8/TtErgzNpyzKlj0hLGiZdkMpgbGBfcYuxg5OSQETCQmz7rDBGGLSVy4t56ti5GLQ0jgMKNE 67QrjBDOYkaJLytnADkcHGwCFhLd/7RBGkQEoiVW3usHG8QsUCWx+0wTO4gtLGAnMWN+BxNE jb3E2Y5FbBB2lsT0bztZQMawCKhI7N1QABLmFfCVWHZtLhPEqgUsEp2f1jGDJDgFAiXu3jsL 1ssIdNz3U2uYIHaJS9x6Mh/qaAGJJXvOM0PYohIvH/9jhbAVJa5OXw5Vny+x5WkLE8QyQYmT M5+wTGAUnYVk1CwkZbOQlM0COpVZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2Jkz03M zEkvN9zECIzGg1t+6+5gPHVO5BCjNAeLkjhvEldjoJBAemJJanZqakFqUXxRaU5q8SFGJg5O EMEl1cDI6f7LTlvXLXNvn7zlAj0HjndbJ7l/uxH01jNi6f5bzqwlhf+7EvhPVN/IWbvibmKG fMr7lGtr9jIq3fjpfMade+ffRS98vlkopB2+8+n6o2prNVO3GR23X5y9c4Kh0mvlTPl1DyWU +zZU1NzeaMjJvOvslt+aH/Y7/rCrFjeJu6c2cWW2LJurEktxRqKhFnNRcSIAKngL5ZkCAAA= Cc: Alan Johnston , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 06:39:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C369FE3ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpBcmUgeW91IHRhbGtpbmcgYWJvdXQgRFRMUy1TUlRQIG9ubHksIG9yIG1v cmUgZ2VuZXJhbD8NCg0KSWYgSSB1bmRlcnN0b29kIHlvdSBjb3JyZWN0bHksIHdoYXQgeW91IHN1 Z2dlc3QgaXMgd2hhdCBSRkMgNDU3MiBzYXlzLCBpZSB0aGF0IHRoZSBUTFMgcm9sZSBpcyBkZXRl cm1pbmVkIGJhc2VkIG9uIHRoZSBzZXR1cCByb2xlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQpGcm9tOiBtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogMy4gdG91a29rdXV0YSAy MDEzIDg6NTQNClRvOiBHdXN0YXZvIEdhcmPDrWENCkNjOiBBbGFuIEpvaG5zdG9uOyBtbXVzaWNA aWV0Zi5vcmc7IFBhdWwgS3l6aXZhdA0KU3ViamVjdDogUmU6IFtNTVVTSUNdIERUTFMtU1JUUCBj bGllbnQvc2VydmVyIHJvbGUgbmVnb3RpYXRpb24NCg0KVGhpcyBpcyB3aGVyZSB0aGUgT1AncyBx dWVzdGlvbiBjYW1lIGZyb20gLSB0aGUgZGlmZmVyaW5nIHBvbGljeSBiZXR3ZWVuIENocm9tZSBh bmQgRmlyZWZveC4gSSAocmVnYXJkaW5nIENocm9tZSkgaGFkIGZpZ3VyZWQgdGhhdCBpZiBJQ0Ug aGFkIG1hZGUgYSBkZXRlcm1pbmF0aW9uIHJlZ2FyZGluZyB3aGljaCBzaWRlIHdhcyBpbiBjaGFy Z2UsIHRoZSBvdGhlciBsYXllcnMgaW4gdGhlIHN0YWNrIHNob3VsZCBkbyB0aGUgc2FtZSwgYnV0 IGl0IHNvdW5kcyBsaWtlIHRoZXJlIGFyZSBhbHJlYWR5IGVzdGFibGlzaGVkIHJ1bGVzIG9uIGhv dyB0byBkbyB0aGlzLg0KDQpGcm9tIHRoaXMgdGhyZWFkLCBpdCBzb3VuZHMgbGlrZSB0aGUgcmVj b21tZW5kYXRpb24gaXMgdG8gdXNlIGE9c2V0dXA6YWN0cGFzcyBpbiB0aGUgb2ZmZXIsIGFuZCB0 aGVuIHRoZSBhbnN3ZXJlciBjYW4gdXNlIGE9c2V0dXA6YWN0aXZlIHRvIGNob29zZSB0aGUgY2xp ZW50IHJvbGUuIEluIDNwY2MgY2FzZXMsIHRoZSBCMkJVQSBjYW4gc2VsZWN0IGE9c2V0dXAgYXBw cm9wcmlhdGVseSB0byBhdm9pZCBhbnkgaXNzdWUuDQoNCklzIHRoYXQgYW4gYWNjdXJhdGUgc3Vt bWFyeSwgYW5kIGlzIHRoZXJlIGNvbnNlbnN1cyBvbiB0aGlzPw0KDQpPbiBUaHUsIE1heSAyLCAy MDEzIGF0IDEwOjM2IEFNLCBHdXN0YXZvIEdhcmPDrWEgPGdnYkB0b2tib3guY29tPG1haWx0bzpn Z2JAdG9rYm94LmNvbT4+IHdyb3RlOg0KSW4gcHJldmlvdXMgdmVyc2lvbnMgb2YgQ2hyb21lIHRo ZSBvZmZlcmVyIHdhcyBhbHdheXMgdGhlIERUTFMgc2VydmVyLg0KDQpJbiBuZXdlc3QgdmVyc2lv biBvZiBDaHJvbWUgdGhlIElDRSBjb250cm9sbGluZyBhZ2VudCBpcyBhbHdheXMgdGhlIERUTFMg c2VydmVyLiAgKGNvbnRyb2xsaW5nIGFuZCBvZmZlcmVyIGFyZSBub3QgdGhlIHNhbWUgaW4gY2Fz ZSBvZiBvZmZlcmVyIGJlaW5nIGljZS1saXRlIGltcGxlbWVudGF0aW9uKQ0KDQpJIHRoaW5rIGlu IGNhc2Ugb2YgM3BjYyB3ZSBuZWVkICJhPXNldHVwIiB3aXRoIHByb3h5L0IyQlVBIG1vZGlmeWlu ZyB0aGUgU0RQcyBvciB1c2luZyB0aGUgSUNFIHJvbGVzIHRvIHJlc29sdmUgdGhlIGNvbmZsaWN0 cy4gICAgSSBwcmVmZXIgdG8gbm90IHVzZSBJQ0UgdG8gc29sdmUgdGhpcyBhbmQgZGVjb3VwbGUg SUNFIGFuZCBEVExTIHJvbGVzLg0KDQpHLg0KDQpPbiAwMi8wNS8yMDEzLCBhdCAxMDowNSwgQWxh biBKb2huc3RvbiB3cm90ZToNCg0KPiBJbnRlcmVzdGluZ2x5LCBJIGhhdmUgeWV0IHRvIHNlZSBh bnkgYnJvd3NlciB1c2UgYT1zZXR1cCBmb3IgRFRMUy1TUlRQLiAgSXMgdGhpcyBhdHRyaWJ1dGUg cmVhbGx5IG5lZWRlZD8gIEhvdyBkbyB0aGluZ3Mgd29yayBpZiBvbmUgb3IgYm90aCBicm93c2Vy cyBkb24ndCBpbmNsdWRlIGl0Pw0KPg0KPiAtIEFsYW4gLQ0KPg0KPg0KPiBPbiBUaHUsIE1heSAy LCAyMDEzIGF0IDI6MTUgQU0sIFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCkgPGFsYnJlY2h0 LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzphbGJyZWNodC5zY2h3YXJ6QGFsY2F0 ZWwtbHVjZW50LmNvbT4+IHdyb3RlOg0KPiBUaGUgUkZDIHNpdHVhdGlvbiBpcyBub3QgcmVhbGx5 IGNsZWFyLCBldmVuIGNvbmZ1c2luZyBjb25jZXJuaW5nIGNsaWVudC9zZXJ2ZXIgcm9sZSBuZWdv dGlhdGlvbnMgKGluIGNhc2Ugb2YgdHJhbnNwb3J0IHNlY3VyaXR5IHNlc3Npb25zIG92ZXIgY29u bmVjdGlvbi1vcmllbnRlZCBJUCB0cmFuc3BvcnQgcHJvdG9jb2xzKS4NCj4NCj4NCj4NCj4gwrcg ICAgICAgICBSRkMgNDE0NSBpcyBvbmx5IGFib3V0IFRDUCwgaS5lLiwgVENQIGNsaWVudC9zZXJ2 ZXIgcm9sZSBhc3NpZ25tZW50cy4gVGh1cywgdGhlIFJGQyA0MTQ1IGludHJvZHVjZWQgU0RQIGF0 dHJpYnV0ZSBpcyBUQ1Agc3BlY2lmaWMuDQo+DQo+IMK3ICAgICAgICAgZHJhZnQtaWV0Zi1tbXVz aWMtc2N0cC1zZHA6IHNlZW1zIHRvIHByb2ZpbGUgdGhlIOKAnGE9c2V0dXA64oCdIGF0dHJpYnV0 ZSBmb3IgU0NUUCBwYXRoIGVzdGFibGlzaG1lbnQgZGlyZWN0aW9ucyDigKYgKD8pDQo+DQo+IMK3 ICAgICAgICAgUkZDIDU3NjMgdXNlcyB0aGUgVENQIFNEUCBhdHRyaWJ1dGUgZm9yIERUTFMgc2Vz c2lvbiBlc3RhYmxpc2htZW50LCBpLmUuIERUTFMgY2xpZW50L3NlcnZlciByb2xlIGFzc2lnbm1l bnRzOyB0aGF04oCZcyBhY3R1YWxseSBhIHNlbWFudGljYWwgY2hhbmdlIG9mIHRoaXMgU0RQIGVs ZW1lbnQgdnMgUkZDIDQxNDUNCj4NCj4NCj4NCj4g4oCmIGFuZCBEVExTIGlzIFRMUyBiYXNlZCwg bGVhZGluZyB0byB0aGUgcXVlc3Rpb24gb2Ygcm9sZS9hc3NpZ25tZW50cyBpbiBjYXNlIG9mIFRM Uy9UQ1Agc2Vzc2lvbnM/DQo+DQo+IEkuZS4sIHRoZSBUQ1AgY2xpZW50L3NlcnZlciBhbmQgYWxz byBUTFMgY2xpZW50L3NlcnZlciByb2xlcz8gS2VlcGluZyBpbiBtaW5kIHRoYXQgdGhlIHJvbGUg YXNzaWdubWVudHMgYXQgSVAgdHJhbnNwb3J0IGxheWVyIGFuZCBzZWN1cml0eSBzZXNzaW9uIGxh eWVyICBtYXkgcHJpbmNpcGFsbHkgYmUgZGlmZmVyZW50IQ0KPg0KPg0KPg0KPiBUaGUg4oCcYT1z ZXR1cOKAnSBkZWZpbml0aW9uIGJ5IFJGQyA0MTQ1IGlzIHVuZm9ydHVuYXRlIGluIG15IG9waW5p b24uDQo+DQo+IFJlcXVpcmVkIHNlZW1zIHRvIGJlIGEgZ2VuZXJpYyBTRFAgc3BlY2lmaWNhdGlv biAoaS5lLiwgb3V0c2lkZSBSRkMgNDE0NSksIHdoaWNoIG1heSBiZSB0aGVuIHRpZ2h0IHRvIHRo ZSBjb25jZXJuZWQgcHJvdG9jb2wuIFN0aCBsaWtlIGFuIGV4cGxpY2l0IGluZGljYXRpb24g4oCc YT1zZXR1cDpQUk9UT0NPTDrigJ0gb3IgYW4gaW1wbGljaXQgaW5kaWNhdGlvbiBieSBhZGRpbmcg YW4gaWRlbnRpZmllci4NCj4NCj4NCj4NCj4gVGhlIOKAnG094oCdIGxpbmUgPHByb3RvPiBlbGVt ZW50IGRvZXMgbm90IHJlYWxseSBoZWxwIHRvIHJlZHVjZSBhbWJpZ3VpdHkgKGFzIFBhdWwgcmVt aW5kZWQgYWdhaW46IOKAnOKAnFVuZm9ydHVuYXRlbHkgU0RQIGhhcyBhIHByZXR0eSBjb25mdXNp bmcgaWRlYSBvZiAidHJhbnNwb3J0Ii4gVGhlIHByb3RvIGZpZWxkIGlkZW50aWZpZXMgYSB3aG9s ZSBzdGFjayBvZiBwcm90b2NvbCBsYXllcnMu4oCdKS4NCj4NCj4NCj4NCj4gQWxicmVjaHQNCj4N Cj4gUFMNCj4NCj4gSSB3b3VsZCBzZWUgZm9sbG93aW5nIHBhcmFtZXRlciB2YWx1ZXMgZm9yIGEg U0RQIOKAnGE9c2V0dXA6UFJPVE9DT0w64oCdIGF0dHJpYnV0ZSBleHRlbnNpb246DQo+DQo+IEw0 OiBUQ1AsIFNDVFAsIERDQ1AoPykNCj4NCj4gTDQrOiBUTFMsIERUTFMsIERUTFMtU1JUUCg/LCBk dWUgdG8gUkZDIDU3NjQgU0RQIHByb2ZpbGluZyDigKYpDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+ IEZyb206IG1tdXNpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRm Lm9yZz4gW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bW11c2ljLWJvdW5j ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTW8gWmFuYXR5IChtemFuYXR5KQ0KPiBTZW50OiBE b25uZXJzdGFnLCAyLiBNYWkgMjAxMyAwNjowNA0KPiBUbzogSnVzdGluIFViZXJ0aQ0KPiBDYzog UGF1bCBLeXppdmF0OyBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCj4g U3ViamVjdDogUmU6IFtNTVVTSUNdIERUTFMtU1JUUCBjbGllbnQvc2VydmVyIHJvbGUgbmVnb3Rp YXRpb24NCj4NCj4NCj4NCj4gQSBzaW1wbGUgM1BDQy9CMkJVQSBvbmx5IGRlbGF5cyBvZmZlcnMg dG93YXJkIG9uZSBsZWcgbGlrZSBSRkMzNzI1LCBzbyB0aGUgb3RoZXIgbGVnIHdpbGwgYW5zd2Vy IHdpdGggYWN0aXZlIG9yIHBhc3NpdmUgYnV0IG5vdCBhY3RwYXNzLg0KPg0KPg0KPg0KPiBBIGNv bXBsZXggM1BDQy9CMkJVQSBkZWxheXMgb2ZmZXJzIHRvd2FyZCBib3RoIGxlZ3MsIHNvIGl0IG11 c3QgYW5hbHl6ZSBhbmQgYWx0ZXIgU0RQIGluIGNvbXBsZXggd2F5cyB0byBnZW5lcmF0ZSB0d28g YW5zd2VycyBmcm9tIHR3byBvZmZlcnMsIHBhcnQgb2Ygd2hpY2ggaXMgZGVjaWRpbmcgd2hpY2gg YW5zd2VyIHNob3VsZCBiZWNvbWUgYWN0aXZlIGFuZCB3aGljaCBzaG91bGQgYmVjb21lIHBhc3Np dmUuDQo+DQo+DQo+DQo+IFRoZSBmbG93IGluIFJGQyA1MjQ1IEIuMTEgaXMgb3ZlcnNpbXBsaWZp ZWQuIFNEUCBjYW4ndCBiZSBmb3J3YXJkZWQgdW5hbHRlcmVkIGJ5IGEgQjJCVUEgd2hpY2ggZGVs YXlzIG9mZmVycyBvbiBib3RoIGxlZ3MuIEdlbmVyYXRpbmcgdHdvIGFuc3dlcnMgZnJvbSB0d28g b2ZmZXJzIGlzIG11Y2ggbW9yZSBjb21wbGV4IHRoYW4gc2ltcGx5IGZvcndhcmRpbmcgdGhlIG9m ZmVycyBhcyBhbnN3ZXJzLg0KPg0KPg0KPg0KPiBEVExTLVNSVFAgaXMgYWN0dWFsbHkgYW4gZWFz eSBjYXNlIHNpbmNlIFJGQyA1NzYzIHJlcXVpcmVzIG9mZmVycyB0byBiZSBhY3RwYXNzLiBUQ1Ag aXMgaGFyZGVyIHNpbmNlIFJGQyA0MTQ1IGFsbG93cyBvZmZlcnMgdG8gYmUgYWN0aXZlLCBwYXNz aXZlLCBvciBhY3RwYXNzLCBjYXVzaW5nIG1vcmUgY29tcGxleCByZWludml0ZXMgdG8gcmVzb2x2 ZSBhY3RpdmUvYWN0aXZlIG9yIHBhc3NpdmUvcGFzc2l2ZSBjb25mbGljdHMuDQo+DQo+DQo+DQo+ IE1vDQo+DQo+DQo+DQo+IE9uIE1heSAxLCAyMDEzLCBhdCA2OjI4IFBNLCAiSnVzdGluIFViZXJ0 aSIgPGp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6 DQo+DQo+IEkgdGhpbmsgUGF1bCBtZWFucyB0aGUgYWN0aXZlL3Bhc3NpdmUgYXR0cmlidXRlcyBp biBSRkMgNTc2MywgYnV0IEknbSBzdGlsbCBub3Qgc3VyZSBhYm91dCBob3cgM3JkIHBhcnR5IGNh bGwgY29udHJvbCB3b3VsZCBiZSBoYW5kbGVkIGluIHRoaXMgY2FzZSwgaS5lLiB3aGVuIGJvdGgg ZW5kcG9pbnRzIHRoaW5rIHRoZXkgYXJlIG9mZmVyZXJzIGFuZCBzZXQgYT1zZXR1cDphY3RwYXNz Lg0KPg0KPg0KPg0KPiBJQ0UgaGFzIGxvZ2ljIHRvIGRldGVybWluZSByb2xlcyBpbiB0aGlzIHNj ZW5hcmlvLCBhcyBzaG93cyBpbiBSRkMgNTI0NSwgQi4xMS4NCj4NCj4NCj4NCj4gT24gV2VkLCBN YXkgMSwgMjAxMyBhdCAyOjEwIFBNLCBHdXN0YXZvIEdhcmPDrWEgPGdnYkB0b2tib3guY29tPG1h aWx0bzpnZ2JAdG9rYm94LmNvbT4+IHdyb3RlOg0KPg0KPiBJIHNhdyBpdCwgYnV0IHRoYXQgaXMg YWxsIGFib3V0IFRDUCBjbGllbnQvc2VydmVyIHJvbGUgYW5kIG5vdCBEVExTIGNsaWVudC9zZXJ2 ZXIgcm9sZS4gICBBcmUgd2Ugc3VwcG9zZWQgdG8gdXNlIHRoZSBzYW1lICJzZXR1cCIgYXR0cmli dXRlIGZvciBkdGxzIHJvbGUgbmVnb3RpYXRpb24gZXZlbiBpZiBpdCBpcyBvdmVyIFVEUD8NCj4N Cj4gSSB0aGluayB0aGVyZSBpcyBubyByZWFzb24gdG8gdGllIFRDUCBhbmQgRFRMUyByb2xlcywg YnV0IHBlcmhhcHMgSSdtIG1pc3VuZGVyc3RhbmRpbmcgc29tZXRoaW5nLg0KPg0KPg0KPiBPbiAw MS8wNS8yMDEzLCBhdCAxMzo1NiwgUGF1bCBLeXppdmF0IHdyb3RlOg0KPg0KPiA+IE9uIDUvMS8x MyAyOjI2IFBNLCBHdXN0YXZvIEdhcmPDrWEgd3JvdGU6DQo+ID4+IFJGQzU3NjQgKERUTFMtU1JU UCkgc3RhdGVzIHRoYXQgIldoaWNoIHNpZGUgaXMgdGhlIERUTFMgY2xpZW50IGFuZCB3aGljaCBz aWRlIGlzIHRoZSBEVExTIHNlcnZlciBtdXN0IGJlIGVzdGFibGlzaGVkIHZpYSBzb21lIG91dC1v Zi1iYW5kIG1lY2hhbmlzbSBzdWNoIGFzIFNEUC4iDQo+ID4+DQo+ID4+IFdoYXQgaXMgdGhlIHNw ZWNpZmljYXRpb24gb24gaG93IHRvIHNpZ25hbCB0aGF0IGluIFNEUD8NCj4gPj4NCj4gPj4gU3Bl Y2lmaWNhbGx5IGluIGNhc2Ugb2YgM3BjYyB3aGVyZSBib3RoIGVuZHBvaW50cyBhcmUgU0RQIG9m ZmVyZXJzIHdoaWNoIG9uZSBzaG91bGQgdGFrZSB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgcm9sZXMg Zm9yIERUTFM/ICAgIFNob3VsZCB3ZSB0aWUgdGhhdCByb2xlIHRvIElDRSBjb250cm9sbGVkL2Nv bnRyb2xsaW5nIHJvbGVzIG9yIHNob3VsZCB3ZSBuZWdvdGlhdGUgaXQgaW4gdGhlIFNEUCBzb21l aG93Pw0KPiA+DQo+ID4gU2VlIFJGQzQxNDUuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4g PiBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+ IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPg0KPg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0 DQo+IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0 DQo+IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0 DQo+IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2lj QGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1C369FE3ESESSMB209erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSnVz dGluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QXJlIHlvdSB0YWxraW5nIGFib3V0IERUTFMtU1JUUCBvbmx5LCBvciBt b3JlIGdlbmVyYWw/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBJIHVuZGVyc3Rvb2QgeW91IGNvcnJlY3RseSwgd2hh dCB5b3Ugc3VnZ2VzdCBpcyB3aGF0IFJGQyA0NTcyIHNheXMsIGllIHRoYXQgdGhlIFRMUyByb2xl IGlzIGRldGVybWluZWQgYmFzZWQgb24gdGhlIHNldHVwIHJvbGUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5TZW50Ojwv Yj4gMy4gdG91a29rdXV0YSAyMDEzIDg6NTQ8YnI+DQo8Yj5Ubzo8L2I+IEd1c3Rhdm8gR2FyY8Ot YTxicj4NCjxiPkNjOjwvYj4gQWxhbiBKb2huc3RvbjsgbW11c2ljQGlldGYub3JnOyBQYXVsIEt5 eml2YXQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIERUTFMtU1JUUCBjbGllbnQv c2VydmVyIHJvbGUgbmVnb3RpYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIGlzIHdoZXJlIHRoZSBPUCdzIHF1ZXN0aW9uIGNhbWUgZnJvbSAtIHRoZSBkaWZm ZXJpbmcgcG9saWN5IGJldHdlZW4gQ2hyb21lIGFuZCBGaXJlZm94LiBJIChyZWdhcmRpbmcgQ2hy b21lKSBoYWQgZmlndXJlZCB0aGF0IGlmIElDRSBoYWQgbWFkZSBhIGRldGVybWluYXRpb24gcmVn YXJkaW5nIHdoaWNoIHNpZGUgd2FzIGluIGNoYXJnZSwgdGhlIG90aGVyIGxheWVycyBpbiB0aGUg c3RhY2sgc2hvdWxkDQogZG8gdGhlIHNhbWUsIGJ1dCBpdCBzb3VuZHMgbGlrZSB0aGVyZSBhcmUg YWxyZWFkeSBlc3RhYmxpc2hlZCBydWxlcyBvbiBob3cgdG8gZG8gdGhpcy48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb20gdGhpcyB0aHJlYWQsIGl0IHNv dW5kcyBsaWtlIHRoZSByZWNvbW1lbmRhdGlvbiBpcyB0byB1c2UgYT1zZXR1cDphY3RwYXNzIGlu IHRoZSBvZmZlciwgYW5kIHRoZW4gdGhlIGFuc3dlcmVyIGNhbiB1c2UgYT1zZXR1cDphY3RpdmUg dG8gY2hvb3NlIHRoZSBjbGllbnQgcm9sZS4gSW4gM3BjYyBjYXNlcywgdGhlIEIyQlVBIGNhbiBz ZWxlY3QgYT1zZXR1cCBhcHByb3ByaWF0ZWx5IHRvIGF2b2lkIGFueSBpc3N1ZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhhdCBhbiBh Y2N1cmF0ZSBzdW1tYXJ5LCBhbmQgaXMgdGhlcmUgY29uc2Vuc3VzIG9uIHRoaXM/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXkgMiwgMjAxMyBhdCAxMDozNiBBTSwgR3VzdGF2 byBHYXJjw61hICZsdDs8YSBocmVmPSJtYWlsdG86Z2diQHRva2JveC5jb20iIHRhcmdldD0iX2Js YW5rIj5nZ2JAdG9rYm94LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW4gcHJldmlvdXMgdmVyc2lvbnMgb2YgQ2hyb21lIHRoZSBvZmZlcmVy IHdhcyBhbHdheXMgdGhlIERUTFMgc2VydmVyLjxicj4NCjxicj4NCkluIG5ld2VzdCB2ZXJzaW9u IG9mIENocm9tZSB0aGUgSUNFIGNvbnRyb2xsaW5nIGFnZW50IGlzIGFsd2F5cyB0aGUgRFRMUyBz ZXJ2ZXIuICZuYnNwOyhjb250cm9sbGluZyBhbmQgb2ZmZXJlciBhcmUgbm90IHRoZSBzYW1lIGlu IGNhc2Ugb2Ygb2ZmZXJlciBiZWluZyBpY2UtbGl0ZSBpbXBsZW1lbnRhdGlvbik8YnI+DQo8YnI+ DQpJIHRoaW5rIGluIGNhc2Ugb2YgM3BjYyB3ZSBuZWVkICZxdW90O2E9c2V0dXAmcXVvdDsgd2l0 aCBwcm94eS9CMkJVQSBtb2RpZnlpbmcgdGhlIFNEUHMgb3IgdXNpbmcgdGhlIElDRSByb2xlcyB0 byByZXNvbHZlIHRoZSBjb25mbGljdHMuICZuYnNwOyAmbmJzcDtJIHByZWZlciB0byBub3QgdXNl IElDRSB0byBzb2x2ZSB0aGlzIGFuZCBkZWNvdXBsZSBJQ0UgYW5kIERUTFMgcm9sZXMuPGJyPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkcu PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KT24gMDIvMDUvMjAxMywgYXQgMTA6MDUsIEFsYW4gSm9obnN0b24gd3Jv dGU6PGJyPg0KPGJyPg0KJmd0OyBJbnRlcmVzdGluZ2x5LCBJIGhhdmUgeWV0IHRvIHNlZSBhbnkg YnJvd3NlciB1c2UgYT1zZXR1cCBmb3IgRFRMUy1TUlRQLiAmbmJzcDtJcyB0aGlzIGF0dHJpYnV0 ZSByZWFsbHkgbmVlZGVkPyAmbmJzcDtIb3cgZG8gdGhpbmdzIHdvcmsgaWYgb25lIG9yIGJvdGgg YnJvd3NlcnMgZG9uJ3QgaW5jbHVkZSBpdD88YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIEFsYW4gLTxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBUaHUsIE1heSAyLCAyMDEzIGF0IDI6MTUg QU0sIFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCkgJmx0OzxhIGhyZWY9Im1haWx0bzphbGJy ZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbSI+YWxicmVjaHQuc2Nod2FyekBhbGNhdGVs LWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFRoZSBSRkMgc2l0dWF0aW9uIGlz IG5vdCByZWFsbHkgY2xlYXIsIGV2ZW4gY29uZnVzaW5nIGNvbmNlcm5pbmcgY2xpZW50L3NlcnZl ciByb2xlIG5lZ290aWF0aW9ucyAoaW4gY2FzZSBvZiB0cmFuc3BvcnQgc2VjdXJpdHkgc2Vzc2lv bnMgb3ZlciBjb25uZWN0aW9uLW9yaWVudGVkIElQIHRyYW5zcG9ydCBwcm90b2NvbHMpLjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwrcgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFJGQyA0MTQ1IGlzIG9ubHkgYWJvdXQgVENQLCBpLmUuLCBUQ1AgY2xpZW50L3Nl cnZlciByb2xlIGFzc2lnbm1lbnRzLiBUaHVzLCB0aGUgUkZDIDQxNDUgaW50cm9kdWNlZCBTRFAg YXR0cmlidXRlIGlzIFRDUCBzcGVjaWZpYy48YnI+DQomZ3Q7PGJyPg0KJmd0OyDCtyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHA6IHNlZW1zIHRv IHByb2ZpbGUgdGhlIOKAnGE9c2V0dXA64oCdIGF0dHJpYnV0ZSBmb3IgU0NUUCBwYXRoIGVzdGFi bGlzaG1lbnQgZGlyZWN0aW9ucyDigKYgKD8pPGJyPg0KJmd0Ozxicj4NCiZndDsgwrcgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJGQyA1NzYzIHVzZXMgdGhlIFRDUCBTRFAgYXR0cmlidXRl IGZvciBEVExTIHNlc3Npb24gZXN0YWJsaXNobWVudCwgaS5lLiBEVExTIGNsaWVudC9zZXJ2ZXIg cm9sZSBhc3NpZ25tZW50czsgdGhhdOKAmXMgYWN0dWFsbHkgYSBzZW1hbnRpY2FsIGNoYW5nZSBv ZiB0aGlzIFNEUCBlbGVtZW50IHZzIFJGQyA0MTQ1PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyDigKYgYW5kIERUTFMgaXMgVExTIGJhc2VkLCBsZWFkaW5nIHRvIHRoZSBx dWVzdGlvbiBvZiByb2xlL2Fzc2lnbm1lbnRzIGluIGNhc2Ugb2YgVExTL1RDUCBzZXNzaW9ucz88 YnI+DQomZ3Q7PGJyPg0KJmd0OyBJLmUuLCB0aGUgVENQIGNsaWVudC9zZXJ2ZXIgYW5kIGFsc28g VExTIGNsaWVudC9zZXJ2ZXIgcm9sZXM/IEtlZXBpbmcgaW4gbWluZCB0aGF0IHRoZSByb2xlIGFz c2lnbm1lbnRzIGF0IElQIHRyYW5zcG9ydCBsYXllciBhbmQgc2VjdXJpdHkgc2Vzc2lvbiBsYXll ciAmbmJzcDttYXkgcHJpbmNpcGFsbHkgYmUgZGlmZmVyZW50ITxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIOKAnGE9c2V0dXDigJ0gZGVmaW5pdGlvbiBieSBSRkMg NDE0NSBpcyB1bmZvcnR1bmF0ZSBpbiBteSBvcGluaW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJl cXVpcmVkIHNlZW1zIHRvIGJlIGEgZ2VuZXJpYyBTRFAgc3BlY2lmaWNhdGlvbiAoaS5lLiwgb3V0 c2lkZSBSRkMgNDE0NSksIHdoaWNoIG1heSBiZSB0aGVuIHRpZ2h0IHRvIHRoZSBjb25jZXJuZWQg cHJvdG9jb2wuIFN0aCBsaWtlIGFuIGV4cGxpY2l0IGluZGljYXRpb24g4oCcYT1zZXR1cDpQUk9U T0NPTDrigJ0gb3IgYW4gaW1wbGljaXQgaW5kaWNhdGlvbiBieSBhZGRpbmcgYW4gaWRlbnRpZmll ci48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSDigJxtPeKAnSBs aW5lICZsdDtwcm90byZndDsgZWxlbWVudCBkb2VzIG5vdCByZWFsbHkgaGVscCB0byByZWR1Y2Ug YW1iaWd1aXR5IChhcyBQYXVsIHJlbWluZGVkIGFnYWluOiDigJzigJxVbmZvcnR1bmF0ZWx5IFNE UCBoYXMgYSBwcmV0dHkgY29uZnVzaW5nIGlkZWEgb2YgJnF1b3Q7dHJhbnNwb3J0JnF1b3Q7LiBU aGUgcHJvdG8gZmllbGQgaWRlbnRpZmllcyBhIHdob2xlIHN0YWNrIG9mIHByb3RvY29sIGxheWVy cy7igJ0pLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQWxicmVjaHQ8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBQUzxicj4NCiZndDs8YnI+DQomZ3Q7IEkgd291bGQgc2VlIGZv bGxvd2luZyBwYXJhbWV0ZXIgdmFsdWVzIGZvciBhIFNEUCDigJxhPXNldHVwOlBST1RPQ09MOuKA nSBhdHRyaWJ1dGUgZXh0ZW5zaW9uOjxicj4NCiZndDs8YnI+DQomZ3Q7IEw0OiBUQ1AsIFNDVFAs IERDQ1AoPyk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBMNCYjNDM7OiBUTFMsIERUTFMsIERUTFMtU1JU UCg/LCBkdWUgdG8gUkZDIDU3NjQgU0RQIHByb2ZpbGluZyDigKYpPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnIj5tbXVz aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bW11c2ljLWJv dW5jZXNAaWV0Zi5vcmciPm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m IE1vIFphbmF0eSAobXphbmF0eSk8YnI+DQomZ3Q7IFNlbnQ6IERvbm5lcnN0YWcsIDIuIE1haSAy MDEzIDA2OjA0PGJyPg0KJmd0OyBUbzogSnVzdGluIFViZXJ0aTxicj4NCiZndDsgQ2M6IFBhdWwg S3l6aXZhdDsgPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3Jn PC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFtNTVVTSUNdIERUTFMtU1JUUCBjbGllbnQvc2Vy dmVyIHJvbGUgbmVnb3RpYXRpb248YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IEEgc2ltcGxlIDNQQ0MvQjJCVUEgb25seSBkZWxheXMgb2ZmZXJzIHRvd2FyZCBvbmUgbGVn IGxpa2UgUkZDMzcyNSwgc28gdGhlIG90aGVyIGxlZyB3aWxsIGFuc3dlciB3aXRoIGFjdGl2ZSBv ciBwYXNzaXZlIGJ1dCBub3QgYWN0cGFzcy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IEEgY29tcGxleCAzUENDL0IyQlVBIGRlbGF5cyBvZmZlcnMgdG93YXJkIGJvdGgg bGVncywgc28gaXQgbXVzdCBhbmFseXplIGFuZCBhbHRlciBTRFAgaW4gY29tcGxleCB3YXlzIHRv IGdlbmVyYXRlIHR3byBhbnN3ZXJzIGZyb20gdHdvIG9mZmVycywgcGFydCBvZiB3aGljaCBpcyBk ZWNpZGluZyB3aGljaCBhbnN3ZXIgc2hvdWxkIGJlY29tZSBhY3RpdmUgYW5kIHdoaWNoIHNob3Vs ZCBiZWNvbWUgcGFzc2l2ZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IFRoZSBmbG93IGluIFJGQyA1MjQ1IEIuMTEgaXMgb3ZlcnNpbXBsaWZpZWQuIFNEUCBjYW4ndCBi ZSBmb3J3YXJkZWQgdW5hbHRlcmVkIGJ5IGEgQjJCVUEgd2hpY2ggZGVsYXlzIG9mZmVycyBvbiBi b3RoIGxlZ3MuIEdlbmVyYXRpbmcgdHdvIGFuc3dlcnMgZnJvbSB0d28gb2ZmZXJzIGlzIG11Y2gg bW9yZSBjb21wbGV4IHRoYW4gc2ltcGx5IGZvcndhcmRpbmcgdGhlIG9mZmVycyBhcyBhbnN3ZXJz Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgRFRMUy1TUlRQIGlzIGFj dHVhbGx5IGFuIGVhc3kgY2FzZSBzaW5jZSBSRkMgNTc2MyByZXF1aXJlcyBvZmZlcnMgdG8gYmUg YWN0cGFzcy4gVENQIGlzIGhhcmRlciBzaW5jZSBSRkMgNDE0NSBhbGxvd3Mgb2ZmZXJzIHRvIGJl IGFjdGl2ZSwgcGFzc2l2ZSwgb3IgYWN0cGFzcywgY2F1c2luZyBtb3JlIGNvbXBsZXggcmVpbnZp dGVzIHRvIHJlc29sdmUgYWN0aXZlL2FjdGl2ZSBvciBwYXNzaXZlL3Bhc3NpdmUgY29uZmxpY3Rz Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgTW88YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIE1heSAxLCAyMDEzLCBhdCA2OjI4IFBNLCAm cXVvdDtKdXN0aW4gVWJlcnRpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29n bGUuY29tIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJIHRoaW5rIFBhdWwgbWVhbnMgdGhlIGFjdGl2ZS9wYXNzaXZlIGF0dHJpYnV0ZXMgaW4g UkZDIDU3NjMsIGJ1dCBJJ20gc3RpbGwgbm90IHN1cmUgYWJvdXQgaG93IDNyZCBwYXJ0eSBjYWxs IGNvbnRyb2wgd291bGQgYmUgaGFuZGxlZCBpbiB0aGlzIGNhc2UsIGkuZS4gd2hlbiBib3RoIGVu ZHBvaW50cyB0aGluayB0aGV5IGFyZSBvZmZlcmVycyBhbmQgc2V0IGE9c2V0dXA6YWN0cGFzcy48 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IElDRSBoYXMgbG9naWMgdG8g ZGV0ZXJtaW5lIHJvbGVzIGluIHRoaXMgc2NlbmFyaW8sIGFzIHNob3dzIGluIFJGQyA1MjQ1LCBC LjExLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gV2VkLCBNYXkg MSwgMjAxMyBhdCAyOjEwIFBNLCBHdXN0YXZvIEdhcmPDrWEgJmx0OzxhIGhyZWY9Im1haWx0bzpn Z2JAdG9rYm94LmNvbSI+Z2diQHRva2JveC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJIHNhdyBpdCwgYnV0IHRoYXQgaXMgYWxsIGFib3V0IFRDUCBjbGllbnQvc2VydmVy IHJvbGUgYW5kIG5vdCBEVExTIGNsaWVudC9zZXJ2ZXIgcm9sZS4gJm5ic3A7IEFyZSB3ZSBzdXBw b3NlZCB0byB1c2UgdGhlIHNhbWUgJnF1b3Q7c2V0dXAmcXVvdDsgYXR0cmlidXRlIGZvciBkdGxz IHJvbGUgbmVnb3RpYXRpb24gZXZlbiBpZiBpdCBpcyBvdmVyIFVEUD88YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJIHRoaW5rIHRoZXJlIGlzIG5vIHJlYXNvbiB0byB0aWUgVENQIGFuZCBEVExTIHJvbGVz LCBidXQgcGVyaGFwcyBJJ20gbWlzdW5kZXJzdGFuZGluZyBzb21ldGhpbmcuPGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IE9uIDAxLzA1LzIwMTMsIGF0IDEzOjU2LCBQYXVsIEt5eml2YXQg d3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBPbiA1LzEvMTMgMjoyNiBQTSwgR3VzdGF2 byBHYXJjw61hIHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsgUkZDNTc2NCAoRFRMUy1TUlRQKSBz dGF0ZXMgdGhhdCAmcXVvdDtXaGljaCBzaWRlIGlzIHRoZSBEVExTIGNsaWVudCBhbmQgd2hpY2gg c2lkZSBpcyB0aGUgRFRMUyBzZXJ2ZXIgbXVzdCBiZSBlc3RhYmxpc2hlZCB2aWEgc29tZSBvdXQt b2YtYmFuZCBtZWNoYW5pc20gc3VjaCBhcyBTRFAuJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsgV2hhdCBpcyB0aGUgc3BlY2lmaWNhdGlvbiBvbiBob3cgdG8gc2ln bmFsIHRoYXQgaW4gU0RQPzxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFNw ZWNpZmljYWxseSBpbiBjYXNlIG9mIDNwY2Mgd2hlcmUgYm90aCBlbmRwb2ludHMgYXJlIFNEUCBv ZmZlcmVycyB3aGljaCBvbmUgc2hvdWxkIHRha2UgdGhlIGNsaWVudCBhbmQgc2VydmVyIHJvbGVz IGZvciBEVExTPyAmbmJzcDsgJm5ic3A7U2hvdWxkIHdlIHRpZSB0aGF0IHJvbGUgdG8gSUNFIGNv bnRyb2xsZWQvY29udHJvbGxpbmcgcm9sZXMgb3Igc2hvdWxkIHdlIG5lZ290aWF0ZSBpdCBpbiB0 aGUgU0RQIHNvbWVob3c/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNlZSBSRkM0MTQ1 Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBtbXVzaWMgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0Bp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbW11 c2ljIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9y ZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyBtbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBo cmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11 c2ljPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbW11c2ljIG1haWxpbmcgbGlz dDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYu b3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21tdXNpYzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1t dXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5v cmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1C369FE3ESESSMB209erics_-- From prvs=4835715ece=christer.holmberg@ericsson.com Thu May 2 23:40:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2418721F93D8 for ; Thu, 2 May 2013 23:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00zA9bGT+rFb for ; Thu, 2 May 2013 23:39:56 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 935D221F93D3 for ; Thu, 2 May 2013 23:39:56 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-b3-51835bbb7ca4 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0A.81.32006.BBB53815; Fri, 3 May 2013 08:39:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Fri, 3 May 2013 08:39:54 +0200 From: Christer Holmberg To: Alan Johnston , "Schwarz, Albrecht (Albrecht)" Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpmC/JMg42bB/EOYWhKkPbD8pZjwrh2AgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIABBP8w Date: Fri, 3 May 2013 06:39:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369FF7@ESESSMB209.ericsson.se> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.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.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvre7u6OZAgxkTxC1mtrayWPxp/cVo MXX5YxaLFRsOsDqweLQ+28vq8ff9ByaPnbPusnssWfKTKYAlitsmKbGkLDgzPU/fLoE74/yM HqaC6UwVi/bNZWlgvMnYxcjJISFgIvHwzTIoW0ziwr31bF2MXBxCAocZJSZPf8sE4SwGcr7v Zu5i5OBgE7CQ6P6nDdIgIlAKFJ7OBGIzC/hKvP85nR3EFhawk5gxv4MJosZe4mzHIjYIO0ri yvtvLCA2i4CKxLaLk1hBbF6g3uNXTkHtWsossedjE9ggToFAiS3XNoA1MwJd9/3UGqhl4hK3 nsxngrhaQGLJnvPMELaoxMvH/1ghbEWJq9OXQ9XrSdyYOoUNwtaWWLbwNTPEYkGJkzOfsExg FJuFZOwsJC2zkLTMQtKygJFlFSN7bmJmTnq50SZGYDwd3PJbdQfjnXMihxilOViUxHmTuRoD hQTSE0tSs1NTC1KL4otKc1KLDzEycXCCCC6pBkaz999eb5n8JfBebvryxMC2y3dWFfrrdm6r nrF5ThiDfeTLfIfQqYe7nux2mrFpnnvbLebD0jaSgnXc9/2rd21IYvW3fF3leP1m/K8zzddM vd433d35ivdvgeqqz1kn/mdeaDLbYjZlQsJu+RnmaxJ+veA98q2qmed4n/fV6ktPk5tP7N1V 5/FYiaU4I9FQi7moOBEACC81g3oCAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 06:40:03 -0000 Hi Alan, > Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SRTP.= =A0Is this attribute really needed? =A0How do things work if one or both b= rowsers don't include it? How is the TLS role determined in the cases you've seen? Regards, Christer From prvs=68353fe77e=christer.holmberg@ericsson.com Thu May 2 23:59:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DABC21F8619 for ; Thu, 2 May 2013 23:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrxpKfirrY0y for ; Thu, 2 May 2013 23:59:02 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B8CFC21F8675 for ; Thu, 2 May 2013 23:59:00 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-8a-518360339320 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 98.B3.32006.33063815; Fri, 3 May 2013 08:58:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Fri, 3 May 2013 08:58:59 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpmC/JMg42bB/EOYWhKkPbD8pZjwrh2AgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIAAKEfF///lJwCAAPmFoA== Date: Fri, 3 May 2013 06:58:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36A026@ESESSMB209.ericsson.se> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> <5182A802.9020003@alum.mit.edu> In-Reply-To: <5182A802.9020003@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.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvra5xQnOgwd075hYzW1tZLP60/mK0 mLr8MYvFig0HWB1YPFqf7WX1+Pv+A5PHzll32T2WLPnJFMASxW2TlFhSFpyZnqdvl8Cdce/M fJaCDu6KZ//EGxgvcnQxcnJICJhIbJq8lRXCFpO4cG89WxcjF4eQwGFGiaN90xghnMWMEmdW TAPKcHCwCVhIdP/TBjFFBDQkJm1VAylhFpjFKDH95GZGkEHCAnYSM+Z3MIHYIgL2Emc7FrFB 2FkSK+b0gNksAioSm251sIPYvAK+EpMvdUMt7mSR+N47E+wiTgEdiU9LVoANYgS67vupNWA2 s4C4xK0n85kgrhaQWLLnPDOELSrx8vE/qG8UJa5OXw5VryOxYPcnNghbW2LZwtfMEIsFJU7O fMIygVFsFpKxs5C0zELSMgtJywJGllWM7LmJmTnp5UabGIHRdHDLb9UdjHfOiRxilOZgURLn TeZqDBQSSE8sSc1OTS1ILYovKs1JLT7EyMTBCSK4pBoYWeaJt/5UuBYsnPlrGouT7Oav36ZY 3MzeajA5QN4yIzhi5SpzJ/XoY+wyMa+UpjztP32i9GiX7CmfjCTFeKnvgk9WpViLrWCoemLc tOG87+q7RwJmM5+Zv0BfiyXn1QKv/ZG81rO2flh4ND6U7eNUtlesIdOFD6nteffv2FaHGw+l fk73aOfmUGIpzkg01GIuKk4EAIRymeJ5AgAA Cc: Alan Johnston , "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 06:59:08 -0000 Hi Paul, >> RFC 4572 specifies that the "active" endpoint also takes the role as TLS= client. At least MSRP refers to RFC 4572. >> >> AFAIR, BFCP specifies its own rule, saying that the SDP offerer always a= ct as TLS client - ie it separates the TCP setup from TLS roles - which I t= hink is very good. > > I think that approach has limitations. What does one do when doing a subs= equent o/a, especially in the opposite direction? Well, I could ask you to look it up in the BFCP RFC, but I doubt you'll fin= d an answer there :) > And how does one distinguish when in a subsequent o/a you do/don't want t= o reestablish the connection rather than retaining the existing one? I would need some more time to think about that, but a few questions that c= ame to my mind: 1) If the TLS connection already exists, is there a reason to reestablish i= t to begin with? 2) Would you need an o/a to reestablish the TLS connection to begin with? O= nce the roles have been determined (in the initial o/a), can't everything b= e handled on the TLS layer? 3) If the TLS connection already exists, is there a reason to renegotiate t= he TLS roles? 4) If a subsequent o/a is needed in order to reestablish the connection, an= d/or renegotiate the TLS roles, could the TLS connection first be terminate= d on the TLS layer, before the subsequent of/a is sent? Regards, Christer From internet-drafts@ietf.org Fri May 3 00:27:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934AE21F9488; Fri, 3 May 2013 00:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s85fGC97uWl; Fri, 3 May 2013 00:27:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0604821F942C; Fri, 3 May 2013 00:27:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130503072737.1258.75687.idtracker@ietfa.amsl.com> Date: Fri, 03 May 2013 00:27:37 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 07:27:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Miscellaneous Capabilities Negotiation in the Session De= scription Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-05.txt Pages : 21 Date : 2013-05-03 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line for each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps= -05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Simo.Veikkolainen@nokia.com Fri May 3 00:30:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB1021F93FC for ; Fri, 3 May 2013 00:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFA-gIcCv70E for ; Fri, 3 May 2013 00:29:57 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8A45C21F9488 for ; Fri, 3 May 2013 00:29:52 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r437TSDX011198; Fri, 3 May 2013 10:29:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 May 2013 10:29:37 +0300 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.126]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0328.011; Fri, 3 May 2013 07:29:37 +0000 From: To: , Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) Thread-Index: AQHOO3h4GI1XUw+H1UKVjshlEllXf5jjVzIggAPSQ4CAAR5VMIAK4NIQ Date: Fri, 3 May 2013 07:29:37 +0000 Message-ID: References: <514FA8F7.7060203@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> <5168A94B.20608@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> <516EB28A.1050003@cisco.com> <517956CB.2040701@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ivm4xbzrYVxIZLYcVE8MkpBpYSmhkAuQqQMGR/NKzjcJ6f+e0jPWCKW7SGpJea1HxF1+/yLcs1+3lx3oszWyEpFv854jwBDNm5uGBrLhHEq2uJVa1v3Zy3IaDHnDpP8YdeWJoIxth58+K+iDrSfX6VQ02aQvlegHvqg5/RXW70sT2gWMegB3w4ZokmZ6TonQusO76vvQMHR/vQU0QPUC11SVb40uqfcnkx/QGq/+rxh6PjGmIEYoBsFtbNHhKJpsDCi2sWHkj6c1vywSqwUPIuCiLtKIL2Gu8XWL0WJgw3GKD0xnlqe8LYUvX+UUenTVQQ== x-originating-ip: [172.21.81.226] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2013 07:29:37.0660 (UTC) FILETIME=[F781BBC0:01CE47CF] X-Nokia-AV: Clean Cc: jonathan@vidyo.com, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 07:30:02 -0000 I didn't find any additional comments on this, so I went ahead and changed = the paragraphs according to Flemming's proposal and submitted a new version= . Regards, Simo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Veikkolainen Simo (Nokia-CTO/Espoo) Sent: 26. huhtikuuta 2013 12:22 To: fandreas@cisco.com Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (d= raft-ietf-mmusic-sdp-miscellaneous-caps-04) See below [SV]. -----Original Message----- From: ext Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: 25. huhtikuuta 2013 19:16 To: Veikkolainen Simo (Nokia-CTO/Espoo) Cc: mohamed.boucadair@orange.com; aallen@blackberry.com; HKaplan@acmepacket= .com; jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (d= raft-ietf-mmusic-sdp-miscellaneous-caps-04) On 4/23/13 4:37 AM, Simo.Veikkolainen@nokia.com wrote: > Below the original and proposed text on the usage of ccap attribute in=20 > Section 3.1.2. of=20 > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > > This is pretty much the same text I proposed earlier, including Jonathan'= s wording on IN address families. > > --- begin original text --- > The 'ccap' capability attribute allows for expressing alternative > connection address ('c=3D') lines in SDP as part of the SDP capabilit= y > negotiation process. The 'ccap' capability attribute is intended to > be used only when there is no other mechanism available for > negotiating alternative connection address information, such as when > the is different among the alternative addresses (e.g. > "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in > situations where an existing mechanism (such as Interactive > Connectivity Establishment (ICE) [RFC5245]) can be used to select > between different connection addresses (e.g. "IP4" and "IP6" or > different IP addresses within the same IP address family). > --- end original text --- > > --- begin proposed text --- > The 'ccap' capability attribute is intended for offering > alternative connection addresses where the > is "IN" or "PSTN", i.e. selecting between an IP based > bearer or a circuit-switched bearer. > > The 'ccap' attribute MUST NOT be used to indicate more > than one address with an IN network type in actual > or potential configurations for any given media description > (e.g. between "IP4" and "IP6" address families or different > IP addresses within the same IP address family). > --- end proposed text--- I'm ok with the overall restriction but I think the opening wording is over= ly constraining. With that in mind, a slightly modified proposal below: The 'ccap' capability attribute allows for expressing alternative connection address ('c=3D') lines in SDP as part of the SDP capability negotiation process. One of the primary use cases for this is offering alternative connection addresses where the is "IN" or "PSTN", i.e., selecting between an IP based bearer or a circuit-switched bearer. By supporting the "IN" , the 'ccap' attribute enables the signalin= g of multiple IPv4 and IPv6 addresses, however the Standards Track mechanis= m for negotiation of alternative IP addresses in SDP is Interactive Connect= ivity Establishment (ICE) [RFC5245]. The 'ccap' attribute does not change t= hat and hence the combined set of actual and potential configurations (as d= efined in [RFC5939]) for any given media description MUST NOT use the 'ccap= ' attribute to negotiate more than one address with an IN network type (i.e= ., it is not permissible to select between "IP4" and "IP6" address families= or different IP addresses within the same IP address family). [SV] I think your proposal makes the intent clearer; I'll edit the text acc= ordingly. Simo > > Also, since no alternative port numbers can be offered, add this sentence= at the end the of the last paragraph to clarify how alternative IP and PST= N media descriptions are offered: > > This document does not define any mechanism for negotiating or > describing different port numbers and hence the port number from the > "m=3D" line MUST be used by default. Exceptions to this default can b= e > provided by extension mechanisms or network type specific rules. > This draft defines an exception when the network type is "PSTN", in > which case the port number is replaced with 9 (the "discard" port) as > described in Session Decription Protocol (SDP) Extension For Setting > Up Audio and Video Media Streams over Circuit-Switched Bearers in the > Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs]. > --- begin new text --- > An endpoint offering alternative IP and PSTN bearers MUST include the > IP media description in the actual configuration (IP address in the "= c=3D" line > and port number in the "m=3D" line), and the PSTN media descriptions = in the > potential configuration. > --- end new text --- Looks good. Thanks -- Flemming > Regards, > Simo > > > -----Original Message----- > From: ext Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: 17. huhtikuuta 2013 17:33 > To: mohamed.boucadair@orange.com > Cc: Veikkolainen Simo (Nokia-CTO/Espoo); aallen@blackberry.com;=20 > HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org;=20 > christer.holmberg@ericsson.com > Subject: Re: [MMUSIC] Connection Data Capability (ccap) and=20 > IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > > On 4/17/13 7:08 AM, mohamed.boucadair@orange.com wrote: >> Hi Felmming, >> >> Because it does not allow to indicate an alternate port number. > Correct - a connection address does not provide a port number; a differen= t capability would be needed for that. >> This makes it a no working solution for various scenarios. > No - it simply means that you would need to define another capability to = convey port numbers if you wanted such a solution (however we have ICE as t= he complete solution for that and the WG has not indicated a desire to chan= ge that). > >> The text which triggered this discussion was confusing. I hope the updat= ed version will be much more clear and reflect what have been discussion so= far in this thread. > I have asked Simo to update the draft. > > Thanks > > -- Flemming > > >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Flemming Andreasen [mailto:fandreas@cisco.com] Envoy=E9 : samedi >>> 13 avril 2013 02:40 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : >>> Simo.Veikkolainen@nokia.com; aallen@blackberry.com;=20 >>> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org;=20 >>> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection Data=20 >>> Capability (ccap) and IP-addresses >>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> >>> On 4/12/13 11:39 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Simo, >>>> >>>> I'm in favor of restricting the alternative address to PSTN. >>> Can you elaborate on why ? >>> >>> We have defined a generic connection data capability as part of a=20 >>> general capability negotiation framework. What's the point of that=20 >>> if the only value it can convey is PSTN ? >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>>> This is coherent whit your first bullet below. >>>> >>>> If you share the text changes you are proposing, this would be more >>> easier to review. >>>> Thanks for taking care of this issue. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De=20 >>>>> la part >>> de >>>>> Simo.Veikkolainen@nokia.com >>>>> Envoy=E9 : lundi 8 avril 2013 08:35 >>>>> =C0 : fandreas@cisco.com; aallen@blackberry.com;=20 >>>>> HKaplan@acmepacket.com Cc : jonathan@vidyo.com; mmusic@ietf.org;=20 >>>>> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection=20 >>>>> Data Capability (ccap) and IP-addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> Recapping the discussion so far: >>>>> >>>>> >>>>> - ICE is the way to negotiate between different IP addresses.=20 >>>>> There >>> seems >>>>> to be no disagreement here. >>>>> >>>>> - since no alternative port number can be expressed, in practice=20 >>>>> the IN address needs to go to the actual configuration (address in=20 >>>>> the c=3D line >>> and >>>>> port number in the m=3D line), and the alternative PSTN address in=20 >>>>> the potential configurations. Also here, there seems to be no disagre= ement. >>>>> >>>>> - then, whether the "ccap" attribute should be limited to carry=20 >>>>> only >>> PSTN >>>>> addresses, or also other types. I'm with Flemming on this one; SDP >>> capneg >>>>> framework is already fragmented enough, and limiting the=20 >>>>> connection >>> address >>>>> capability to PSTN addresses only would again be targeted for a=20 >>>>> single >>> use >>>>> case only, whereas we should strive for general solutions. >>>>> >>>>> Simo >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >>>>> Behalf >>> Of >>>>> ext Flemming Andreasen >>>>> Sent: 25. maaliskuuta 2013 3:32 >>>>> To: Andrew Allen >>>>> Cc: jonathan@vidyo.com; mmusic@ietf.org;=20 >>>>> christer.holmberg@ericsson.com >>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and=20 >>>>> IP-addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> >>>>> On 3/24/13 1:33 PM, Andrew Allen wrote: >>>>>> There is also nothing that prevents people from defining their=20 >>>>>> own >>>>> proprietary attributes to do such a thing but that is not part of=20 >>>>> an >>> IETF >>>>> standard and is not approved usage. >>>>> Agreed. >>>>> >>>>>> If we really feel the need to discourage further such usage I=20 >>>>>> suppose >>> we >>>>> could add some text stating that if CCAP s received containing an=20 >>>>> IN net type and an IN net type is present in the corresponding=20 >>>>> Connection Attribute then the CCAP attribute MUST be ignored. >>>>> I think that gets complicated quickly for a questionable gain. I'd=20 >>>>> prefer the "MUST NOT" described below with an explanation as to=20 >>>>> why it's there; as you note, ultimately people either decide to be=20 >>>>> spec compliant or not. >>>>> >>>>> -- Flemming >>>>>> That way compliant implementations would not perfom the=20 >>>>>> discouraged >>>>> behavior. >>>>>> Andrew >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >>>>>> To: Christer Holmberg >>>>>> Cc: Jonathan Lennox ; mmusic@ietf.org >>>>> >>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and I= P- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> In general I agree that having multiple ways of doing the same=20 >>>>>>> thing >>> is >>>>> not a good thing, and I don't have any strong feelings regarding=20 >>>>> the >>> ccap >>>>> usage. >>>>>>> But, no matter what we say, what would actually prevent people=20 >>>>>>> from >>>>> using ccap, in the same way they are using ANAT and altc? :) >>>>>> There's no port signaling capability with ccap, but other than=20 >>>>>> that, >>> the >>>>>> only thing that prevents people from using this to signal=20 >>>>>> alternative IP-addresses is the existence of a "MUST NOT" in the spe= c. >>>>>> >>>>>> -- Flemming >>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on=20 >>>>>>> behalf of >>>>> Jonathan Lennox [jonathan@vidyo.com] >>>>>>> Sent: Friday, 22 March 2013 10:00 PM >>>>>>> To: Flemming Andreasen >>>>>>> Cc: mmusic@ietf.org >>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>> Currently, the deployed SIP world has three mechanisms to allow=20 >>>>>>> some >>>>> flavor of negotiation among multiple IP addresses: ICE, altc=20 >>>>> (despite >>> the >>>>> general disapproval of the working group), and ANAT (despite its=20 >>>>> deprecation). >>>>>>> I think that adding ccap as a fourth member of this set would be=20 >>>>>>> a >>>>> terrible idea; and as far as I can tell, no one wants to do that. >>>>> So we need to make it clear that that it MUST NOT be used for that pu= rpose. >>>>>>> In the formulation below, I think I'd say that a given media >>> description >>>>> MUST NOT indicate more than one address with an IN network type,=20 >>>>> across >>> all >>>>> its configurations (actual and potential). >>>>>>> Obviously, different media descriptions (m=3D line blocks) can=20 >>>>>>> have >>>>> different addresses. >>>>>>> In practice, given the port number issue that started this=20 >>>>>>> thread, I >>>>> suspect this means that the SDP offer will need to put the IN=20 >>>>> address in the actual configuration (in the c=3D line), and the PSTN >>>>> address(es) will >>> be >>>>> in the potential configurations. >>>>>>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>>>>>> >>>>>>>> Still waiting for more comments on this, especially from the=20 >>>>>>>> people >>>>> that >>>>>>>> were very vocal in their complaints previously: Now is the time=20 >>>>>>>> to >>>>> speak up. >>>>>>>> Regardless, a few comments on the below: >>>>>>>> 1) It allows the use of "ccap" to be used to indicate one or=20 >>>>>>>> more >>> "IP4" >>>>>>>> addresses in a given SDP. >>>>>>>> 2) It allows the use of "ccap" to be used to indicate one or=20 >>>>>>>> more >>> "IP6" >>>>>>>> addresses in a given SDP. >>>>>>>> >>>>>>>> Nit-picking a bit on the actual text, which I think is important: >>>>>>>> The "ccap" attribute is not what is being to select between=20 >>>>>>>> different IP-addresses; the use of a "ccap" attribute in a=20 >>>>>>>> potential >>>>> configuration >>>>>>>> ("pcfg") is what is being used for this. Is the restriction=20 >>>>>>>> that we >>>>> want >>>>>>>> here: >>>>>>>> a) A potential configuration MUST NOT reference more than one "cca= p" >>>>>>>> attribute with a network type of "IN" ? >>>>>>>> b) All potential configurations for a particular media=20 >>>>>>>> description >>> MUST >>>>>>>> NOT reference more than one "ccap" attribute with a network=20 >>>>>>>> type of >>>>> "IN" ? >>>>>>>> c) Something else ? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>>>>>> I am OK with either of these proposals >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 >>>>>>>>> On >>>>> Behalf Of Simo.Veikkolainen@nokia.com >>>>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>>>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and=20 >>>>>>>>> IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>>> I went through the discussion, and my reading is that there is >>>>> agreement on not allowing ccap to be used for alternative IP=20 >>>>> address negotiation. >>>>>>>>> That could be made clear in the text e.g. by modifying the=20 >>>>>>>>> second >>>>> sentence Flemming quoted to read: >>>>>>>>> >>>>>>>>> The 'ccap' attribute MUST NOT be used to select >>>>>>>>> between different IP connection addresses (e.g. between >>>>>>>>> "IP4" and "IP6" address families or different IP address= es >>>>>>>>> within the same IP address family). >>>>>>>>> >>>>>>>>> >>>>>>>>> The ccap attribute should be able to carry either an IP or=20 >>>>>>>>> PSTN >>>>> address; that way either a PSTN or an IP bearer could be offered=20 >>>>> as the highest priority configuration (in the "m=3D" line). =20 >>>>> However, if we want >>> to >>>>> clarify the intended use of ccap, we could modify the first=20 >>>>> sentence to >>>>> read: >>>>>>>>> >>>>>>>>> The 'ccap' capability attribute is intended for offering >>>>>>>>> alternative connection addresses where the >>>>>>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>>>>>> bearer or a circuit-switched bearer. >>>>>>>>> >>>>>>>>> >>>>>>>>> Simo >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 >>>>>>>>> On >>>>> Behalf Of ext Flemming Andreasen >>>>>>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>>>>>> To: mmusic >>>>>>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and=20 >>>>>>>>> IP-addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>>> Greetings >>>>>>>>> >>>>>>>>> As you may have seen, there has recently been some list=20 >>>>>>>>> discussion >>> on >>>>> the "connection data capability" defined in >>>>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread=20 >>>>>>>>> in=20 >>>>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.h >>>>>>>>> t >>>>>>>>> ml) >>>>>>>>> >>>>>>>>> To recap, the connection data capability ("ccap") provides >>> capability >>>>> negotiation capabilities for what amounts to the "c=3D" line in=20 >>>>> regular >>> SDP, >>>>> and as such enables negotiation of network type (such as "IN") and >>>>> IP- address information (v4 and v6 addresses). The Standards Track=20 >>>>> mechanism for negotiating and determining alternative IP-address=20 >>>>> information today >>> is >>>>> ICE, and hence the draft currently includes the following wording: >>>>>>>>> >>>>>>>>> The 'ccap' capability attribute is intended to >>>>>>>>> be used only when there is no other mechanism available = for >>>>>>>>> negotiating alternative connection address=20 >>>>>>>>> information, such >>> as >>>>> when >>>>>>>>> the is different among the alternative=20 >>>>>>>>> addresses >>> (e.g. >>>>>>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used= in >>>>>>>>> situations where an existing mechanism (such as Interact= ive >>>>>>>>> Connectivity Establishment (ICE) [RFC5245]) can be=20 >>>>>>>>> used to >>>>> select >>>>>>>>> between different connection addresses (e.g. "IP4" and = "IP6" >>> or >>>>>>>>> different IP addresses within the same IP address family= ). >>>>>>>>> >>>>>>>>> >>>>>>>>> The above text has led to some confusion as to exactly when=20 >>>>>>>>> and what >>>>> "ccap" can be used for. More specifically, is it/should it ever be >>> allowed >>>>> to use "ccap" to convey an IP4 or IP6 address, and if so, under=20 >>>>> what circumstances ? >>>>>>>>> If you have an opinion, please let us know. >>>>>>>>> >>>>>>>>> A couple of points to keep in mind: >>>>>>>>> - The current document has been WGLC'ed without comment ~6=20 >>>>>>>>> months >>> ago. >>>>>>>>> - 3GPP has a dependency on the document (however I'm not sure=20 >>>>>>>>> if >>> that >>>>> dependency includes the above "IN" feature) >>>>>>>>> - The connection data capability is defined in a general=20 >>>>>>>>> manner to >>> be >>>>> generally useful in line with the overall capability negotiation >>> framework >>>>> (as opposed to targeted at one specific use case with one specific >>> value) >>>>>>>>> - There are scenarios where ICE cannot be used, even if=20 >>>>>>>>> implemented >>>>> (e.g. ice-mismatch). >>>>>>>>> - RFC 6849 (media loopback) provides for NAT traversal in the >>> absence >>>>> of ICE support >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> -- Flemming >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> - >>>>>>>>> ----- >>> - >>>>>>>>> This transmission (including any attachments) may contain >>> confidential >>>>> information, privileged material (including material protected by=20 >>>>> the solicitor-client or other applicable privileges), or=20 >>>>> constitute >>>>> non- >>> public >>>>> information. Any use of this information by anyone other than the >>> intended >>>>> recipient is prohibited. If you have received this transmission in >>> error, >>>>> please immediately reply to the sender and delete this information=20 >>>>> from your system. Use, dissemination, distribution, or=20 >>>>> reproduction of this transmission by unintended recipients is not=20 >>>>> authorized and may be unlawful. >>>>>>>>> . >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>>> >>>>>>> -- >>>>>>> Jonathan Lennox >>>>>>> jonathan@vidyo.com >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>> . >>>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>>> ----------------------------------------------------------------- >>>>>> - >>>>>> --- This transmission (including any attachments) may contain=20 >>>>>> confidential >>>>> information, privileged material (including material protected by=20 >>>>> the solicitor-client or other applicable privileges), or=20 >>>>> constitute >>>>> non- >>> public >>>>> information. Any use of this information by anyone other than the >>> intended >>>>> recipient is prohibited. If you have received this transmission in >>> error, >>>>> please immediately reply to the sender and delete this information=20 >>>>> from your system. Use, dissemination, distribution, or=20 >>>>> reproduction of this transmission by unintended recipients is not=20 >>>>> authorized and may be unlawful. >>>>>> . >>>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> . >>>> >> . >> > . > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Fri May 3 05:04:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C428921F93FB for ; Fri, 3 May 2013 05:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBTswjgCnvJA for ; Fri, 3 May 2013 05:04:21 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 720D821F8FF5 for ; Fri, 3 May 2013 05:04:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BE3839E129 for ; Fri, 3 May 2013 14:04:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksT4t2BInS6R for ; Fri, 3 May 2013 14:04:15 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B69F239E125 for ; Fri, 3 May 2013 14:04:15 +0200 (CEST) Message-ID: <5183A7BF.50903@alvestrand.no> Date: Fri, 03 May 2013 14:04:15 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> In-Reply-To: <201304261820.r3QIKq913501941@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 12:04:25 -0000 I support this proposal. On 04/26/2013 08:20 PM, Dale R. Worley wrote: >> From: Magnus Westerlund >> >> Regarding the IANA, Mo you have correctly identified the registry as >> closed and Adam pointed to the relevant text. Is this level of >> indirection so problematic that this registry needs a Note to the effect? > (cleaning up my proposal) > > I use the IANA registries as the reference for how the various number > spaces are managed. The current final rows of the Payload Types table > read: > > 35-71 Unassigned > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Unassigned > 96-127 dynamic [RFC3551] > > I find these to be problematic in several ways: > > 1) RFC 5761 is not mentioned at all, despite that it provides > important modifications of the governing text in RFC 3551. This is a > practical problem: Note that Adam quoted the text in RFC 3551, not > the text in RFC 5761, and the 3551 text is now incorrect. > > 2) The range that is reserved for RTCP avoidance is not specified > correctly. It's true that the rest of the RTCP avoidance range is > marked "Unassigned", but in the context of RFC 3551, that suggests > that they can be used as a secondary dynamic assignment area. > > 3) The range 35-71 should be marked more clearly as the secondary > dynamic assignment area. > > Because of this, I suggest the following changes to this registry: > > 1) The "Reference" section should be changed from "[RFC3551]" to > "[RFC5761][RFC3551]". > > 2) The final rows should be changed to > > 35-63 Unassigned/secondary dynamic area [RFC5761] > 64-71 Reserved for RTCP conflict avoidance [RFC5761] > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Reserved for RTCP conflict avoidance [RFC5761] > 96-127 Dynamic [RFC3551] > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From prvs=88353e42bc=christer.holmberg@ericsson.com Fri May 3 05:53:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB19F21F9642 for ; Fri, 3 May 2013 05:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeacRIDDIUAA for ; Fri, 3 May 2013 05:53:26 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7577F21F9640 for ; Fri, 3 May 2013 05:53:05 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-39-5183b33068da Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 76.1B.01956.033B3815; Fri, 3 May 2013 14:53:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Fri, 3 May 2013 14:53:03 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE Weekly Summary: Assumptions Thread-Index: Ac5H/Rv/zjNZSPPjTceQWRJyHaV9rQ== Date: Fri, 3 May 2013 12:53:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B485@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C36B485ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvra7B5uZAg0NdqhZTlz9mcWD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8bJLXkFjw0qvhz+ytzAeFyri5GTQ0LARGLmhUOsELaYxIV7 69m6GLk4hAQOM0q8n32WHcJZzCjR0/ufpYuRg4NNwEKi+582SIOIgLrE1709zCC2sIC2xKQL t1kg4gYSTZNvMIOUiwjoScy5IAJisgioSMzYUAFSwSvgK3F28QKwTkagtd9PrWECsZkFxCVu PZnPBHGOgMSSPeeZIWxRiZeP/0GdqShxdfpyqPp8iX8PlrBBzBSUODnzCcsERqFZSEbNQlI2 C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XInpuYmZNebr6JERjyB7f8NtjBuOm+ 2CFGaQ4WJXHeZK7GQCGB9MSS1OzU1ILUovii0pzU4kOMTBycIIJLqoFxPq/2VTFGjcDn91pW 9SpyCp7QcH2Y1X770IZPS79vLlTftNz2VMf+WUcWTFxq77Y8+syflKnhO9k31G95tdr1Ycun pT+d371ufTt5xp3590p+Ftl6N1pc9egrDYqY8E93o6DY7eR9WU4NXww+cvU6Sy7Y89B31/0d r817RX1un/ygmsJxfuqVI0osxRmJhlrMRcWJAFZM99RMAgAA Subject: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 12:53:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C36B485ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In order to try to close issues on BUNDLE, based on the discussions we've h= ad, I intend to update the BUNDLE draft based on the following assumptions: 1. We mandate usage of rtcp-mux when BUNDLE is used. 2. SDP m- lines with a zero port value MUST NOT be put inside a BUNDL= E group (not in an offer, nor in an answer). There will be a note indicatin= g that, due to this, the number of m- lines associated with a BUNDLE group = may differ between the offer and the associated answer. There will also be = a note indicating that this is due to RFC 5888, in case people later start = to wonder where the "MUST NOT" comes from. Please indicate if you OBJECT to any of these assumptions. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C36B485ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In order to try to close issues on BUNDLE, based on = the discussions we’ve had, I intend to update the BUNDLE draft based = on the following assumptions:

 

1.     &= nbsp; We mandate usage of rtcp-mux when BUNDLE is used.

 

2.     &= nbsp; SDP m- lines with a zero port value MUST NOT be put= inside a BUNDLE group (not in an offer, nor in an answer). There will be a= note indicating that, due to this, the number of m- lines associated with = a BUNDLE group may differ between the offer and the associated answer. There will also be a note indicating = that this is due to RFC 5888, in case people later start to wonder where th= e “MUST NOT” comes from.

 

Please indicate if you OBJECT to any of these assump= tions.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C36B485ESESSMB209erics_-- From prvs=98354f29d4=christer.holmberg@ericsson.com Fri May 3 06:07:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973A321F87B1 for ; Fri, 3 May 2013 06:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.15 X-Spam-Level: X-Spam-Status: No, score=-6.15 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC+e60+rbPF6 for ; Fri, 3 May 2013 06:07:03 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6481621F89A6 for ; Fri, 3 May 2013 06:07:02 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-24-5183b675ed7c Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C9.DC.01956.576B3815; Fri, 3 May 2013 15:07:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 3 May 2013 15:07:00 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Accept m- line, reject bundle Thread-Index: Ac5H/igNZNDXoaDWRAK0EIjSzLXMBA== Date: Fri, 3 May 2013 13:07:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C36B4F6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+JvrW7ptuZAgxlrxSymLn/M4sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7ozdP9+yFlxwr3gy9Q5jA+MSuy5GDg4JAROJhj8hXYycQKaY xIV769m6GLk4hAQOM0osvtbCDuEsZpQ4tr2BGaSBTcBCovufNkiDiIC6xNe9PcwgtrCAnkT/ jJ0sEHFjiWMTNrFC2HoSH05MBouzCKhIfPh3iA3E5hXwlTh7+CyYzQi0+PupNUwgNrOAuMSt J/OZIA4SkFiy5zwzhC0q8fLxP1YIW1Hi6vTlUPX5EtfObGSGmCkocXLmE5YJjEKzkIyahaRs FpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRPTcxMye93HwTIzDsD275bbCDcdN9 sUOM0hwsSuK8yVyNgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4QQSXVAPjzmO1Z75lsH32+rIk WuNl8apMhyMXcuK/P71S4FaZ/mox8wf1lFU//39fuOjbN4HW0xYv8s4JLhDSFXygE8J57YUF x6Gy/H9JfAtrZzCaXE04/+lq/8kbuaVaVz7vD7q4W4KHv9y485ps5IECjqiDPdLZAo7s951v zoxUnCwX8OrbbMtNETKMSizFGYmGWsxFxYkA6hLK0E4CAAA= Subject: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:07:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C36B4F6ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Assume the following case: 1. An SDP offer contains an m- line associated with a BUNDLE group 2. The answerer wants to accept the m- line, but wants to reject it b= eing in the specific BUNDLE group. A few alternatives on how this could be achieved have been presented: Alt 1. The answerer accepts the m- line, but does not associate it wit= h a BUNDLE group. Alt 2. The answerer accepts the m- line, associates it with a BUNDLE g= roup, and then sends a new offer which removes the m- line from the BUNDLE = group. Alt 3. The answerer rejects the m- line, and then sends a new offer wh= ich adds the m- line outside a BUNDLE group. In my opinion, Alt 1 does not work, at least not if the offer contains iden= tical port values for the m- lines associated with the BUNDLE group. It wou= ld mean that the m- line is not added to a BUNDLE group, but still has the = same port value (at least at the offerer side) as the m- lines in the BUNDL= E group, which is not allowed. So, my suggestion would be to specify that the answerer must use Alt 2 and/= or Alt 3. Comments? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C36B4F6ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Assume the following case:

 

1.     &= nbsp; An SDP offer contains an m- line associated with a = BUNDLE group

2.     &= nbsp; The answerer wants to accept the m- line, but wants= to reject it being in the specific BUNDLE group.

 

A few alternatives on how this could be achieved hav= e been presented:

 

Alt 1.      The answerer ac= cepts the m- line, but does not associate it with a BUNDLE group.

 

Alt 2.      The answerer ac= cepts the m- line, associates it with a BUNDLE group, and then sends a new = offer which removes the m- line from the BUNDLE group.

 

Alt 3.      The answerer re= jects the m- line, and then sends a new offer which adds the m- line outsid= e a BUNDLE group.

 

In my opinion, Alt 1 does not work, at least not if = the offer contains identical port values for the m- lines associated with t= he BUNDLE group. It would mean that the m- line is not added to a BUNDLE gr= oup, but still has the same port value (at least at the offerer side) as the m- lines in the BUNDLE group, which = is not allowed.

 

So, my suggestion would be to specify that the answe= rer must use Alt 2 and/or Alt 3.

 

Comments?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C36B4F6ESESSMB209erics_-- From mzanaty@cisco.com Fri May 3 06:28:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAC221F9655 for ; Fri, 3 May 2013 06:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thlPr6mfMAim for ; Fri, 3 May 2013 06:28:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5748D21F964F for ; Fri, 3 May 2013 06:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18646; q=dns/txt; s=iport; t=1367587715; x=1368797315; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ulHNZxx8kzSdqYQNE7MrbmePsTRBfmEpJg8MTz25kek=; b=g3hExnzluPbPutRUWhh+ajxb1WBgwhxSyPp4vhO/ZZY+5AeRt6FyZ1Qz kPLP83z5cDbcUKYluo3x8YA20mWFdtXKB/x+cXSWuond7DlKIxik9rC0B EszSaE9rwZe4dCw3FFyvjZ+LP2ckMLlaJIMkwNw8242OpjuMhXS7yhe9n E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAP26g1GtJXHA/2dsb2JhbABQgwc3vy95FnSCHwEBAQMBAQEBawsFCwIBCA4DBAEBAScHJwsUCQgCBA4FiAYGDMEeBI8jBAeCcmEDlyuRMoMN X-IronPort-AV: E=Sophos;i="4.87,604,1363132800"; d="scan'208,217";a="206098185" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 03 May 2013 13:28:34 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r43DSYqK023284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 13:28:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 3 May 2013 08:28:34 -0500 From: "Mo Zanaty (mzanaty)" To: Justin Uberti Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHOR8KVUvZFEriikUyEO6sxlAqo8pjzdLKN Date: Fri, 3 May 2013 13:28:33 +0000 Message-ID: <5050EE56-9146-48D7-8C6C-1699244D8F2C@cisco.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5050EE56914648D78C6C1699244D8F2Cciscocom_" MIME-Version: 1.0 Cc: Paul Kyzivat , Alan Johnston , "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:28:49 -0000 --_000_5050EE56914648D78C6C1699244D8F2Cciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Accurate summary, and I agree with the recommendation, which is a MUST in D= TLS-SRTP (RFC 5763 section 5). Mo On May 3, 2013, at 1:54 AM, "Justin Uberti" > wrote: This is where the OP's question came from - the differing policy between Ch= rome and Firefox. I (regarding Chrome) had figured that if ICE had made a d= etermination regarding which side was in charge, the other layers in the st= ack should do the same, but it sounds like there are already established ru= les on how to do this. >From this thread, it sounds like the recommendation is to use a=3Dsetup:act= pass in the offer, and then the answerer can use a=3Dsetup:active to choose= the client role. In 3pcc cases, the B2BUA can select a=3Dsetup appropriate= ly to avoid any issue. Is that an accurate summary, and is there consensus on this? On Thu, May 2, 2013 at 10:36 AM, Gustavo Garc=EDa > wrote: In previous versions of Chrome the offerer was always the DTLS server. In newest version of Chrome the ICE controlling agent is always the DTLS se= rver. (controlling and offerer are not the same in case of offerer being i= ce-lite implementation) I think in case of 3pcc we need "a=3Dsetup" with proxy/B2BUA modifying the = SDPs or using the ICE roles to resolve the conflicts. I prefer to not us= e ICE to solve this and decouple ICE and DTLS roles. G. On 02/05/2013, at 10:05, Alan Johnston wrote: > Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SRTP.= Is this attribute really needed? How do things work if one or both brows= ers don't include it? > > - Alan - > > > On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) > wrote= : > The RFC situation is not really clear, even confusing concerning client/s= erver role negotiations (in case of transport security sessions over connec= tion-oriented IP transport protocols). > > > > =B7 RFC 4145 is only about TCP, i.e., TCP client/server role assi= gnments. Thus, the RFC 4145 introduced SDP attribute is TCP specific. > > =B7 draft-ietf-mmusic-sctp-sdp: seems to profile the =93a=3Dsetup= :=94 attribute for SCTP path establishment directions =85 (?) > > =B7 RFC 5763 uses the TCP SDP attribute for DTLS session establis= hment, i.e. DTLS client/server role assignments; that=92s actually a semant= ical change of this SDP element vs RFC 4145 > > > > =85 and DTLS is TLS based, leading to the question of role/assignments in= case of TLS/TCP sessions? > > I.e., the TCP client/server and also TLS client/server roles? Keeping in = mind that the role assignments at IP transport layer and security session l= ayer may principally be different! > > > > The =93a=3Dsetup=94 definition by RFC 4145 is unfortunate in my opinion. > > Required seems to be a generic SDP specification (i.e., outside RFC 4145)= , which may be then tight to the concerned protocol. Sth like an explicit i= ndication =93a=3Dsetup:PROTOCOL:=94 or an implicit indication by adding an = identifier. > > > > The =93m=3D=94 line element does not really help to reduce ambigu= ity (as Paul reminded again: =93=93Unfortunately SDP has a pretty confusing= idea of "transport". The proto field identifies a whole stack of protocol = layers.=94). > > > > Albrecht > > PS > > I would see following parameter values for a SDP =93a=3Dsetup:PROTOCOL:= =94 attribute extension: > > L4: TCP, SCTP, DCCP(?) > > L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling =85) > > > > > > > > From: mmusic-bounces@ietf.org [mailto:mmu= sic-bounces@ietf.org] On Behalf Of Mo Zanat= y (mzanaty) > Sent: Donnerstag, 2. Mai 2013 06:04 > To: Justin Uberti > Cc: Paul Kyzivat; mmusic@ietf.org > Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation > > > > A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so th= e other leg will answer with active or passive but not actpass. > > > > A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze a= nd alter SDP in complex ways to generate two answers from two offers, part = of which is deciding which answer should become active and which should bec= ome passive. > > > > The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalt= ered by a B2BUA which delays offers on both legs. Generating two answers fr= om two offers is much more complex than simply forwarding the offers as ans= wers. > > > > DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be a= ctpass. TCP is harder since RFC 4145 allows offers to be active, passive, o= r actpass, causing more complex reinvites to resolve active/active or passi= ve/passive conflicts. > > > > Mo > > > > On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: > > I think Paul means the active/passive attributes in RFC 5763, but I'm sti= ll not sure about how 3rd party call control would be handled in this case,= i.e. when both endpoints think they are offerers and set a=3Dsetup:actpass= . > > > > ICE has logic to determine roles in this scenario, as shows in RFC 5245, = B.11. > > > > On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: > > I saw it, but that is all about TCP client/server role and not DTLS clien= t/server role. Are we supposed to use the same "setup" attribute for dtls= role negotiation even if it is over UDP? > > I think there is no reason to tie TCP and DTLS roles, but perhaps I'm mis= understanding something. > > > On 01/05/2013, at 13:56, Paul Kyzivat wrote: > > > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: > >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and whi= ch side is the DTLS server must be established via some out-of-band mechani= sm such as SDP." > >> > >> What is the specification on how to signal that in SDP? > >> > >> Specifically in case of 3pcc where both endpoints are SDP offerers whi= ch one should take the client and server roles for DTLS? Should we tie t= hat role to ICE controlled/controlling roles or should we negotiate it in t= he SDP somehow? > > > > See RFC4145. > > > > _______________________________________________ > > 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 _______________________________________________ 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_5050EE56914648D78C6C1699244D8F2Cciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Accurate summary, and I agree with the recommendation, which is a MUST= in DTLS-SRTP (RFC 5763 section 5).

Mo


On May 3, 2013, at 1:54 AM, "Justin Uberti" <juberti@google.com> wrote:

This is where the OP's question came from - the differing = policy between Chrome and Firefox. I (regarding Chrome) had figured that if= ICE had made a determination regarding which side was in charge, the other= layers in the stack should do the same, but it sounds like there are already established rules on how to do = this.

From this thread, it sounds like the recommendation is to u= se a=3Dsetup:actpass in the offer, and then the answerer can use a=3Dsetup:= active to choose the client role. In 3pcc cases, the B2BUA can select a=3Ds= etup appropriately to avoid any issue.

Is that an accurate summary, and is there consensus on this= ?


On Thu, May 2, 2013 at 10:36 AM, Gustavo Garc=ED= a <ggb@tokbox.com&= gt; wrote:
In previous versions of Chrome the offerer was always the DTLS server.

In newest version of Chrome the ICE controlling agent is always the DTLS se= rver.  (controlling and offerer are not the same in case of offerer be= ing ice-lite implementation)

I think in case of 3pcc we need "a=3Dsetup" with proxy/B2BUA modi= fying the SDPs or using the ICE roles to resolve the conflicts.   &nbs= p;I prefer to not use ICE to solve this and decouple ICE and DTLS roles.
G.

On 02/05/2013, at 10:05, Alan Johnston wrote:

> Interestingly, I have yet to see any browser use a=3Dsetup for DTLS-SR= TP.  Is this attribute really needed?  How do things work if one = or both browsers don't include it?
>
> - Alan -
>
>
> On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-= lucent.com> wrote:
> The RFC situation is not really clear, even confusing concerning clien= t/server role negotiations (in case of transport security sessions over con= nection-oriented IP transport protocols).
>
>
>
> =B7         RFC 4145 is only about TCP, i.e., TCP = client/server role assignments. Thus, the RFC 4145 introduced SDP attribute= is TCP specific.
>
> =B7         draft-ietf-mmusic-sctp-sdp: seems to p= rofile the =93a=3Dsetup:=94 attribute for SCTP path establishment direction= s =85 (?)
>
> =B7         RFC 5763 uses the TCP SDP attribute fo= r DTLS session establishment, i.e. DTLS client/server role assignments; tha= t=92s actually a semantical change of this SDP element vs RFC 4145
>
>
>
> =85 and DTLS is TLS based, leading to the question of role/assignments= in case of TLS/TCP sessions?
>
> I.e., the TCP client/server and also TLS client/server roles? Keeping = in mind that the role assignments at IP transport layer and security sessio= n layer  may principally be different!
>
>
>
> The =93a=3Dsetup=94 definition by RFC 4145 is unfortunate in my opinio= n.
>
> Required seems to be a generic SDP specification (i.e., outside RFC 41= 45), which may be then tight to the concerned protocol. Sth like an explici= t indication =93a=3Dsetup:PROTOCOL:=94 or an implicit indication by adding = an identifier.
>
>
>
> The =93m=3D=94 line <proto> element does not really help to redu= ce ambiguity (as Paul reminded again: =93=93Unfortunately SDP has a pretty = confusing idea of "transport". The proto field identifies a whole= stack of protocol layers.=94).
>
>
>
> Albrecht
>
> PS
>
> I would see following parameter values for a SDP =93a=3Dsetup:PROTOCOL= :=94 attribute extension:
>
> L4: TCP, SCTP, DCCP(?)
>
> L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling =85) >
>
>
>
>
>
>
> From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ie= tf.org] On Behalf Of Mo Zanaty (mzanaty)
> Sent: Donnerstag, 2. Mai 2013 06:04
> To: Justin Uberti
> Cc: Paul Kyzivat; mmusic@ietf.org
> Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
>
>
>
> A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so= the other leg will answer with active or passive but not actpass.
>
>
>
> A complex 3PCC/B2BUA delays offers toward both legs, so it must analyz= e and alter SDP in complex ways to generate two answers from two offers, pa= rt of which is deciding which answer should become active and which should = become passive.
>
>
>
> The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded un= altered by a B2BUA which delays offers on both legs. Generating two answers= from two offers is much more complex than simply forwarding the offers as = answers.
>
>
>
> DTLS-SRTP is actually an easy case since RFC 5763 requires offers to b= e actpass. TCP is harder since RFC 4145 allows offers to be active, passive= , or actpass, causing more complex reinvites to resolve active/active or pa= ssive/passive conflicts.
>
>
>
> Mo
>
>
>
> On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> wrote:
>
> I think Paul means the active/passive attributes in RFC 5763, but I'm = still not sure about how 3rd party call control would be handled in this ca= se, i.e. when both endpoints think they are offerers and set a=3Dsetup:actp= ass.
>
>
>
> ICE has logic to determine roles in this scenario, as shows in RFC 524= 5, B.11.
>
>
>
> On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa <ggb@tokbox.com> wrote:
>
> I saw it, but that is all about TCP client/server role and not DTLS cl= ient/server role.   Are we supposed to use the same "setup" = attribute for dtls role negotiation even if it is over UDP?
>
> I think there is no reason to tie TCP and DTLS roles, but perhaps I'm = misunderstanding something.
>
>
> On 01/05/2013, at 13:56, Paul Kyzivat wrote:
>
> > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote:
> >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS = client and which side is the DTLS server must be established via some out-o= f-band mechanism such as SDP."
> >>
> >> What is the specification on how to signal that in SDP?
> >>
> >> Specifically in case of 3pcc where both endpoints are SDP off= erers which one should take the client and server roles for DTLS?   &n= bsp;Should we tie that role to ICE controlled/controlling roles or should w= e negotiate it in the SDP somehow?
> >
> > See RFC4145.
> >
> > _______________________________________________
> > 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

_______________________________________________
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_5050EE56914648D78C6C1699244D8F2Cciscocom_-- From albrecht.schwarz@alcatel-lucent.com Fri May 3 07:14:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2EE21F86D3 for ; Fri, 3 May 2013 07:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6udAK5MZCL8A for ; Fri, 3 May 2013 07:13:54 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BD4E121F86AE for ; Fri, 3 May 2013 07:13:47 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r43EDTui017066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 May 2013 09:13:29 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r43EDRkM022782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 10:13:29 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 3 May 2013 10:13:27 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 3 May 2013 16:13:24 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "Mo Zanaty (mzanaty)" , Justin Uberti Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpl/XH1yp96NPUWvLDnzWSG5+pjwrh2AgAAD2gCAABUxgIAAXkyAgABRLxCAALuJAIABTZkA Date: Fri, 3 May 2013 14:13:23 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC0329D7@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>, <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> <3879D71E758A7E4AA99A35DD8D41D3D91D45A655@xmb-aln-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D45A655@xmb-aln-x14.cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC0329D7FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 14:14:00 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC0329D7FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mo > If you mean TCP and TLS client/server roles can differ, I don't see that = flexibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense = for SDP to describe flexibility which is not supported in the underlying pr= otocol. I disagree with your refered justification, primarily because 1. RFC 5246, sec. 7.4 does not provide such info explicitly ("can't find a= ny TCP related info") 2. TLS itself (RFC 5246) is designed to be transport protocol independent = (see section 1: "At the lowest level, layered on top of some reliable trans= port protocol ...") 3. TLS-over-SCTP (RFC 3436): there is not any client/server concept in SCT= P (RFC 2960)! SCTP associations are established between two SCTP endpoints = ... (rather a peer-to-peer concept than client/server) 4. TLS-over-TCP: the establishment of a TLS session could be principally d= elayed wrt the TCP connection establishment; the TCP client/server role is = ONLY relevant during the state transitioning from CLOSED to ESTAB (RFC 793)= ; ie the TCP roles "dissolve" with a successfully established TCP connectio= n state. I fail to see any tight coupling between TLS and TCP. Regards, Albrecht From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] Sent: Donnerstag, 2. Mai 2013 22:06 To: Schwarz, Albrecht (Albrecht); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation > role assignments at IP transport layer and security session layer may pri= ncipally be different! If you mean TCP and TLS client/server roles can differ, I don't see that fl= exibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense fo= r SDP to describe flexibility which is not supported in the underlying prot= ocol. I agree it is somewhat confusing for DTLS-SRTP to use an attribute original= ly defined for TCP, but I don't see any practical problem or deficiency tha= t would be solved by the proposed "a=3Dsetup:PROTOCOL:" attribute extension= . Mo From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: Thursday, May 02, 2013 3:15 AM To: Mo Zanaty (mzanaty); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation The RFC situation is not really clear, even confusing concerning client/ser= ver role negotiations (in case of transport security sessions over connecti= on-oriented IP transport protocols). =B7 RFC 4145 is only about TCP, i.e., TCP client/server role assign= ments. Thus, the RFC 4145 introduced SDP attribute is TCP specific. =B7 draft-ietf-mmusic-sctp-sdp: seems to profile the "a=3Dsetup:" a= ttribute for SCTP path establishment directions ... (?) =B7 RFC 5763 uses the TCP SDP attribute for DTLS session establishm= ent, i.e. DTLS client/server role assignments; that's actually a semantical= change of this SDP element vs RFC 4145 ... and DTLS is TLS based, leading to the question of role/assignments in c= ase of TLS/TCP sessions? I.e., the TCP client/server and also TLS client/server roles? Keeping in mi= nd that the role assignments at IP transport layer and security session lay= er may principally be different! The "a=3Dsetup" definition by RFC 4145 is unfortunate in my opinion. Required seems to be a generic SDP specification (i.e., outside RFC 4145), = which may be then tight to the concerned protocol. Sth like an explicit ind= ication "a=3Dsetup:PROTOCOL:" or an implicit indication by adding an identi= fier. The "m=3D" line element does not really help to reduce ambiguity (a= s Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "= transport". The proto field identifies a whole stack of protocol layers."). Albrecht PS I would see following parameter values for a SDP "a=3Dsetup:PROTOCOL:" attr= ibute extension: L4: TCP, SCTP, DCCP(?) L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling ...) From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty) Sent: Donnerstag, 2. Mai 2013 06:04 To: Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 --_000_786615F3A85DF44AA2A76164A71FE1AC0329D7FR711WXCHMBA03zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mo

 

> If you mean TCP and TLS client/server roles can differ, I don= 217;t see that flexibility in TLS itself (RFC 5246 section 7.4), so it doesnR= 17;t make sense for SDP to describe flexibility which is not supported in t= he underlying protocol.

 

I disagree with your refered = justification, primarily because

1.  RFC 5246, sec. 7.4 do= es not provide such info explicitly (“can’t find any TCP relate= d info”)

2.  TLS itself (RFC 5246)= is designed to be transport protocol independent (see section 1: “At the lowest level, layered on top of some reliable transport protocol …”)

3.  TLS-over-SCTP (RFC 34= 36): there is not any client/server concept in SCTP (RFC 2960)! SCTP associ= ations are established between two SCTP endpoints … (rather a peer-to-peer concept than client/server)

4.  TLS-over-TCP: the est= ablishment of a TLS session could be principally delayed wrt the TCP connec= tion establishment; the TCP client/server role is ONLY relevant during the state transitioning from CLOSED to ESTAB (RFC = 793); ie the TCP roles “dissolve” with a successfully establish= ed TCP connection state.

 

I fail to see any tight coupl= ing between TLS and TCP.

 

Regards,

Albrecht

 

From: Mo Zanat= y (mzanaty) [mailto:mzanaty@cisco.com]
Sent: Donnerstag, 2. Mai 2013 22:06
To: Schwarz, Albrecht (Albrecht); = Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

> role assignments at= IP transport layer and security session layer may principally be different= !

 =

If you mean TCP and TLS = client/server roles can differ, I don’t see that flexibility in TLS i= tself (RFC 5246 section 7.4), so it doesn’t make sense for SDP to describe flexibility which is not supported in the underlying protocol.

 =

I agree it is somewhat c= onfusing for DTLS-SRTP to use an attribute originally defined for TCP, but = I don’t see any practical problem or deficiency that would be solved by the proposed “a=3Dsetup:PROTOCOL:” attribute exte= nsion.

 =

Mo

 =

 =

From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com<= /a>]
Sent: Thursday, May 02, 2013 3:15 AM
To: Mo Zanaty (mzanaty); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org=
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

The RFC situation is not real= ly clear, even confusing concerning client/server role negotiations (in cas= e of transport security sessions over connection-oriented IP transport protocols).

 

=B7    =      RFC 4145 is only abou= t TCP, i.e., TCP client/server role assignments. Thus, the RFC 4145 introdu= ced SDP attribute is TCP specific.

=B7    =      draft-ietf-mmusic-sct= p-sdp: seems to profile the “a=3Dsetup:” attribute for SCTP pat= h establishment directions … (?)

=B7    =      RFC 5763 uses the TCP= SDP attribute for DTLS session establishment, i.e. DTLS client/server role= assignments; that’s actually a semantical change of this SDP element vs RFC 4145

 

… and DTLS is TLS based= , leading to the question of role/assignments in case of TLS/TCP sessions?<= o:p>

I.e., the TCP client/server a= nd also TLS client/server roles? Keeping in mind that the role assignments = at IP transport layer and security session layer may principally be different!

 

The “a=3Dsetup” d= efinition by RFC 4145 is unfortunate in my opinion.

Required seems to be a generi= c SDP specification (i.e., outside RFC 4145), which may be then tight to th= e concerned protocol. Sth like an explicit indication “a=3Dsetup:PROTOCOL:” or an implicit indication by adding an i= dentifier.

 

The “m=3D” lin= e <proto> element does not really help to reduce ambiguity (as Paul r= eminded again: ““Unfortunately SDP has a pretty confusing idea of "transport". The proto field = identifies a whole stack of protocol layers.&= #8221;).

 

Albrecht

PS

I would see following paramet= er values for a SDP “a=3Dsetup:PROTOCOL:” attribute extension:<= o:p>

L4: TCP, SCTP, DCCP(?)

L4+: TLS, DTLS, DTLS-SRTP= (?, due to RFC 5764 SDP profiling …)

 

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org=
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

A simple 3PCC/B2BUA only delays offers toward one le= g like RFC3725, so the other leg will answer with active or passive but not= actpass.

 

A complex 3PCC/B2BUA delays offers toward both legs,= so it must analyze and alter SDP in complex ways to generate two answers f= rom two offers, part of which is deciding which answer should become active= and which should become passive.

 

The flow in RFC 5245 B.11 is oversimplified. SDP can= 't be forwarded unaltered by a B2BUA which delays offers on both legs. Gene= rating two answers from two offers is much more complex than simply forward= ing the offers as answers.

 

DTLS-SRTP is actually an easy case since RFC 5763 re= quires offers to be actpass. TCP is harder since RFC 4145 allows offers to = be active, passive, or actpass, causing more complex reinvites to resolve a= ctive/active or passive/passive conflicts.

 

Mo



On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> wrote:

I think Paul means the active/passive attributes in = RFC 5763, but I'm still not sure about how 3rd party call control would be = handled in this case, i.e. when both endpoints think they are offerers and = set a=3Dsetup:actpass.

 

ICE has logic to determine roles in this scenario, a= s shows in RFC 5245, B.11. 

 

On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa <= ;ggb@tokbox.com>= wrote:

I saw it, but that is all about TCP client/server ro= le and not DTLS client/server role.   Are we supposed to use the same = "setup" attribute for dtls role negotiation even if it is over UD= P?

I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something.


On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote:
>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS clien= t and which side is the DTLS server must be established via some out-of-ban= d mechanism such as SDP."
>>
>> What is the specification on how to signal that in SDP?
>>
>> Specifically in case of 3pcc where both endpoints are SDP offerers= which one should take the client and server roles for DTLS?    S= hould we tie that role to ICE controlled/controlling roles or should we neg= otiate it in the SDP somehow?
>
> See RFC4145.
>
> _______________________________________________
> 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.o= rg/mailman/listinfo/mmusic

--_000_786615F3A85DF44AA2A76164A71FE1AC0329D7FR711WXCHMBA03zeu_-- From pkyzivat@alum.mit.edu Fri May 3 08:26:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C62D21F9661 for ; Fri, 3 May 2013 08:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZA9uDTO1j6fx for ; Fri, 3 May 2013 08:26:39 -0700 (PDT) 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 15B3C21F96B1 for ; Fri, 3 May 2013 07:55:28 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id XPJu1l0031swQuc51SvSU1; Fri, 03 May 2013 14:55:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id XSvS1l0073ZTu2S3bSvSpv; Fri, 03 May 2013 14:55:26 +0000 Message-ID: <5183CFDD.90203@alum.mit.edu> Date: Fri, 03 May 2013 10:55:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36B485@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=1367592926; bh=5SuxTnVuZjsyL/aws9gsPWg2+33axf6yL8Sbw0+u/xY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gf4oNe6SgyEcfG/9uGAP1hXtaDPMgtosdzWefZjfOmQ8Dzaw2SIXwT+2AiEIRipCs toCbGT2NY+inQspjKYDfpl/EwnUnEU+krQ3SMlP751WoYF6jB2n1cl1vTwmG6YmrN5 UaaWKq2RW0ISLf5TtO7gTKzLzfiTyBqsQ9907tBJpBioCkZlkuXGbKASmvb3Hs7H0M tKbN71Qs7mHyly4nU5I3Wg68mR8sgo29F1uEN0LPGZdG12WzAePVeIpvTMeG0biKYf ufdVu/uN91nYe8oykMvRMfLhYHp8hZmve4KibKHIsTi7T7Sd5iuL74oMkSjI2eZsz1 kn7kxm77nzaxA== Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 15:26:45 -0000 On 5/3/13 8:53 AM, Christer Holmberg wrote: > Hi, > > In order to try to close issues on BUNDLE, based on the discussions > we’ve had, I intend to update the BUNDLE draft based on the following > assumptions: > > 1.We mandate usage of rtcp-mux when BUNDLE is used. Are you going to include the possibility of bundling non-RTP m-lines? (Needed if we are to include DTLS/SCTP.) If so, then of course the use of rtcp-mux only applies to RTP m-lines. (Of course, if only one DTLS/SCTP line can be included, a bundle without RTP is not very interesting. But it doesn't hurt to make this ready for future bundling of other things.) > 2.SDP m- lines with a zero port value MUST NOT be put inside a BUNDLE > group (not in an offer, nor in an answer). There will be a note > indicating that, due to this, the number of m- lines associated with a > BUNDLE group may differ between the offer and the associated answer. > There will also be a note indicating that this is due to RFC 5888, in > case people later start to wonder where the “MUST NOT” comes from. > > Please indicate if you OBJECT to any of these assumptions. Aside from the above comment I have no objections. Thanks, Paul From pkyzivat@alum.mit.edu Fri May 3 08:43:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8BD21F9830 for ; Fri, 3 May 2013 08:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeiCDu9Bi0E2 for ; Fri, 3 May 2013 08:43:20 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id F252F21F9687 for ; Fri, 3 May 2013 08:01:22 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id XNwz1l0040vyq2s51T1Muy; Fri, 03 May 2013 15:01:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id XT1M1l00l3ZTu2S3RT1Mb3; Fri, 03 May 2013 15:01:21 +0000 Message-ID: <5183D141.7060607@alum.mit.edu> Date: Fri, 03 May 2013 11:01:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367593281; bh=ijJLO39gjBEXykKk6h68s0NqX8DRoIA72tgbKZzfMqM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oftiOKXQmwr4TJSQjHSWluvrY9mWH5NwS0Dcl3i56VIj+yQpwtnXVmxW1dB3Fb3Xk /Xve8IVZ6yUv9uemIgAk8JFFZhsNHSSpNnL+0ZTMbdLYQzbms9KZ8ntxyO4g7HzdjX 5fbvssWtHghxtuyvS3l9sdvxErglpCtSeHDsbLl3pA+btQtb/vWoV8HKO78MgieOIf czoXq+LgMoIumRcyP+d0DeK69tQespWPQIpBU9ejib7F7nxzB/7GJPvd771ooGvUi5 3kdqG7HsgaT64kYtyxrvilF3wB0aIQyN7HIS17Al1zB9bxZeXWBeg4hX92yQDezpHh M+FAgjXTDqfXQ== Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 15:43:29 -0000 On 5/3/13 9:07 AM, Christer Holmberg wrote: > Hi, > > Assume the following case: > > 1.An SDP offer contains an m- line associated with a BUNDLE group > > 2.The answerer wants to accept the m- line, but wants to reject it being > in the specific BUNDLE group. > > A few alternatives on how this could be achieved have been presented: > > Alt 1. The answerer accepts the m- line, but does not associate it > with a BUNDLE group. > > Alt 2. The answerer accepts the m- line, associates it with a > BUNDLE group, and then sends a new offer which removes the m- line from > the BUNDLE group. > > Alt 3. The answerer rejects the m- line, and then sends a new offer > which adds the m- line outside a BUNDLE group. > > In my opinion, Alt 1 does not work, at least not if the offer contains > identical port values for the m- lines associated with the BUNDLE group. > It would mean that the m- line is not added to a BUNDLE group, but still > has the same port value (at least at the offerer side) as the m- lines > in the BUNDLE group, which is not allowed. > > So, my suggestion would be to specify that the answerer must use Alt 2 > and/or Alt 3. I don't think we should restrict flexibility here when it works and makes sense. I agree that Alt 1 doesn't work *if* the m-line in question shares addr/prot with other m-lines that are also accepted, bundled or not. But the normal first offer won't present that situation. If the addr/port in the m-line in question is unique among all the accepted m-lines, then this should be acceptable. (Note, this is a degenerate case of bundle splitting. There are real use cases for it. If it can be done without a 2nd o/a, then lets allow that.) Thanks, Paul From pkyzivat@alum.mit.edu Fri May 3 10:19:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5221F969C for ; Fri, 3 May 2013 10:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.762 X-Spam-Level: ** X-Spam-Status: No, score=2.762 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMq459Ji0dfM for ; Fri, 3 May 2013 10:19:55 -0700 (PDT) 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 A675321F993A for ; Fri, 3 May 2013 08:54:58 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta02.westchester.pa.mail.comcast.net with comcast id XPzz1l0051wpRvQ51Tulqu; Fri, 03 May 2013 15:54:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:a060:a4d2:13be:538b]) by omta18.westchester.pa.mail.comcast.net with comcast id XTuj1l00c0bDVez3eTujok; Fri, 03 May 2013 15:54:45 +0000 Message-ID: <5183DDC2.9000602@alum.mit.edu> Date: Fri, 03 May 2013 11:54:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Justin Uberti References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367596485; bh=Vwcop7LBcbFBjKhhnyVtyamJQdK1yEqMv2sM7r64eT8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iyC4V2rzIckywaw0MoCE9SewLFdyWU+O0FIUpkyxK53cHrBdAOeE8pnJqQ3eqD/ZS zjfPv8RUi7mbmxyAvpohtrev3BkizJiIe1DjF4ETOuIpxMAisBoShBpA5ZluP4gq+Z akDtf//TkEGNVmeeGXn6ElfICrRCNFLKyFSdTyyGSiSfWSDwDM3HRnSeiPpQprrwiE baHePmA9di++4SiU4w9fPx8KDta08yQJoWG6DI9zCzwNx+e71EwPO87wzjRWVTDA9T gSV00ubu5frJOd7G5SJeD302BvaGxDxn3Ug8dgh3EeNqdBZA5gAxrnmrfVvdxl5QeB rbCO3omhH23wg== Cc: Alan Johnston , "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:19:59 -0000 On 5/3/13 1:53 AM, Justin Uberti wrote: > This is where the OP's question came from - the differing policy between > Chrome and Firefox. I (regarding Chrome) had figured that if ICE had > made a determination regarding which side was in charge, the other > layers in the stack should do the same, but it sounds like there are > already established rules on how to do this. > > From this thread, it sounds like the recommendation is to use > a=setup:actpass in the offer, and then the answerer can use > a=setup:active to choose the client role. In 3pcc cases, the B2BUA can > select a=setup appropriately to avoid any issue. > > Is that an accurate summary, and is there consensus on this? More or less. It is generally recommended that the initial offerer use actpass if it can, and be more restrictive if it knows it has corresponding restrictions. Presumably use of ICE can make anybody capable of being passive. Thanks, Paul > On Thu, May 2, 2013 at 10:36 AM, Gustavo García > wrote: > > In previous versions of Chrome the offerer was always the DTLS server. > > In newest version of Chrome the ICE controlling agent is always the > DTLS server. (controlling and offerer are not the same in case of > offerer being ice-lite implementation) > > I think in case of 3pcc we need "a=setup" with proxy/B2BUA modifying > the SDPs or using the ICE roles to resolve the conflicts. I > prefer to not use ICE to solve this and decouple ICE and DTLS roles. > > G. > > On 02/05/2013, at 10:05, Alan Johnston wrote: > > > Interestingly, I have yet to see any browser use a=setup for > DTLS-SRTP. Is this attribute really needed? How do things work if > one or both browsers don't include it? > > > > - Alan - > > > > > > On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) > > wrote: > > The RFC situation is not really clear, even confusing concerning > client/server role negotiations (in case of transport security > sessions over connection-oriented IP transport protocols). > > > > > > > > · RFC 4145 is only about TCP, i.e., TCP client/server > role assignments. Thus, the RFC 4145 introduced SDP attribute is TCP > specific. > > > > · draft-ietf-mmusic-sctp-sdp: seems to profile the > “a=setup:†attribute for SCTP path establishment directions … (?) > > > > · RFC 5763 uses the TCP SDP attribute for DTLS session > establishment, i.e. DTLS client/server role assignments; that’s > actually a semantical change of this SDP element vs RFC 4145 > > > > > > > > … and DTLS is TLS based, leading to the question of > role/assignments in case of TLS/TCP sessions? > > > > I.e., the TCP client/server and also TLS client/server roles? > Keeping in mind that the role assignments at IP transport layer and > security session layer may principally be different! > > > > > > > > The “a=setup†definition by RFC 4145 is unfortunate in my opinion. > > > > Required seems to be a generic SDP specification (i.e., outside > RFC 4145), which may be then tight to the concerned protocol. Sth > like an explicit indication “a=setup:PROTOCOL:†or an implicit > indication by adding an identifier. > > > > > > > > The “m=†line element does not really help to reduce > ambiguity (as Paul reminded again: ““Unfortunately SDP has a pretty > confusing idea of "transport". The proto field identifies a whole > stack of protocol layers.â€). > > > > > > > > Albrecht > > > > PS > > > > I would see following parameter values for a SDP > “a=setup:PROTOCOL:†attribute extension: > > > > L4: TCP, SCTP, DCCP(?) > > > > L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling …) > > > > > > > > > > > > > > > > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org ] On > Behalf Of Mo Zanaty (mzanaty) > > Sent: Donnerstag, 2. Mai 2013 06:04 > > To: Justin Uberti > > Cc: Paul Kyzivat; mmusic@ietf.org > > Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation > > > > > > > > A simple 3PCC/B2BUA only delays offers toward one leg like > RFC3725, so the other leg will answer with active or passive but not > actpass. > > > > > > > > A complex 3PCC/B2BUA delays offers toward both legs, so it must > analyze and alter SDP in complex ways to generate two answers from > two offers, part of which is deciding which answer should become > active and which should become passive. > > > > > > > > The flow in RFC 5245 B.11 is oversimplified. SDP can't be > forwarded unaltered by a B2BUA which delays offers on both legs. > Generating two answers from two offers is much more complex than > simply forwarding the offers as answers. > > > > > > > > DTLS-SRTP is actually an easy case since RFC 5763 requires offers > to be actpass. TCP is harder since RFC 4145 allows offers to be > active, passive, or actpass, causing more complex reinvites to > resolve active/active or passive/passive conflicts. > > > > > > > > Mo > > > > > > > > On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: > > > > I think Paul means the active/passive attributes in RFC 5763, but > I'm still not sure about how 3rd party call control would be handled > in this case, i.e. when both endpoints think they are offerers and > set a=setup:actpass. > > > > > > > > ICE has logic to determine roles in this scenario, as shows in > RFC 5245, B.11. > > > > > > > > On Wed, May 1, 2013 at 2:10 PM, Gustavo García > wrote: > > > > I saw it, but that is all about TCP client/server role and not > DTLS client/server role. Are we supposed to use the same "setup" > attribute for dtls role negotiation even if it is over UDP? > > > > I think there is no reason to tie TCP and DTLS roles, but perhaps > I'm misunderstanding something. > > > > > > On 01/05/2013, at 13:56, Paul Kyzivat wrote: > > > > > On 5/1/13 2:26 PM, Gustavo García wrote: > > >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client > and which side is the DTLS server must be established via some > out-of-band mechanism such as SDP." > > >> > > >> What is the specification on how to signal that in SDP? > > >> > > >> Specifically in case of 3pcc where both endpoints are SDP > offerers which one should take the client and server roles for DTLS? > Should we tie that role to ICE controlled/controlling roles or > should we negotiate it in the SDP somehow? > > > > > > See RFC4145. > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > From mzanaty@cisco.com Fri May 3 10:29:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1DE21F8BB7 for ; Fri, 3 May 2013 10:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y8irP+ROEiC for ; Fri, 3 May 2013 10:28:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id F203021F9B3E for ; Fri, 3 May 2013 09:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38475; q=dns/txt; s=iport; t=1367600051; x=1368809651; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vb6DZFyvkLZV4FXapezsK2nHCiHKPwPzuAcI8RFzOXg=; b=FGuUX26dIJ9xxJruzmSg+mNe5+cPRH83BIBsgOVrbimIDBNr54aocpQK +tywMSh3ja9VyjUG084+PvhAwzhLlm1z/c7avd3l5gqo/4Ww6hDjgE2KX d6l+9Sz5nB5wBJb3a9tlUGh8SVFuK8GD71+G33+JW+F5sOXaNpIAlWUu0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAMzqg1GtJV2Z/2dsb2JhbABQgkNEN78yeRZ0gh8BAQEDAQEBASpBCwULAgEIEQQBAQEKFgEGBycLFAkIAgQBDQUIh34GDMFCBI8ALQQGAQaCbGEDiGCffoMNgic X-IronPort-AV: E=Sophos;i="4.87,606,1363132800"; d="scan'208,217";a="206161029" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 03 May 2013 16:54:00 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r43Gs01S008336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 16:54:00 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 3 May 2013 11:54:00 -0500 From: "Mo Zanaty (mzanaty)" To: "Schwarz, Albrecht (Albrecht)" , Justin Uberti Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORq6jUvZFEriikUyEO6sxlAqo8pjxJyYAgAAVMYCAAAp7+oAAiSgAgAAzPTCAAdP7gP//xzeQ Date: Fri, 3 May 2013 16:53:59 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D462E4B@xmb-rcd-x14.cisco.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>, <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> <3879D71E758A7E4AA99A35DD8D41D3D91D45A655@xmb-aln-x14.cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0329D7@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0329D7@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.209.249] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D462E4Bxmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:29:00 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D462E4Bxmbrcdx14ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TLS RFC 5246 section 7.4.1.2: When a client first connects to a server, it is required to send the Client= Hello as its first message. TCP RFC 793 section 2.7: The OPEN call also specifies whether the connection establishment is to be = actively pursued, or to be passively waited for. You are correct that TLS does not specify any tight coupling to TCP, but ho= w can you interpret the above to mean anything other than "clients actively= connect to passive servers"? Since TLS and DTLS do not support negotiating client/server roles, but rath= er derive them from the connection (and DTLS-SRTP specifies how to negotiat= e the connection as active/passive/actpass in SDP O/A), how would you suppo= rt the role inversion you propose? How would a TCP listener know whether it= can invert roles from server to client and send TLS ClientHello? Perhaps EKR can chime in, but I just don't see the flexibility you describe= being supported in TLS, so I don't see why SDP would need extensions to si= gnal such flexibility. Mo From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: Friday, May 03, 2013 10:13 AM To: Mo Zanaty (mzanaty); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation Mo > If you mean TCP and TLS client/server roles can differ, I don't see that = flexibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense = for SDP to describe flexibility which is not supported in the underlying pr= otocol. I disagree with your refered justification, primarily because 1. RFC 5246, sec. 7.4 does not provide such info explicitly ("can't find a= ny TCP related info") 2. TLS itself (RFC 5246) is designed to be transport protocol independent = (see section 1: "At the lowest level, layered on top of some reliable trans= port protocol ...") 3. TLS-over-SCTP (RFC 3436): there is not any client/server concept in SCT= P (RFC 2960)! SCTP associations are established between two SCTP endpoints = ... (rather a peer-to-peer concept than client/server) 4. TLS-over-TCP: the establishment of a TLS session could be principally d= elayed wrt the TCP connection establishment; the TCP client/server role is = ONLY relevant during the state transitioning from CLOSED to ESTAB (RFC 793)= ; ie the TCP roles "dissolve" with a successfully established TCP connectio= n state. I fail to see any tight coupling between TLS and TCP. Regards, Albrecht From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] Sent: Donnerstag, 2. Mai 2013 22:06 To: Schwarz, Albrecht (Albrecht); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation > role assignments at IP transport layer and security session layer may pri= ncipally be different! If you mean TCP and TLS client/server roles can differ, I don't see that fl= exibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense fo= r SDP to describe flexibility which is not supported in the underlying prot= ocol. I agree it is somewhat confusing for DTLS-SRTP to use an attribute original= ly defined for TCP, but I don't see any practical problem or deficiency tha= t would be solved by the proposed "a=3Dsetup:PROTOCOL:" attribute extension= . Mo From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: Thursday, May 02, 2013 3:15 AM To: Mo Zanaty (mzanaty); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation The RFC situation is not really clear, even confusing concerning client/ser= ver role negotiations (in case of transport security sessions over connecti= on-oriented IP transport protocols). =B7 RFC 4145 is only about TCP, i.e., TCP client/server role assign= ments. Thus, the RFC 4145 introduced SDP attribute is TCP specific. =B7 draft-ietf-mmusic-sctp-sdp: seems to profile the "a=3Dsetup:" a= ttribute for SCTP path establishment directions ... (?) =B7 RFC 5763 uses the TCP SDP attribute for DTLS session establishm= ent, i.e. DTLS client/server role assignments; that's actually a semantical= change of this SDP element vs RFC 4145 ... and DTLS is TLS based, leading to the question of role/assignments in c= ase of TLS/TCP sessions? I.e., the TCP client/server and also TLS client/server roles? Keeping in mi= nd that the role assignments at IP transport layer and security session lay= er may principally be different! The "a=3Dsetup" definition by RFC 4145 is unfortunate in my opinion. Required seems to be a generic SDP specification (i.e., outside RFC 4145), = which may be then tight to the concerned protocol. Sth like an explicit ind= ication "a=3Dsetup:PROTOCOL:" or an implicit indication by adding an identi= fier. The "m=3D" line element does not really help to reduce ambiguity (a= s Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "= transport". The proto field identifies a whole stack of protocol layers."). Albrecht PS I would see following parameter values for a SDP "a=3Dsetup:PROTOCOL:" attr= ibute extension: L4: TCP, SCTP, DCCP(?) L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling ...) From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty) Sent: Donnerstag, 2. Mai 2013 06:04 To: Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D462E4Bxmbrcdx14ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

TLS RFC 5246 section 7.4.1.2:

When a client first connects to a serve= r, it is required to send the ClientHello as its first message.<= /span>

 

TCP RFC 793 section 2.7:

The OPEN call also specifies whether th= e connection establishment is to be actively pursued, or to be passively wa= ited for.

 

You are correct that TLS does not speci= fy any tight coupling to TCP, but how can you interpret the above to mean a= nything other than “clients actively connect to passive servers”?

 

Since TLS and DTLS do not support negot= iating client/server roles, but rather derive them from the connection (and= DTLS-SRTP specifies how to negotiate the connection as active/passive/actpass in SDP O/A), how would you support the role inversi= on you propose? How would a TCP listener know whether it can invert roles f= rom server to client and send TLS ClientHello?

 

Perhaps EKR can chime in, but I just do= n’t see the flexibility you describe being supported in TLS, so I don= ’t see why SDP would need extensions to signal such flexibility.=

 

Mo

 

 

From: Schwarz,= Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Sent: Friday, May 03, 2013 10:13 AM
To: Mo Zanaty (mzanaty); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

Mo

 

> If you mean TCP and= TLS client/server roles can differ, I don’t see that flexibility in = TLS itself (RFC 5246 section 7.4), so it doesn’t make sense for SDP to d= escribe flexibility which is not supported in the underlying protocol.=

 

I disagree with your refered justification, = primarily because

1.  RFC 5246, sec. 7.4 does not provide = such info explicitly (“can’t find any TCP related info”)<= o:p>

2.  TLS itself (RFC 5246) is designed to= be transport protocol independent (see section 1: “At the lowest = level, layered on top of some reliable transport protocol …”)

3.  TLS-over-SCTP (RFC 3436): there is n= ot any client/server concept in SCTP (RFC 2960)! SCTP associations are esta= blished between two SCTP endpoints … (rather a peer-to-peer concept than client/server)

4.  TLS-over-TCP: the establishment of a= TLS session could be principally delayed wrt the TCP connection establishm= ent; the TCP client/server role is ONLY relevant during the state transitioning from CLOSED to ESTAB (RFC 793); ie the TCP = roles “dissolve” with a successfully established TCP connection= state.

 

I fail to see any tight coupling between TLS= and TCP.

 

Regards,

Albrecht

 

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: Donnerstag, 2. Mai 2013 22:06
To: Schwarz, Albrecht (Albrecht); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

> role assignments at IP transport l= ayer and security session layer may principally be different!

 

If you mean TCP and TLS client/server r= oles can differ, I don’t see that flexibility in TLS itself (RFC 5246= section 7.4), so it doesn’t make sense for SDP to describe flexibili= ty which is not supported in the underlying protocol.

 

I agree it is somewhat confusing for DT= LS-SRTP to use an attribute originally defined for TCP, but I don’t s= ee any practical problem or deficiency that would be solved by the proposed “a=3Dsetup:PROTOCOL:” attribute extension.

 

Mo

 

 

From: Schwarz,= Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Sent: Thursday, May 02, 2013 3:15 AM
To: Mo Zanaty (mzanaty); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org=
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

The RFC situation is not really clear, even = confusing concerning client/server role negotiations (in case of transport = security sessions over connection-oriented IP transport protocols).

 

=B7      &nbs= p;  RFC 4145 is only about TCP, i.e., TC= P client/server role assignments. Thus, the RFC 4145 introduced SDP attribu= te is TCP specific.

=B7      &nbs= p;  draft-ietf-mmusic-sctp-sdp: seems to= profile the “a=3Dsetup:” attribute for SCTP path establishment= directions … (?)

=B7      &nbs= p;  RFC 5763 uses the TCP SDP attribute = for DTLS session establishment, i.e. DTLS client/server role assignments; t= hat’s actually a semantical change of this SDP element vs RFC 4145

 

… and DTLS is TLS based, leading to th= e question of role/assignments in case of TLS/TCP sessions?

I.e., the TCP client/server and also TLS cli= ent/server roles? Keeping in mind that the role assignments at IP transport= layer and security session layer may principally be different!

 

The “a=3Dsetup” definition by RF= C 4145 is unfortunate in my opinion.

Required seems to be a generic SDP specifica= tion (i.e., outside RFC 4145), which may be then tight to the concerned pro= tocol. Sth like an explicit indication “a=3Dsetup:PROTOCOL:” or an implicit indication by adding an identifier.

 

The “m=3D” line <proto>= element does not really help to reduce ambiguity (as Paul reminded again: = ““Unfortunately SDP has a pretty confusing idea of "transport". The proto field = identifies a whole stack of protocol layers.”).=

 

Albrecht

PS

I would see following parameter values for a= SDP “a=3Dsetup:PROTOCOL:” attribute extension:

L4: TCP, SCTP, DCCP(?)

L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC = 5764 SDP profiling …)

 

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org=
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

A simple 3PCC/B2BUA only delays of= fers toward one leg like RFC3725, so the other leg will answer with active = or passive but not actpass.

 

A complex 3PCC/B2BUA delays offers= toward both legs, so it must analyze and alter SDP in complex ways to gene= rate two answers from two offers, part of which is deciding which answer sh= ould become active and which should become passive.

 

The flow in RFC 5245 B.11 is overs= implified. SDP can't be forwarded unaltered by a B2BUA which delays offers = on both legs. Generating two answers from two offers is much more complex t= han simply forwarding the offers as answers.

 

DTLS-SRTP is actually an easy case= since RFC 5763 requires offers to be actpass. TCP is harder since RFC 4145= allows offers to be active, passive, or actpass, causing more complex rein= vites to resolve active/active or passive/passive conflicts.

 

Mo


On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> wrote:

I think Paul means the active/pass= ive attributes in RFC 5763, but I'm still not sure about how 3rd party call= control would be handled in this case, i.e. when both endpoints think they= are offerers and set a=3Dsetup:actpass.

 

ICE has logic to determine roles i= n this scenario, as shows in RFC 5245, B.11. 

 

On Wed, May 1, 2013 at 2:10 PM, Gu= stavo Garc=EDa <ggb@= tokbox.com> wrote:

I saw it, but that is all about TC= P client/server role and not DTLS client/server role.   Are we suppose= d to use the same "setup" attribute for dtls role negotiation eve= n if it is over UDP?

I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something.


On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote:
>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS clien= t and which side is the DTLS server must be established via some out-of-ban= d mechanism such as SDP."
>>
>> What is the specification on how to signal that in SDP?
>>
>> Specifically in case of 3pcc where both endpoints are SDP offerers= which one should take the client and server roles for DTLS?    S= hould we tie that role to ICE controlled/controlling roles or should we neg= otiate it in the SDP somehow?
>
> See RFC4145.
>
> _______________________________________________
> 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.o= rg/mailman/listinfo/mmusic

--_000_3879D71E758A7E4AA99A35DD8D41D3D91D462E4Bxmbrcdx14ciscoc_-- From pkyzivat@alum.mit.edu Fri May 3 10:33:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6BF21F8FF0 for ; Fri, 3 May 2013 10:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.762 X-Spam-Level: ** X-Spam-Status: No, score=2.762 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnISGLhHpyjb for ; Fri, 3 May 2013 10:33:00 -0700 (PDT) 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 6436921F99E1 for ; Fri, 3 May 2013 09:20:09 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta15.westchester.pa.mail.comcast.net with comcast id XQti1l0081HzFnQ5FUL97U; Fri, 03 May 2013 16:20:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id XUL81l01C3ZTu2S3aUL9YC; Fri, 03 May 2013 16:20:09 +0000 Message-ID: <5183E3B8.6060401@alum.mit.edu> Date: Fri, 03 May 2013 12:20:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> <5182A802.9020003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36A026@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36A026@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367598009; bh=y3g+oeCckohRnbNZIB8u5wYqwKF3y7Rgb4seSsFOlLg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gyvmn2cLGhokPIdzd8ZizByNlUXnTfV5aSgIA8/OzAmZY9KsDbzRWPIPB5XdYXEaL STJ7h54VGsOIoq1TIvmd36NFLUhbtVOw7Xtw9w3dq2/feHXAheBKbVP2RNy0B5ms9K LeHgS47eTccNaVun2Jmyx0XzwM9p/7GXAAfcCf214vi2LTxhcNT92OvXiGGUv2XBlW O+a2bOgiWPXEX3ECli661H2aWBl37y80pGSHpm0u8wCzJxBM/psWE+3eakOmHojCKm jbu84uIiup5Q27V1L4Da6o9TEWOSeH6mgwH83LsHsAywVmYsE3xglpQN9tYXkeVR+D eIXYkptvFF7sQ== Cc: Alan Johnston , "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:33:06 -0000 Christer, After rereading this and checking 4583, I realize my comment was based on a misunderstanding of what BFCP was doing. I thought you were saying that BFCP didn't use a=setup, and that the active party for the TCP/TLS connection was always the offerer. I see that was wrong - that it uses a=setup for that and says that the answer is the TLS server. BFCP seems to have arranged its authentication so either end is capable of being the TLS server, and it is only necessary to have *some* mechanism for deciding which one will be. As long as that is the case, I don't have a particular problem with it. Thanks, Paul On 5/3/13 2:58 AM, Christer Holmberg wrote: > Hi Paul, > >>> RFC 4572 specifies that the "active" endpoint also takes the role as TLS client. At least MSRP refers to RFC 4572. >>> >>> AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act as TLS client - ie it separates the TCP setup from TLS roles - which I think is very good. >> >> I think that approach has limitations. What does one do when doing a subsequent o/a, especially in the opposite direction? > > Well, I could ask you to look it up in the BFCP RFC, but I doubt you'll find an answer there :) > >> And how does one distinguish when in a subsequent o/a you do/don't want to reestablish the connection rather than retaining the existing one? > > I would need some more time to think about that, but a few questions that came to my mind: > > 1) If the TLS connection already exists, is there a reason to reestablish it to begin with? > > 2) Would you need an o/a to reestablish the TLS connection to begin with? Once the roles have been determined (in the initial o/a), can't everything be handled on the TLS layer? > > 3) If the TLS connection already exists, is there a reason to renegotiate the TLS roles? > > 4) If a subsequent o/a is needed in order to reestablish the connection, and/or renegotiate the TLS roles, could the TLS connection first be terminated on the TLS layer, before the subsequent of/a is sent? > > Regards, > > Christer > > From martin.thomson@gmail.com Fri May 3 10:40:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D34221F92F7 for ; Fri, 3 May 2013 10:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ5TgM+I4u4t for ; Fri, 3 May 2013 10:40:12 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id E040121F901A for ; Fri, 3 May 2013 10:29:56 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hq12so844832wib.15 for ; Fri, 03 May 2013 10:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lp3/ZGS4vLgjSjaTFm6KJkXkpnVgjOQFXkS/Gu0/gKY=; b=Pt7ytQVeWJ/Z5I2sMEVXa+zCQH5SerN5f4FucSUZ/9/qmF3yPBkxpIR2gelTHDF/Lt RmgnVaAZlKUvHT/hzRQ7ur+Hf3fV6Ba7wLiQDZGcwQ8KnS6XP/oLzKcASLmOhUu4i3VV CxoLcujXnXhjPCs9/9nxi2Jkc/RlWZz51HaeOzd6MNk7hTlVMzD1qx69Dj2Qg/jA8DER hWL1rK6W+ptFCoS3upD49+bAYYSON1Y8s8lWXr/RK7V7Ye4X9S4EoBrbbDSBc/vUFOFa Uz2+36E3J7K9vgcP157PMOgcH++fBXREdYP8vMuoOhgLfnPjYNuoWUXN5vB6UCpEDAUu cOIw== MIME-Version: 1.0 X-Received: by 10.180.183.133 with SMTP id em5mr14484700wic.26.1367602196090; Fri, 03 May 2013 10:29:56 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Fri, 3 May 2013 10:29:55 -0700 (PDT) In-Reply-To: References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Fri, 3 May 2013 10:29:55 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: Paul Kyzivat , Alan Johnston , "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:40:12 -0000 On 2 May 2013 22:53, Justin Uberti wrote: > This is where the OP's question came from - the differing policy between > Chrome and Firefox. I (regarding Chrome) had figured that if ICE had made a > determination regarding which side was in charge, the other layers in the > stack should do the same, but it sounds like there are already established > rules on how to do this. > > From this thread, it sounds like the recommendation is to use > a=setup:actpass in the offer, and then the answerer can use a=setup:active > to choose the client role. In 3pcc cases, the B2BUA can select a=setup > appropriately to avoid any issue. > > Is that an accurate summary, and is there consensus on this? The answer should probably be a=setup:passive, so that you don't have any disconnect on what candidate pair is nominated. And you don't pay an extra half-RTT. But otherwise, yes. From prvs=783586931d=christer.holmberg@ericsson.com Fri May 3 10:42:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4621F96E9 for ; Fri, 3 May 2013 10:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrIJg11RTHN7 for ; Fri, 3 May 2013 10:42:53 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CA70A21F9798 for ; Fri, 3 May 2013 10:37:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-30-5183f5edf15a Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0B.A0.32006.DE5F3815; Fri, 3 May 2013 19:37:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Fri, 3 May 2013 19:37:49 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpmC/JMg42bB/EOYWhKkPbD8pZjwrh2AgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIAAKEfF///lJwCAAPmFoIAAftYAgAA20vU= Date: Fri, 3 May 2013 17:37:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B693@ESESSMB209.ericsson.se> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C369B4F@ESESSMB209.ericsson.se> <5182A802.9020003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36A026@ESESSMB209.ericsson.se>, <5183E3B8.6060401@alum.mit.edu> In-Reply-To: <5183E3B8.6060401@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvre7br82BBteXGFvMbG1lsfjT+ovR YuryxywWKzYcYHVg8Wh9tpfV4+/7D0weO2fdZfdYsuQnUwBLFLdNUmJJWXBmep6+XQJ3xufJ s9gKvglWvL+6gbWB8QNvFyMHh4SAicS2h5ZdjJxAppjEhXvr2boYuTiEBA4zSux8fY0RwlnM KHF24xNWkAY2AQuJ7n/aIKaIgIbEpK1qICXMArMYJaaf3MwIMkhYwE5ixvwOJhBbRMBe4mzH IjYIu0xi3qGpzCC9LAIqEqumx4KEeQV8JTatfQu16i2LxKXee2C9nAI6Elu29oLZjEDHfT+1 BsxmFhCXuPVkPhPE0QISS/acZ4awRSVePv7HCmErSrQ/bWCEqNeRWLD7ExuErS2xbOFrZojF ghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAWDq45bfqDsY750QOMUpz sCiJ8yZzNQYKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFINjEsM4m71W5va3dF/djbvUifP n3mbgqUqJ6w+/Ezxo45me6951es9wbaxax2umD2bpnjdr0nC19aFz9FiZwRnT2/wY4nqq/pK nduemP3gOy9+avn7qwld8xaffNA5b++q9x+Vp7T/3blXRLUiobXUzfyth9ctO6HPr8teRPdk v1FYwhIXVWwQpcRSnJFoqMVcVJwIAFBMSA14AgAA Cc: Alan Johnston , "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:42:58 -0000 Hi, >After rereading this and checking 4583, I realize my comment was based >on a misunderstanding of what BFCP was doing. I thought you were saying >that BFCP didn't use a=3Dsetup, and that the active party for the TCP/TLS >connection was always the offerer. I see that was wrong - that it uses >a=3Dsetup for that and says that the answer is the TLS server. Correct. BFCP does use a=3Dsetup for the TCP connection establishment. Sorr= y if I was unclear. Regards, Christer BFCP seems to have arranged its authentication so either end is capable of being the TLS server, and it is only necessary to have *some* mechanism for deciding which one will be. As long as that is the case, I don't have a particular problem with it. Thanks, Paul On 5/3/13 2:58 AM, Christer Holmberg wrote: > Hi Paul, > >>> RFC 4572 specifies that the "active" endpoint also takes the role as TL= S client. At least MSRP refers to RFC 4572. >>> >>> AFAIR, BFCP specifies its own rule, saying that the SDP offerer always = act as TLS client - ie it separates the TCP setup from TLS roles - which I = think is very good. >> >> I think that approach has limitations. What does one do when doing a sub= sequent o/a, especially in the opposite direction? > > Well, I could ask you to look it up in the BFCP RFC, but I doubt you'll f= ind an answer there :) > >> And how does one distinguish when in a subsequent o/a you do/don't want = to reestablish the connection rather than retaining the existing one? > > I would need some more time to think about that, but a few questions that= came to my mind: > > 1) If the TLS connection already exists, is there a reason to reestablish= it to begin with? > > 2) Would you need an o/a to reestablish the TLS connection to begin with?= Once the roles have been determined (in the initial o/a), can't everything= be handled on the TLS layer? > > 3) If the TLS connection already exists, is there a reason to renegotiate= the TLS roles? > > 4) If a subsequent o/a is needed in order to reestablish the connection, = and/or renegotiate the TLS roles, could the TLS connection first be termina= ted on the TLS layer, before the subsequent of/a is sent? > > Regards, > > Christer > > From prvs=783586931d=christer.holmberg@ericsson.com Fri May 3 10:44:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8CD21F85DB for ; Fri, 3 May 2013 10:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.300, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93iY2L9HdUNh for ; Fri, 3 May 2013 10:44:12 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 284A521F882A for ; Fri, 3 May 2013 10:41:10 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-bc-5183f6b5573d Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C8.75.01956.5B6F3815; Fri, 3 May 2013 19:41:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Fri, 3 May 2013 19:41:09 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: Ac5H/Rv/zjNZSPPjTceQWRJyHaV9rQAAF6iAAAnhX7Y= Date: Fri, 3 May 2013 17:41:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B6A6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se>, <5183CFDD.90203@alum.mit.edu> In-Reply-To: <5183CFDD.90203@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.19] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvre62b82BBk3z2SymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApitsmKbGkLDgzPU/fLoE7Y/ruHawFu7gr2p7ENTB+4+hi5OSQEDCR WPRyLyOELSZx4d56ti5GLg4hgcOMEtOOHmeGcBYzSjRNX8fSxcjBwSZgIdH9TxukQUTAV+LZ 49tsILYwUPjDocVgJSIClhKr73tBlFhJ7Js4mwXEZhFQkehY2cMKYvMCtc7ec50JxBYSyJY4 v/w82A2cAloSyw9fZgaxGYHu+X5qDVgNs4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VghbUaL9 aQMjRL2BxPtz85khbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMbLnJmbm pJebb2IERsLBLb8NdjBuui92iFGag0VJnDeZqzFQSCA9sSQ1OzW1ILUovqg0J7X4ECMTByeI 4JJqYGSbzLhVR2JGSM2MfGaulWddkvPXFh3t6v3mvESSt/TZPlXVwqoLdcELZ5nXLDg1WYfn ihCzQWi3lfazlN6j30R+25w0nD31WUjOtBfB+p8/Xu9RP56XsmHixnkb2D2ePs5K1i1nsD0m cWrjiVkuvnoyWzkvrT51SX5h2+4WhxvOt/43vH3XM0WJpTgj0VCLuag4EQBH+9TzVwIAAA== Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:44:24 -0000 Hi, >> In order to try to close issues on BUNDLE, based on the discussions >> we=92ve had, I intend to update the BUNDLE draft based on the following >> assumptions: >> >> 1.We mandate usage of rtcp-mux when BUNDLE is used. > > Are you going to include the possibility of bundling non-RTP m-lines? > (Needed if we are to include DTLS/SCTP.) Yes. I guess I should have listed that as a third assumption. > If so, then of course the use of rtcp-mux only applies to RTP m-lines. Correct. > (Of course, if only one DTLS/SCTP line can be included, a bundle without > RTP is not very interesting. But it doesn't hurt to make this ready for > future bundling of other things.) Agree. My intention is not to mandate a BUNDLE group to contain RTP media. >> 2.SDP m- lines with a zero port value MUST NOT be put inside a BUNDLE >> group (not in an offer, nor in an answer). There will be a note >> indicating that, due to this, the number of m- lines associated with a >> BUNDLE group may differ between the offer and the associated answer. >> There will also be a note indicating that this is due to RFC 5888, in >> case people later start to wonder where the =93MUST NOT=94 comes from. >> >> Please indicate if you OBJECT to any of these assumptions. > > Aside from the above comment I have no objections. And, the zero port value restriction would of course apply to any media typ= e (not only RTP). Regards, Christer From juberti@google.com Fri May 3 11:15:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7823221F974A for ; Fri, 3 May 2013 11:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+KjoioJypws for ; Fri, 3 May 2013 11:15:39 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0539E21F974E for ; Fri, 3 May 2013 11:15:35 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 10so2152668ied.33 for ; Fri, 03 May 2013 11:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=yV857/XAkjdegv+P9+ema4j3qNvjJEpVrXWZOOtA5r8=; b=IqyK7smu4Umio05yi18ovyqXMdZ9dNXe3BHgAJ+PcM7EzzSMarml4eCLBJ3F6hPC7M Ku/igi1gktfqJ1nYyfu9m5Vb29qXXdp505AdD4joEVWHj5SLwz8KzMfB4xJFUnQtXWIP Q/qFzzP/WnLZHYxvUCziOIcn8pmyMooqSfmxJvafTBQj4hE+MJ0wWg/Ctc7LFF4V3Jur bptRNnv69/ok200UVdxc/vEUM4bJPW2A3BK+PLEt5IHRM14qSssnS3qEzjQgr6qgq5Ro P3rCAThq+L0dgQ3wZqC4/LYHvfihlvt37cmCFs9i90OBUfTRhzgyxZGx17wXYKNXQHfm RbDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=yV857/XAkjdegv+P9+ema4j3qNvjJEpVrXWZOOtA5r8=; b=IsgvUGGY3m9rzlSw82N1hpwi1BvvwTSWmO5U/begTs2MV9KSLn/1BniPwY84zS51JM /IIjIULofM4tWB5aKfmdX9HZu0tasAzcdkX5AoLF+H2nqxC63uChOD6L/m5udFN5jMpF uVOVjz37l9LPbuM5zcGXVkcgl9nuzHEfJc5e03I7rMp46Y3t/xLqkSl2JxTIPoK/mL0v qydUiW8hCZ7v4woPdoPDQHGZhWkA/9UjGihwy/OU0Hsbih3fmLaEHeLk9AU3wSx2p0QK CWFlo5QkstXBtr7MvXf4N/gre54yCeyshK/9VD21RdcKqPdDTROFrv8MJ7kgs3HZAIMQ D3TQ== X-Received: by 10.50.32.4 with SMTP id e4mr16342718igi.95.1367604931735; Fri, 03 May 2013 11:15:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.201 with HTTP; Fri, 3 May 2013 11:15:11 -0700 (PDT) In-Reply-To: References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> From: Justin Uberti Date: Fri, 3 May 2013 11:15:11 -0700 Message-ID: To: Martin Thomson , Eric Rescorla Content-Type: multipart/alternative; boundary=e89a8f3ba56d26440104dbd456b0 X-Gm-Message-State: ALoCoQlEvzuCSvr0uVIr2ahwGdKplWGHNyoStSmGKgd13+JhWhvbmCVMBhK3fdBQR8yy5fHOwtqD9clBrmnvX3k5VOjAPyObDGrdTXVSCA+ZSUHKVzQsdx+5Sqg7xq8haWY/yIUF7m3muCtNjgoGCUfD4x0vVGWpa7tRdyDwpXuXN622BQiUZkoX+PB27W6biUg4t1tkr2RE Cc: Paul Kyzivat , Alan Johnston , "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 18:15:40 -0000 --e89a8f3ba56d26440104dbd456b0 Content-Type: text/plain; charset=UTF-8 On Fri, May 3, 2013 at 10:29 AM, Martin Thomson wrote: > On 2 May 2013 22:53, Justin Uberti wrote: > > This is where the OP's question came from - the differing policy between > > Chrome and Firefox. I (regarding Chrome) had figured that if ICE had > made a > > determination regarding which side was in charge, the other layers in the > > stack should do the same, but it sounds like there are already > established > > rules on how to do this. > > > > From this thread, it sounds like the recommendation is to use > > a=setup:actpass in the offer, and then the answerer can use > a=setup:active > > to choose the client role. In 3pcc cases, the B2BUA can select a=setup > > appropriately to avoid any issue. > > > > Is that an accurate summary, and is there consensus on this? > > The answer should probably be a=setup:passive, so that you don't have > any disconnect on what candidate pair is nominated. And you don't pay > an extra half-RTT. But otherwise, yes. > http://tools.ietf.org/html/rfc5763 recommends a=setup:active for the answerer, and Eric convinced me that any perf benefit from doing anything different was nominal. If the answerer's initial ICE checks reach the offerer, the client hello can be sent by the answerer in 1.5 RTT, or the offerer in 2.0 RTT: 0.0: A: offer 0.5 B: answer 0.5 B: binding request 1.0 A: binding response 1.0 A: triggered binding request (USE-CANDIDATE) 1.5 B: DTLS client hello If not, the client hello is sent by the answerer in 2.5 RTT, or the offerer in 2.0 RTT: 0.0: A: offer 0.5 B: answer 0.5 B: binding request (dropped) 1.0 A: binding request (USE-CANDIDATE) 1.5 B: binding response 1.5 B: triggered binding request 2.0 A: binding response 2.5 B: DTLS client hello So overall it's a bit of a wash, and therefore simpler to stick with 5763's recommendation. --e89a8f3ba56d26440104dbd456b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, May 3, 2013 at 10:29 AM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
On 2 May 2013 22:53, Justin Uberti <juberti@google.com> wrote:=
> This is where the OP's question came from - the differing policy b= etween
> Chrome and Firefox. I (regarding Chrome) had figured that if ICE had m= ade a
> determination regarding which side was in charge, the other layers in = the
> stack should do the same, but it sounds like there are already establi= shed
> rules on how to do this.
>
> From this thread, it sounds like the recommendation is to use
> a=3Dsetup:actpass in the offer, and then the answerer can use a=3Dsetu= p:active
> to choose the client role. In 3pcc cases, the B2BUA can select a=3Dset= up
> appropriately to avoid any issue.
>
> Is that an accurate summary, and is there consensus on this?

The answer should probably be a=3Dsetup:passive, so that you don'= t have
any disconnect on what candidate pair is nominated. =C2=A0And you don't= pay
an extra half-RTT. =C2=A0But otherwise, yes.

http= ://tools.ietf.org/html/rfc5763 recommends a=3Dsetup:active for the answ= erer, and Eric convinced me that any perf benefit from doing anything diffe= rent was nominal.=C2=A0

If the answerer's initial ICE checks reach the offe= rer, the client hello can be sent by the answerer in 1.5 RTT, or the offere= r in 2.0 RTT:
0.0: A: offer
0.5 B: answer
0.5 B: binding request
1.0 A: binding response
1.= 0 A: triggered binding request (USE-CANDIDATE)
1.5 B: DTLS client= hello

If not, the client hello is sent by t= he answerer in 2.5 RTT, or the offerer in 2.0 RTT:
0.0: A: offer
0.5 B: answer
0.5 B: bin= ding request (dropped)
1.0 A: binding request (USE-CANDIDATE)
1.5 B: binding response
1.5 B: triggered binding request
2.0 A: binding response
2.5 B: DTLS client hello

So overall it's a bit of a wash, and therefore si= mpler to stick with 5763's recommendation.
--e89a8f3ba56d26440104dbd456b0-- From prvs=08356ddaea=christer.holmberg@ericsson.com Fri May 3 13:03:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2090421F87CB for ; Fri, 3 May 2013 13:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.162 X-Spam-Level: X-Spam-Status: No, score=-5.162 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUw2HSH2V656 for ; Fri, 3 May 2013 13:03:38 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 924DA21F86AE for ; Fri, 3 May 2013 13:03:30 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-2a-518418113e40 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7F.9B.01956.11814815; Fri, 3 May 2013 22:03:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Fri, 3 May 2013 22:03:29 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Accept m- line, reject bundle Thread-Index: Ac5H/igNZNDXoaDWRAK0EIjSzLXMBAAACbGAAA6KqCI= Date: Fri, 3 May 2013 20:03:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B87D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se>, <5183D141.7060607@alum.mit.edu> In-Reply-To: <5183D141.7060607@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvra6gREugwaP/uhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxW2TlFhSFpyZnqdvl8Cd0fBsMntBu0DF5tun2BoYt/F0MXJySAiY SPyefIIFwhaTuHBvPVsXIxeHkMBhRomtHc/YIZzFjBIftm9m7GLk4GATsJDo/qcN0iAi4Cvx 7PFtNhBbWMBaYt67gywQcRuJm/uPM0PYVhJ/Lj4Hs1kEVCRervnIBDKGF6h3wqZ0kLCQQK7E v8sXwUo4BXQkXmxbAjaGEeie76fWMIHYzALiEreezGeCuFNAYsme88wQtqjEy8f/WCFsRYmd Z9uZIep1JBbs/sQGYWtLLFv4GizOKyAocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGJkz03M zEkvN9/ECIyFg1t+G+xg3HRf7BCjNAeLkjhvMldjoJBAemJJanZqakFqUXxRaU5q8SFGJg5O EMEl1cC4/uC73e+ycjJfvuL6u5NDeMJEn+uPr010f+k6Oev79ydM3fderfptdzu16vBVz4rq 7R1bpPS+tAqvXJGnLMmt/NN0gttjtx8ruGSybENcfx5aWbPZKlN7m9/x4MY0OSet6T+DlCaV 8K+cmcwj/Lq75msJw7fZiXNuxSZO/2Ok6TfTroNxd6SeEktxRqKhFnNRcSIA2w2GUlgCAAA= Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 20:03:44 -0000 Hi, >> Assume the following case: >> >> 1.An SDP offer contains an m- line associated with a BUNDLE group >> >> 2.The answerer wants to accept the m- line, but wants to reject it being >> in the specific BUNDLE group. >> >> A few alternatives on how this could be achieved have been presented: >> >> Alt 1. The answerer accepts the m- line, but does not associate it >> with a BUNDLE group. >> >> Alt 2. The answerer accepts the m- line, associates it with a >> BUNDLE group, and then sends a new offer which removes the m- line from >> the BUNDLE group. >> >> Alt 3. The answerer rejects the m- line, and then sends a new offer >> which adds the m- line outside a BUNDLE group. >> >> In my opinion, Alt 1 does not work, at least not if the offer contains >> identical port values for the m- lines associated with the BUNDLE group. >> It would mean that the m- line is not added to a BUNDLE group, but still >> has the same port value (at least at the offerer side) as the m- lines >> in the BUNDLE group, which is not allowed. >> >> So, my suggestion would be to specify that the answerer must use Alt 2 >> and/or Alt 3. > > I don't think we should restrict flexibility here when it works and > makes sense. > > I agree that Alt 1 doesn't work *if* the m-line in question shares > addr/prot with other m-lines that are also accepted, bundled or not. But > the normal first offer won't present that situation. If the addr/port in > the m-line in question is unique among all the accepted m-lines, then > this should be acceptable. > > (Note, this is a degenerate case of bundle splitting. There are real use > cases for it. If it can be done without a 2nd o/a, then lets allow that.) I was thinking that, by not allowing it, we could have a general rule sayin= g something like: "If an m- line in an offer is associated with a BUNDLE group, it MUST be as= sociated with a BUNDLE group in the associated answer, unless the answerer = sets the port value to zero." Regards, Christer From pkyzivat@alum.mit.edu Fri May 3 13:25:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6574821F9164 for ; Fri, 3 May 2013 13:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.162 X-Spam-Level: * X-Spam-Status: No, score=1.162 tagged_above=-999 required=5 tests=[AWL=1.599, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbIbDct9XJx9 for ; Fri, 3 May 2013 13:25:51 -0700 (PDT) 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 ACFCB21F8EC2 for ; Fri, 3 May 2013 13:25:51 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id XUNQ1l0010EZKEL55YRqqC; Fri, 03 May 2013 20:25:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id XYRq1l00X3ZTu2S3MYRqme; Fri, 03 May 2013 20:25:50 +0000 Message-ID: <51841D4C.7080404@alum.mit.edu> Date: Fri, 03 May 2013 16:25:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se>, <5183D141.7060607@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36B87D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36B87D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367612750; bh=IdID2scVzpR2iP/Sv4/u+0R/dlbkqG8giKpPbVKXad4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Hb3Qf0WoVx6s3t5u3TYf70A0taG9QpCWxTMHgyqX5wulHaYa4J3gtgYhLjHmWptsC yRo8Lk1atmqcaRD4nCljqh7fLxa5KPtA6OT5stJ9ztLIdY0aT+0+pFdfJp5hoe0EI7 OOBWZpEsy/9LagfZ8QRTb1zDw91b6fIkQKctvElLOxmRlDHXiMSH00Y8Zv9V24nH5K wSRZlKnJm1QrCB60ZFytJYTadeWwmzWWDcGDQDRbw+1ugoxmukbeoEb7rLz8RoBGL9 FyNGbdnclcj7jIGjJZskAsUtRvUS0B/ugRI2Oa0WCmcrY8A139gYohrU3mRdj9ShkB /jHKwjYjxRQfw== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 20:25:57 -0000 On 5/3/13 4:03 PM, Christer Holmberg wrote: > > Hi, > >>> Assume the following case: >>> >>> 1.An SDP offer contains an m- line associated with a BUNDLE group >>> >>> 2.The answerer wants to accept the m- line, but wants to reject it being >>> in the specific BUNDLE group. >>> >>> A few alternatives on how this could be achieved have been presented: >>> >>> Alt 1. The answerer accepts the m- line, but does not associate it >>> with a BUNDLE group. >>> >>> Alt 2. The answerer accepts the m- line, associates it with a >>> BUNDLE group, and then sends a new offer which removes the m- line from >>> the BUNDLE group. >>> >>> Alt 3. The answerer rejects the m- line, and then sends a new offer >>> which adds the m- line outside a BUNDLE group. >>> >>> In my opinion, Alt 1 does not work, at least not if the offer contains >>> identical port values for the m- lines associated with the BUNDLE group. >>> It would mean that the m- line is not added to a BUNDLE group, but still >>> has the same port value (at least at the offerer side) as the m- lines >>> in the BUNDLE group, which is not allowed. >>> >>> So, my suggestion would be to specify that the answerer must use Alt 2 >>> and/or Alt 3. >> >> I don't think we should restrict flexibility here when it works and >> makes sense. >> >> I agree that Alt 1 doesn't work *if* the m-line in question shares >> addr/prot with other m-lines that are also accepted, bundled or not. But >> the normal first offer won't present that situation. If the addr/port in >> the m-line in question is unique among all the accepted m-lines, then >> this should be acceptable. >> >> (Note, this is a degenerate case of bundle splitting. There are real use >> cases for it. If it can be done without a 2nd o/a, then lets allow that.) > > I was thinking that, by not allowing it, we could have a general rule saying something like: > > "If an m- line in an offer is associated with a BUNDLE group, it MUST be associated with a BUNDLE group in the associated answer, unless the answerer sets the port value to zero." Is the goal to minimize the number of words in the draft? :-) I think this would be eliminating a scenario with practical utility. And allowing it doesn't make the implementation significantly harder. (The offerer must be prepared for the whole bundle to be rejected. This is a variant of that. For the m-lines that are removed from the bundle it is as if the bundle had been rejected. For the other m-lines it is as if the bundle had been accepted. Thanks, Paul From eckelcu@cisco.com Fri May 3 21:40:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD95421F8FE8 for ; Fri, 3 May 2013 21:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjZ6DR80mJQo for ; Fri, 3 May 2013 21:40:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7421F8FDB for ; Fri, 3 May 2013 21:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1927; q=dns/txt; s=iport; t=1367642404; x=1368852004; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=eMs1cqlckTYQOKRX0BrYWLi4uT9i3wH3MtMASrVcWc0=; b=hfVI1+Zg2EMbrRdBvVdVuDIVG04Ka907radzC6vpuQm6f4PcPEkEj/Qp 8XGpCSF9HNQB4hLNHZO7GY9pq/JK3sMyDZk+r+8dfEMDImgQ+WX/hhJ5M GM3mkVFxWYrQj6sKdv30aXronc/7tX6d2v7cOoW0yIEgq2OIfsIkwrxI5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAECQhFGtJXG8/2dsb2JhbABQgwe/bHwWdIIfAQEBAwE6SwQCAQgRBAEBCxQJBzIUCQgBAQQBEgiHfgbBbY8AOAaCbGEDqF6DDYIn X-IronPort-AV: E=Sophos;i="4.87,609,1363132800"; d="scan'208";a="206346245" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 04 May 2013 04:40:04 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r444e4v2017679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 May 2013 04:40:04 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.28]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 3 May 2013 23:40:03 -0500 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: BUNDLE: Accept m- line, reject bundle Thread-Index: Ac5H/igNZNDXoaDWRAK0EIjSzLXMBAAP0M9w Date: Sat, 4 May 2013 04:40:02 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280481F602@xmb-aln-x08.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 04:40:14 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > On Behalf Of Christer Holmberg > Sent: Friday, May 03, 2013 6:07 AM > To: mmusic@ietf.org > Subject: [MMUSIC] BUNDLE: Accept m- line, reject bundle >=20 > Hi, >=20 >=20 >=20 > Assume the following case: >=20 >=20 >=20 > 1. An SDP offer contains an m- line associated with a BUNDLE > group >=20 > 2. The answerer wants to accept the m- line, but wants to reject it > being in the specific BUNDLE group. >=20 >=20 >=20 > A few alternatives on how this could be achieved have been > presented: >=20 >=20 >=20 > Alt 1. The answerer accepts the m- line, but does not associate it > with a BUNDLE group. > >=20 >=20 > Alt 2. The answerer accepts the m- line, associates it with a > BUNDLE group, and then sends a new offer which removes the m- > line from the BUNDLE group. >=20 >=20 >=20 > Alt 3. The answerer rejects the m- line, and then sends a new offer > which adds the m- line outside a BUNDLE group. >=20 >=20 >=20 > In my opinion, Alt 1 does not work, at least not if the offer contains > identical port values for the m- lines associated with the BUNDLE > group. It would mean that the m- line is not added to a BUNDLE > group, but still has the same port value (at least at the offerer side) > as the m- lines in the BUNDLE group, which is not allowed. True, but isn't that precisely what will happen if the answerer does not un= derstand/support BUNDLE? So at this point the offerer could choose to send a re-INVITE to use differ= ent receive ports for the non-bundled m-lines. I would not put that burden on the answerer. Cheers, Charles =20 >=20 >=20 > So, my suggestion would be to specify that the answerer must use Alt > 2 and/or Alt 3. >=20 >=20 >=20 > Comments? >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer From prvs=5836ffe653=christer.holmberg@ericsson.com Fri May 3 23:16:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2E21F9010 for ; Fri, 3 May 2013 23:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.379 X-Spam-Level: X-Spam-Status: No, score=-5.379 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMiPmmBPo+r7 for ; Fri, 3 May 2013 23:15:58 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AD97B21F90DF for ; Fri, 3 May 2013 23:15:57 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-97-5184a79b9021 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 19.B9.28165.B97A4815; Sat, 4 May 2013 08:15:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Sat, 4 May 2013 08:15:55 +0200 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "mmusic@ietf.org" Thread-Topic: BUNDLE: Accept m- line, reject bundle Thread-Index: Ac5H/igNZNDXoaDWRAK0EIjSzLXMBAAP0M9wABRDtuQ= Date: Sat, 4 May 2013 06:15:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B93A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se>, <92B7E61ADAC1BB4F941F943788C088280481F602@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280481F602@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvre6c5S2BBofuMltsmvWFzWLq8scs DkweU35vZPVYsuQnUwBTFLdNUmJJWXBmep6+XQJ3xoZLaxgLrglW3Oq9ztTAuJ+3i5GTQ0LA ROLE7B4mCFtM4sK99WwgtpDAYUaJ3d8cIOzFjBKnm3S7GDk42AQsJLr/aYOERQQiJF5O284C EhYWMJL4c6MOImwscWzCJlYI20qia2Yb2EQWARWJ/x/b2EHKeQV8JX7OzOpi5AIa3sco0T5l NVgNJ1B894u1jCA2I9A130+tAbuMWUBc4taT+VBXCkgs2XOeGcIWlXj5+B8rhK0ocXX6cqh6 HYkFuz+xQdjaEssWvgar5xUQlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxsucmZuaklxtu YgTGwcEtv3V3MJ46J3KIUZqDRUmcN4mrMVBIID2xJDU7NbUgtSi+qDQntfgQIxMHJ4jgkmpg NIle8OxWTb4pi/LdzG+rJy7Vu3fO/sqsS2VdhYVVKzZMVc/I8xaY5bND/XXvI8vjKcePHww9 cNfq8X1NtvqtE8WsHtjufjExS8KlViRianiy/KqNN15+DjDynG2Yf3dFoV3+qvQ4XRGZvJZd Eya7acQaJ7P8/3oo8tNS852n1Bl3h/25tShqjxJLcUaioRZzUXEiAH619l1WAgAA Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 06:16:04 -0000 Hi Charles, Just to clarify, I am talking about a case where the answerer DOES support = BUNDLE, but for some reason it does not want to accept the m- line within a= BUNDLE group. Regards, Christer ________________________________________ From: Charles Eckel (eckelcu) [eckelcu@cisco.com] Sent: Saturday, 04 May 2013 7:40 AM To: Christer Holmberg; mmusic@ietf.org Subject: RE: BUNDLE: Accept m- line, reject bundle > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > On Behalf Of Christer Holmberg > Sent: Friday, May 03, 2013 6:07 AM > To: mmusic@ietf.org > Subject: [MMUSIC] BUNDLE: Accept m- line, reject bundle > > Hi, > > > > Assume the following case: > > > > 1. An SDP offer contains an m- line associated with a BUNDLE > group > > 2. The answerer wants to accept the m- line, but wants to reject it > being in the specific BUNDLE group. > > > > A few alternatives on how this could be achieved have been > presented: > > > > Alt 1. The answerer accepts the m- line, but does not associate it > with a BUNDLE group. > > > > Alt 2. The answerer accepts the m- line, associates it with a > BUNDLE group, and then sends a new offer which removes the m- > line from the BUNDLE group. > > > > Alt 3. The answerer rejects the m- line, and then sends a new offer > which adds the m- line outside a BUNDLE group. > > > > In my opinion, Alt 1 does not work, at least not if the offer contains > identical port values for the m- lines associated with the BUNDLE > group. It would mean that the m- line is not added to a BUNDLE > group, but still has the same port value (at least at the offerer side) > as the m- lines in the BUNDLE group, which is not allowed. True, but isn't that precisely what will happen if the answerer does not un= derstand/support BUNDLE? So at this point the offerer could choose to send a re-INVITE to use differ= ent receive ports for the non-bundled m-lines. I would not put that burden on the answerer. Cheers, Charles > > > So, my suggestion would be to specify that the answerer must use Alt > 2 and/or Alt 3. > > > > Comments? > > > > Regards, > > > > Christer From prvs=58388c790f=christer.holmberg@ericsson.com Mon May 6 03:32:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0C621F8546; Mon, 6 May 2013 03:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.563 X-Spam-Level: X-Spam-Status: No, score=-5.563 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFQncySXTQWZ; Mon, 6 May 2013 03:32:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E3FDA21F8529; Mon, 6 May 2013 03:32:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-a3-518786b8c0fa Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3F.F0.01956.8B687815; Mon, 6 May 2013 12:32:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Mon, 6 May 2013 12:32:23 +0200 From: Christer Holmberg To: "sdp-directorate-private@ietf.org" , "mmusic@ietf.org" Thread-Topic: SDP Directorate review of draft-ietf-xrblock-rtcp-xr-jb-11 Thread-Index: Ac5KRC0U5crvTgKYQwGhehScBTxBnA== Date: Mon, 6 May 2013 10:32:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36BEDB@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C36BEDBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre6OtvZAgzV7hC3mLdrGbjF1+WMW i6ePdrA4MHssWfKTyePL5c9sAUxR3DZJiSVlwZnpefp2CdwZxxecYCzYJFdxafdM5gbGE1Jd jJwcEgImEvueNjFB2GISF+6tZ+ti5OIQEjjMKPFu1nVWkISQwGJGie8dQAkODjYBC4nuf9og YRGBAolr33sYQWxmgWyJc493MoPYwgLOEpvur2CFqPGQuHNiCjOErSex6f9usF0sAioSu5cc YQOxeQV8Ja6c+QRWzwh0w/dTa5ggZopL3HoyH+o2AYkle84zQ9iiEi8f/2OFsBUlrk5fDlWf L/GjYxcrxExBiZMzn7BMYBSehWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG 9lWM7LmJmTnp5eabGIHRcnDLb4MdjJvuix1ilOZgURLnTeZqDBQSSE8sSc1OTS1ILYovKs1J LT7EyMTBCSK4pBoY3Xfteakw79VFf55tk8/XNjgfbshtn/J+Od+LKZ2q7ZUXTK+5JP+M+bTu wS/Pqb6X4v/J2WefvsYR1iPrddLs48a8sDdOv04VFhckvfmfx+IdccwyXvXRw8oNWgffCZ79 f++MQMOX+ouNXzQula/nUuA/zWHc+K91z5Gi2fkdoTaScXWWVfcLlViKMxINtZiLihMBv5ck 8mkCAAA= Cc: "draft-ietf-xrblock-rtcp-xr-jb.all@tools.ietf.org" Subject: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-jb-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 10:32:35 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C36BEDBESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have been assigned to perform a SDP Directorate review of the document. The document does not define new SDP related procedures, but refers to the = procedures in RFC 3611. As was mentioned by Dan, it is allowed to use the feature without signaling= support in SDP. But, as that has been accepted already when RFC 3611 was m= ade, it would be messy to change it for this specific XR usage. So, from an SDP directorate perspective, I think the draft is ready for pub= lication. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C36BEDBESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have been assigned to perform a SDP Directorate re= view of the document.

 

The document does not define new SDP related procedu= res, but refers to the procedures in RFC 3611.

 

As was mentioned by Dan, it is allowed to use the fe= ature without signaling support in SDP. But, as that has been accepted alre= ady when RFC 3611 was made, it would be messy to change it for this specifi= c XR usage.

 

So, from an SDP directorate perspective, I think the= draft is ready for publication.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C36BEDBESESSMB209erics_-- From albrecht.schwarz@alcatel-lucent.com Mon May 6 05:42:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F6F21F8972 for ; Mon, 6 May 2013 05:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyWmccPku1Vu for ; Mon, 6 May 2013 05:42:03 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6AF21F901D for ; Mon, 6 May 2013 05:40:55 -0700 (PDT) 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 r46CekJ4024267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 May 2013 07:40:47 -0500 (CDT) 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 r46Cee9x014209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 May 2013 08:40:46 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 6 May 2013 08:40:45 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 6 May 2013 14:40:22 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "Mo Zanaty (mzanaty)" , Justin Uberti Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpl/XH1yp96NPUWvLDnzWSG5+pjwrh2AgAAD2gCAABUxgIAAXkyAgABRLxCAALuJAIABTZkAgAAPHYCABID4oA== Date: Mon, 6 May 2013 12:40:21 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC033489@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>, <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> <3879D71E758A7E4AA99A35DD8D41D3D91D45A655@xmb-aln-x14.cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0329D7@FR711WXCHMBA03.zeu.alcatel-lucent.com> <3879D71E758A7E4AA99A35DD8D41D3D91D462E4B@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D462E4B@xmb-rcd-x14.cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC033489FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 12:42:09 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC033489FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mo the root cause in your argumentation seems to be related to the term "clien= t/server". Looks like that you are equating "TLS client" equal to "TCP client" etc, ri= ght? However (in our discussion), "client/server" is a protocol, - and thus a pr= otocol layer -, specific concept. RFC 793 is about TCP client/server entities. RFC 5246 is about TLS client/server entities (and NOT TCP client/server). RFC 4975 defines MSRP client and servers (such as a MSRP conference server)= as an example of application protocol related client/server concepts (e.g.= , MSRP/TLS/TCP). RFC 4582 defines BFCP floor control client/server entities as an example of= application protocol related client/server concepts (e.g., BFCP/TLS/TCP). Second: RFCs for user plane (protocols) (above list) and control plane (her= e SIP and SDP) are different items. An SDP RFC can't "redefine" above RFCs. Right, there might be gaps, hidden assumptions, not documented requirements= in some of the referred SDP RFCs, but we shouldn't mix both areas. Regards, Albrecht From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] Sent: Freitag, 3. Mai 2013 18:54 To: Schwarz, Albrecht (Albrecht); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation TLS RFC 5246 section 7.4.1.2: When a client first connects to a server, it is required to send the Client= Hello as its first message. TCP RFC 793 section 2.7: The OPEN call also specifies whether the connection establishment is to be = actively pursued, or to be passively waited for. You are correct that TLS does not specify any tight coupling to TCP, but ho= w can you interpret the above to mean anything other than "clients actively= connect to passive servers"? Since TLS and DTLS do not support negotiating client/server roles, but rath= er derive them from the connection (and DTLS-SRTP specifies how to negotiat= e the connection as active/passive/actpass in SDP O/A), how would you suppo= rt the role inversion you propose? How would a TCP listener know whether it= can invert roles from server to client and send TLS ClientHello? Perhaps EKR can chime in, but I just don't see the flexibility you describe= being supported in TLS, so I don't see why SDP would need extensions to si= gnal such flexibility. Mo From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: Friday, May 03, 2013 10:13 AM To: Mo Zanaty (mzanaty); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation Mo > If you mean TCP and TLS client/server roles can differ, I don't see that = flexibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense = for SDP to describe flexibility which is not supported in the underlying pr= otocol. I disagree with your refered justification, primarily because 1. RFC 5246, sec. 7.4 does not provide such info explicitly ("can't find a= ny TCP related info") 2. TLS itself (RFC 5246) is designed to be transport protocol independent = (see section 1: "At the lowest level, layered on top of some reliable trans= port protocol ...") 3. TLS-over-SCTP (RFC 3436): there is not any client/server concept in SCT= P (RFC 2960)! SCTP associations are established between two SCTP endpoints = ... (rather a peer-to-peer concept than client/server) 4. TLS-over-TCP: the establishment of a TLS session could be principally d= elayed wrt the TCP connection establishment; the TCP client/server role is = ONLY relevant during the state transitioning from CLOSED to ESTAB (RFC 793)= ; ie the TCP roles "dissolve" with a successfully established TCP connectio= n state. I fail to see any tight coupling between TLS and TCP. Regards, Albrecht From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] Sent: Donnerstag, 2. Mai 2013 22:06 To: Schwarz, Albrecht (Albrecht); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation > role assignments at IP transport layer and security session layer may pri= ncipally be different! If you mean TCP and TLS client/server roles can differ, I don't see that fl= exibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense fo= r SDP to describe flexibility which is not supported in the underlying prot= ocol. I agree it is somewhat confusing for DTLS-SRTP to use an attribute original= ly defined for TCP, but I don't see any practical problem or deficiency tha= t would be solved by the proposed "a=3Dsetup:PROTOCOL:" attribute extension= . Mo From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: Thursday, May 02, 2013 3:15 AM To: Mo Zanaty (mzanaty); Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation The RFC situation is not really clear, even confusing concerning client/ser= ver role negotiations (in case of transport security sessions over connecti= on-oriented IP transport protocols). =B7 RFC 4145 is only about TCP, i.e., TCP client/server role assign= ments. Thus, the RFC 4145 introduced SDP attribute is TCP specific. =B7 draft-ietf-mmusic-sctp-sdp: seems to profile the "a=3Dsetup:" a= ttribute for SCTP path establishment directions ... (?) =B7 RFC 5763 uses the TCP SDP attribute for DTLS session establishm= ent, i.e. DTLS client/server role assignments; that's actually a semantical= change of this SDP element vs RFC 4145 ... and DTLS is TLS based, leading to the question of role/assignments in c= ase of TLS/TCP sessions? I.e., the TCP client/server and also TLS client/server roles? Keeping in mi= nd that the role assignments at IP transport layer and security session lay= er may principally be different! The "a=3Dsetup" definition by RFC 4145 is unfortunate in my opinion. Required seems to be a generic SDP specification (i.e., outside RFC 4145), = which may be then tight to the concerned protocol. Sth like an explicit ind= ication "a=3Dsetup:PROTOCOL:" or an implicit indication by adding an identi= fier. The "m=3D" line element does not really help to reduce ambiguity (a= s Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "= transport". The proto field identifies a whole stack of protocol layers."). Albrecht PS I would see following parameter values for a SDP "a=3Dsetup:PROTOCOL:" attr= ibute extension: L4: TCP, SCTP, DCCP(?) L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling ...) From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty) Sent: Donnerstag, 2. Mai 2013 06:04 To: Justin Uberti Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the = other leg will answer with active or passive but not actpass. A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and= alter SDP in complex ways to generate two answers from two offers, part of= which is deciding which answer should become active and which should becom= e passive. The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unalter= ed by a B2BUA which delays offers on both legs. Generating two answers from= two offers is much more complex than simply forwarding the offers as answe= rs. DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be act= pass. TCP is harder since RFC 4145 allows offers to be active, passive, or = actpass, causing more complex reinvites to resolve active/active or passive= /passive conflicts. Mo On May 1, 2013, at 6:28 PM, "Justin Uberti" > wrote: I think Paul means the active/passive attributes in RFC 5763, but I'm still= not sure about how 3rd party call control would be handled in this case, i= .e. when both endpoints think they are offerers and set a=3Dsetup:actpass. ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.= 11. On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa > wrote: I saw it, but that is all about TCP client/server role and not DTLS client/= server role. Are we supposed to use the same "setup" attribute for dtls r= ole negotiation even if it is over UDP? I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something. On 01/05/2013, at 13:56, Paul Kyzivat wrote: > On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote: >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which= side is the DTLS server must be established via some out-of-band mechanism= such as SDP." >> >> What is the specification on how to signal that in SDP? >> >> Specifically in case of 3pcc where both endpoints are SDP offerers which= one should take the client and server roles for DTLS? Should we tie tha= t role to ICE controlled/controlling roles or should we negotiate it in the= SDP somehow? > > See RFC4145. > > _______________________________________________ > 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 --_000_786615F3A85DF44AA2A76164A71FE1AC033489FR711WXCHMBA03zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mo

 

the root cause in your argume= ntation seems to be related to the term “client/server”.

Looks like that you are equat= ing “TLS client” equal to “TCP client” etc, right?<= o:p>

 

However (in our discussion), = “client/server” is a protocol, - and thus a protocol layer -, s= pecific concept.

RFC 793 is about TCP client/s= erver entities.

RFC 5246 is about TLS client/= server entities (and NOT TCP client/server).

 

RFC 4975 defines MSRP client = and servers (such as a MSRP conference server) as an example of application= protocol related client/server concepts (e.g., MSRP/TLS/TCP).

 

RFC 4582 defines BFCP floor c= ontrol client/server entities as an example of application protocol related= client/server concepts (e.g., BFCP/TLS/TCP).

 

 

Second: RFCs for user plane (= protocols) (above list) and control plane (here SIP and SDP) are different = items. An SDP RFC can’t “redefine” above RFCs.=

Right, there might be gaps, h= idden assumptions, not documented requirements in some of the referred SDP = RFCs, but we shouldn’t mix both areas.

 

Regards,

Albrecht

 

 

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: Freitag, 3. Mai 2013 18:54
To: Schwarz, Albrecht (Albrecht); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

TLS RFC 5246 section 7.4= .1.2:

When a client first conn= ects to a server, it is required to send the ClientHello as its first messa= ge.

 =

TCP RFC 793 section 2.7:=

The OPEN call also speci= fies whether the connection establishment is to be actively pursued, or to = be passively waited for.

 =

You are correct that TLS= does not specify any tight coupling to TCP, but how can you interpret the = above to mean anything other than “clients actively connect to passive servers”?

 =

Since TLS and DTLS do no= t support negotiating client/server roles, but rather derive them from the = connection (and DTLS-SRTP specifies how to negotiate the connection as active/passive/actpass in SDP O/A), how would you support the role inve= rsion you propose? How would a TCP listener know whether it can invert role= s from server to client and send TLS ClientHello?

 =

Perhaps EKR can chime in= , but I just don’t see the flexibility you describe being supported i= n TLS, so I don’t see why SDP would need extensions to signal such flexibility.

 =

Mo

 =

 =

From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com<= /a>]
Sent: Friday, May 03, 2013 10:13 AM
To: Mo Zanaty (mzanaty); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org=
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

Mo

 

> If you mean TCP and TLS client/server roles can differ, I don= 217;t see that flexibility in TLS itself (RFC 5246 section 7.4), so it doesnR= 17;t make sense for SDP to describe flexibility which is not supported in t= he underlying protocol.

 

I disagree with your refered = justification, primarily because

1.  RFC 5246, sec. 7.4 do= es not provide such info explicitly (“can’t find any TCP relate= d info”)

2.  TLS itself (RFC 5246)= is designed to be transport protocol independent (see section 1: “At the lowest level, layered on top of some reliable transport protocol …”)

3.  TLS-over-SCTP (RFC 34= 36): there is not any client/server concept in SCTP (RFC 2960)! SCTP associ= ations are established between two SCTP endpoints … (rather a peer-to-peer concept than client/server)

4.  TLS-over-TCP: the est= ablishment of a TLS session could be principally delayed wrt the TCP connec= tion establishment; the TCP client/server role is ONLY relevant during the state transitioning from CLOSED to ESTAB (RFC = 793); ie the TCP roles “dissolve” with a successfully establish= ed TCP connection state.

 

I fail to see any tight coupl= ing between TLS and TCP.

 

Regards,

Albrecht

 

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: Donnerstag, 2. Mai 2013 22:06
To: Schwarz, Albrecht (Albrecht); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org=
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

> role assignments at= IP transport layer and security session layer may principally be different= !

 =

If you mean TCP and TLS = client/server roles can differ, I don’t see that flexibility in TLS i= tself (RFC 5246 section 7.4), so it doesn’t make sense for SDP to describe flexibility which is not supported in the underlying protocol.

 =

I agree it is somewhat c= onfusing for DTLS-SRTP to use an attribute originally defined for TCP, but = I don’t see any practical problem or deficiency that would be solved by the proposed “a=3Dsetup:PROTOCOL:” attribute exte= nsion.

 =

Mo

 =

 =

From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com<= /a>]
Sent: Thursday, May 02, 2013 3:15 AM
To: Mo Zanaty (mzanaty); Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org=
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

The RFC situation is not real= ly clear, even confusing concerning client/server role negotiations (in cas= e of transport security sessions over connection-oriented IP transport protocols).

 

=B7    =      RFC 4145 is only abou= t TCP, i.e., TCP client/server role assignments. Thus, the RFC 4145 introdu= ced SDP attribute is TCP specific.

=B7    =      draft-ietf-mmusic-sct= p-sdp: seems to profile the “a=3Dsetup:” attribute for SCTP pat= h establishment directions … (?)

=B7    =      RFC 5763 uses the TCP= SDP attribute for DTLS session establishment, i.e. DTLS client/server role= assignments; that’s actually a semantical change of this SDP element vs RFC 4145

 

… and DTLS is TLS based= , leading to the question of role/assignments in case of TLS/TCP sessions?<= o:p>

I.e., the TCP client/server a= nd also TLS client/server roles? Keeping in mind that the role assignments = at IP transport layer and security session layer may principally be different!

 

The “a=3Dsetup” d= efinition by RFC 4145 is unfortunate in my opinion.

Required seems to be a generi= c SDP specification (i.e., outside RFC 4145), which may be then tight to th= e concerned protocol. Sth like an explicit indication “a=3Dsetup:PROTOCOL:” or an implicit indication by adding an i= dentifier.

 

The “m=3D” lin= e <proto> element does not really help to reduce ambiguity (as Paul r= eminded again: ““Unfortunately SDP has a pretty confusing idea of "transport". The proto field = identifies a whole stack of protocol layers.&= #8221;).

 

Albrecht

PS

I would see following paramet= er values for a SDP “a=3Dsetup:PROTOCOL:” attribute extension:<= o:p>

L4: TCP, SCTP, DCCP(?)

L4+: TLS, DTLS, DTLS-SRTP= (?, due to RFC 5764 SDP profiling …)

 

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; mmusic@ietf.org=
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation<= /o:p>

 

A simple 3PCC/B2BUA only delays offers toward one le= g like RFC3725, so the other leg will answer with active or passive but not= actpass.

 

A complex 3PCC/B2BUA delays offers toward both legs,= so it must analyze and alter SDP in complex ways to generate two answers f= rom two offers, part of which is deciding which answer should become active= and which should become passive.

 

The flow in RFC 5245 B.11 is oversimplified. SDP can= 't be forwarded unaltered by a B2BUA which delays offers on both legs. Gene= rating two answers from two offers is much more complex than simply forward= ing the offers as answers.

 

DTLS-SRTP is actually an easy case since RFC 5763 re= quires offers to be actpass. TCP is harder since RFC 4145 allows offers to = be active, passive, or actpass, causing more complex reinvites to resolve a= ctive/active or passive/passive conflicts.

 

Mo



On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> wrote:

I think Paul means the active/passive attributes in = RFC 5763, but I'm still not sure about how 3rd party call control would be = handled in this case, i.e. when both endpoints think they are offerers and = set a=3Dsetup:actpass.

 

ICE has logic to determine roles in this scenario, a= s shows in RFC 5245, B.11. 

 

On Wed, May 1, 2013 at 2:10 PM, Gustavo Garc=EDa <= ;ggb@tokbox.com>= wrote:

I saw it, but that is all about TCP client/server ro= le and not DTLS client/server role.   Are we supposed to use the same = "setup" attribute for dtls role negotiation even if it is over UD= P?

I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misun= derstanding something.


On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> On 5/1/13 2:26 PM, Gustavo Garc=EDa wrote:
>> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS clien= t and which side is the DTLS server must be established via some out-of-ban= d mechanism such as SDP."
>>
>> What is the specification on how to signal that in SDP?
>>
>> Specifically in case of 3pcc where both endpoints are SDP offerers= which one should take the client and server roles for DTLS?    S= hould we tie that role to ICE controlled/controlling roles or should we neg= otiate it in the SDP somehow?
>
> See RFC4145.
>
> _______________________________________________
> 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.o= rg/mailman/listinfo/mmusic

--_000_786615F3A85DF44AA2A76164A71FE1AC033489FR711WXCHMBA03zeu_-- From harald@alvestrand.no Mon May 6 07:19:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7488221F933F; Mon, 6 May 2013 07:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGkrYffG5Oj6; Mon, 6 May 2013 07:19:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8D21F920B; Mon, 6 May 2013 07:19:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F20D139E1C8; Mon, 6 May 2013 16:19:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDCyLKZMmVQJ; Mon, 6 May 2013 16:19:49 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3AC6839E1BD; Mon, 6 May 2013 16:19:49 +0200 (CEST) Message-ID: <5187BC04.1030200@alvestrand.no> Date: Mon, 06 May 2013 16:19:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Justin Uberti References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030903070701050308060208" Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:19:56 -0000 This is a multi-part message in MIME format. --------------030903070701050308060208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved. The silence on this issue is disquieting. Harald On 05/03/2013 08:08 AM, Justin Uberti wrote: > Scribbled down the basic concepts of what I have been referring to as > "Plan B" - a way to signal multiple MediaStreamTracks in SDP without > needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: > > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media > sources in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030903070701050308060208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved.

The silence on this issue is disquieting.

           Harald


On 05/03/2013 08:08 AM, Justin Uberti wrote:
Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each.

Hopefully this will make discussion of this topic easier.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00


Abstract:
   This document explains how multiple media sources can be signaled in
   WebRTC using SDP, in a fashion that avoids many common problems and
   provides a simple control surface to the receiver.




The IETF Secretariat





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

--------------030903070701050308060208-- From worley@shell01.TheWorld.com Mon May 6 11:01:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E9521F92EC for ; Mon, 6 May 2013 11:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Himkbzl5d3ep for ; Mon, 6 May 2013 11:01:06 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7F32F21F92EF for ; Mon, 6 May 2013 11:01:06 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r46I0mN1004428; Mon, 6 May 2013 14:00:50 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r46I0lZ64254394; Mon, 6 May 2013 14:00:48 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r46I0jM84247693; Mon, 6 May 2013 14:00:45 -0400 (EDT) Date: Mon, 6 May 2013 14:00:45 -0400 (EDT) Message-Id: <201305061800.r46I0jM84247693@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Bernard Aboba In-reply-to: (bernard_aboba@hotmail.com) References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se>, <517FFB7E.8050801@alum.mit.edu>, , <51801BBD.1010505@alum.mit.edu>, , , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se>, <201305030115.r431Fis33999826@shell01.TheWorld.com> Cc: mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 18:01:12 -0000 > From: Bernard Aboba > > > But it doesn't seem that there is much to gain by mandating rtcp-mux > > in the first offer/answer, the one where actual bundling is not being > > done. All of the RTP/RTCP routing code that is active at that point > > has to support non-rtcp-mux operation already. > > [BA] Support for rtcp-mux in the first offer/answer is mandated by > RFC 5761 Section 5.1.3: > The initial SDP offer MUST include this > attribute at the media level to request multiplexing of RTP and RTCP > on a single port. I don't see how 5761 mandates that a=rtcp-mux MUST be used in the first offer of a bundle negotiation. The context of your quote is: 5.1.3. Interactions with ICE [...] If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired. That is, if the device desires to use both ICE and multiplex, it has to use a=rtcp-mux in the first offer of ICE's set of offers. But we're talking about bundling, which (in the current design) contains *two* ICE cycles, since the second offer (in the bundle spec) is going to restart ICE. And the device need not "desire" to use "both ICE and multiplexed RTP and RTCP" during the first of the ICE cycles. Dale From worley@shell01.TheWorld.com Mon May 6 11:01:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F57621F9343 for ; Mon, 6 May 2013 11:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id betw-RwZCney for ; Mon, 6 May 2013 11:01:13 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id CE4E221F92EC for ; Mon, 6 May 2013 11:01:12 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r46I0SBN028011; Mon, 6 May 2013 14:00:30 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r46I0SeB4262937; Mon, 6 May 2013 14:00:28 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r46I0R6t4259110; Mon, 6 May 2013 14:00:27 -0400 (EDT) Date: Mon, 6 May 2013 14:00:27 -0400 (EDT) Message-Id: <201305061800.r46I0R6t4259110@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <5183D141.7060607@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> <5183D141.7060607@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 18:01:19 -0000 > From: Paul Kyzivat > > (Note, this is a degenerate case of bundle splitting. There are real use > cases for it. If it can be done without a 2nd o/a, then lets allow that.) Strictly speaking, it's not like other cases of bundle splitting, because the separated m= line is not put into another bundle, but remains unbundled. Because of that, the design considerations are likely to be somewhat different. Dale From pkyzivat@alum.mit.edu Mon May 6 11:42:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36B221F86DE for ; Mon, 6 May 2013 11:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32jBdCN4Fanu for ; Mon, 6 May 2013 11:42:25 -0700 (PDT) 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 96C9B21F859C for ; Mon, 6 May 2013 11:42:22 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id YgqU1l0041c6gX858iiMX1; Mon, 06 May 2013 18:42:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id YiiL1l01T3ZTu2S3jiiLsh; Mon, 06 May 2013 18:42:21 +0000 Message-ID: <5187F98C.6010705@alum.mit.edu> Date: Mon, 06 May 2013 14:42:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, 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=1367865741; bh=DIv3LkZRPqyA5Hlv8kqYo07RERmS6OsLITJDh0L1Y7A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=D3EWPJ9r/BBt90lFXnL7E5eE5AzaKrrUrcf1OiFZfNS6DrQLKoVTE3eOG54y0/Ds7 GPRZJOkz1o/SNk9IR7zrOKbP6p+oHRoGDCbk7LyhRvNw2J6mxTRBTht/ru+w/XjO5o pu9xkYa1v9+/30+iBFR4yNFRgDlxNkUxqhvwds3oQLzIhett5fYkiN5e319w5i3JRu vGCFxlK7tG8A0mR7hBB6jpgPZWTiOEnYNIkbH8NAn/dR18sH3L9VTSmtt+X9dz37++ UXJnZDAYiDLwmuwyB+9XRILdckWKeYOR2eVlJ03EtL2YlhZ8Jkn0ZshBocFE14qDmZ ACpl9P8oVKk7w== Subject: [MMUSIC] syntax for attributes in 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 18:42:31 -0000 I have been working on an SDP Directorate review of a draft that defines some new SDP attributes. In the process of doing that I came across some things that I think ought to be improved in 4566bis: 1) The formal syntax for SDP in 4566 defines a generic syntax for attributes: attribute-fields = *(%x61 "=" attribute CRLF) attribute = (att-field ":" att-value) / att-field att-field = token att-value = byte-string This is fine. Elsewhere it defines a number of specific attributes: a=cat: ... a=keywds: .... These are defined with informal patterns such as above, along with text. There is no formal specification of the syntax of the values of these attributes. Then in the IANA considerations section these attributes are added to the IANA registry of SDP attributes. The main problem with the above is the lack of syntax for the values. With newer attributes in other drafts we have typically required ABNF. I think 4566bis ought to provide ABNF syntax for all of the attributes it defines. 2) If syntax is to be provided, then there is a question of *how* it should be done. There are a number of possibilities. Here are two: - link it right into the full SDP syntax. E.g., cat-attr = "cat:" category category = token attribute =/ cat-attr - define the syntax of the attribute, but *don't* link it into the the full SDP syntax. In my opinion it is better to *not* link into the general syntax. It doesn't matter much for this draft, but it sets a bad precedent for other drafts that define attributes. Each draft that does so (via use of 'attribute =/ ...' is an *update* to the rfc that defines 'attribute', and should be marked as such. The existence of the IANA registry for attributes means that it is not necessary to formally extend the syntax of 'attribute' and so the draft need not be an update. Whatever we do here will become a defacto template for how future drafts define attributes. So we should make it a good example. 3) The IANA registration of attributes has become a mess. Section 8.2.4 both defines the IANA registry for attributes and populates it with the attributes defined in the draft. But it doesn't precisely specify the name or format of the table. It *does* specify what information must be provided. What is actually present in IANA are *four* different tables for attributes: SDP Parameters att-field (both session and media level) SDP Parameters att-field (media level only) SDP Parameters att-field (session level) SDP Parameters att-field (source level) SDP Parameters att-field (unknown level) This is hard to read, and its hard for a draft to specify precisely what table things should go in. I suggest it would be good to reorganize the IANA registry, so that it only has one table, with a separate column (or columns) to indicate where the attribute may be used: session, media, source. Then ensure that the registrations for the attributes defined in the bis are good examples of how to use this, including explicitly referencing the table to be updated. 4) RFC5576 introduced the notion of source-level attributes. In principle the same attributes may be used at source level and the other levels, so they should be incorporated into the same table structure. Some thought ought to be given to how to ensure 4566bis integrates well with 5576 regarding definition and registration of attributes. Perhaps it would be better to make 4566bis replace 5576 as well. Or maybe that isn't necessary. Should be discussed. Thanks, Paul From worley@shell01.TheWorld.com Mon May 6 15:02:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037D721F9361 for ; Mon, 6 May 2013 15:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtY0fVN2-YRQ for ; Mon, 6 May 2013 15:02:02 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 149B721F9348 for ; Mon, 6 May 2013 15:02:01 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r46M1GIt016286; Mon, 6 May 2013 18:01:18 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r46M1FKa4270312; Mon, 6 May 2013 18:01:15 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r46M1F9j4269523; Mon, 6 May 2013 18:01:15 -0400 (EDT) Date: Mon, 6 May 2013 18:01:15 -0400 (EDT) Message-Id: <201305062201.r46M1F9j4269523@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C368754@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> <201304251933.r3PJXuon3430760@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36098D@ESESSMB209.ericsson.se> <201304292200.r3TM0GmX3712511@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C368754@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 22:02:08 -0000 > From: Christer Holmberg > > > But if the SBC does not reprocess media, but only *edits* what > > media descriptions it permits in the SDP that it passes through, > > then bundling can succeed as long as the bundling specification > > does not require any element that the SBC removes. > > I still don't get it :) > > If an SBC needs to reprocess media, it obviously need to support the > codecs used. But, that is true no matter whether BUNDLE is used or > not. Yes, if you only consider the case of an SBC that needs to reprocess media, then there is nothing that can be done. But *the case I'm considering* is when the intermediate element (it might not be a proper SBC) edits the SDP but does not need to reprocess media. Dale From christer.holmberg@ericsson.com Tue May 7 00:39:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9EC21F9121 for ; Tue, 7 May 2013 00:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQbmbVBdrR5d for ; Tue, 7 May 2013 00:38:54 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DB9A821F8F62 for ; Tue, 7 May 2013 00:38:53 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-ed-5188af8c0d95 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 63.42.32006.C8FA8815; Tue, 7 May 2013 09:38:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Tue, 7 May 2013 09:38:52 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOQevTi+cVnxjNCEKSb6lvFRbbnJjnWrcQgAZrVnmAAJ8XsIAKYbLPgACg2WA= Date: Tue, 7 May 2013 07:38:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36C6D3@ESESSMB209.ericsson.se> References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> <201304251933.r3PJXuon3430760@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36098D@ESESSMB209.ericsson.se> <201304292200.r3TM0GmX3712511@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C368754@ESESSMB209.ericsson.se> <201305062201.r46M1F9j4269523@shell01.TheWorld.com> In-Reply-To: <201305062201.r46M1F9j4269523@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvrW7P+o5Agz9T5S2mLn/MYvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfG0+S9TwX22ir17FjA1MC5m7WLk5JAQMJHY dXU6I4QtJnHh3nq2LkYuDiGBw4wSO7dMZodwFjNKPL54EqiKg4NNwEKi+582iCkioCnRsSAH xGQWUJe4ujgIZIwwUMH5lpPMILaIgKXEzeXnWSBsP4kNvd/ZQGwWARWJnXsPgNm8Ar4Sc5d/ Y4bYtIpFYsH1T6wgMzkFHCSeTosCqWEEOu37qTVMIDazgLjErSfzmSBOFpBYsuc8M4QtKvHy 8T+otxQlrk5fDlWvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaW VYzsuYmZOenlRpsYgdFxcMtv1R2Md86JHGKU5mBREudN5moMFBJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cAov5yjWLDy2onGWbW30t6sWX+s7YPBPp3IyW+PX3Xvbv02c0X76f1rtoROXTxr 6uZ52+61mwSd+Xh0ybZNws8+KNtEZQWqbF+0a9EenrmyUh7C1VJvHN6X/GM9+9BZ/NKFIxsL NvLGz58+51VaapJ97CxD9XnsZ5OOSGcmpnyvrZwcxeX2J2d+oBJLcUaioRZzUXEiABwycQtc AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 07:39:03 -0000 Hi, >>> But if the SBC does not reprocess media, but only *edits* what media=20 >>> descriptions it permits in the SDP that it passes through, then=20 >>> bundling can succeed as long as the bundling specification does not=20 >>> require any element that the SBC removes. >>=20 >> I still don't get it :) >>=20 >> If an SBC needs to reprocess media, it obviously need to support the=20 >> codecs used. But, that is true no matter whether BUNDLE is used or=20 >> not. > > Yes, if you only consider the case of an SBC that needs to reprocess medi= a, then there is nothing that can be done. > > But *the case I'm considering* is when the intermediate element (it might= not be a proper SBC) edits the SDP but does not need to reprocess media. Well, in that case it doesn't need to support the codec either, does it? Regards, Christer From christer.holmberg@ericsson.com Tue May 7 02:54:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6109021F8D2C for ; Tue, 7 May 2013 02:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATKupqwBVYBK for ; Tue, 7 May 2013 02:53:54 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AA40121F8C23 for ; Tue, 7 May 2013 02:53:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-e0-5188cf23d451 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7B.68.28165.32FC8815; Tue, 7 May 2013 11:53:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Tue, 7 May 2013 11:53:38 +0200 From: Christer Holmberg To: "Dale R. Worley" , Bernard Aboba Thread-Topic: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? Thread-Index: Ac5FpkrHryzI/aQNT0iUvXy00zH5hwADtcYAAAPFvoAAAQhZgAA4imSAABwqMXAABklLyAAANmRgABmo8HEABBaqAAC15MErACEgllA= Date: Tue, 7 May 2013 09:53:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36C89A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se>, <517FFB7E.8050801@alum.mit.edu>, , <51801BBD.1010505@alum.mit.edu>, , , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se>, <201305030115.r431Fis33999826@shell01.TheWorld.com> <201305061800.r46I0jM84247693@shell01.TheWorld.com> In-Reply-To: <201305061800.r46I0jM84247693@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvra7y+Y5Ag7OLhS32L7nMbDF1+WMW i5cnyhyYPSbv/8rs8bjnDJvHkiU/mQKYo7hsUlJzMstSi/TtErgy3k2ezVZwla/ixOmrzA2M u7m7GDk4JARMJI5/K+ti5AQyxSQu3FvP1sXIxSEkcJhRorXrKpSzmFFi3fpHzCANbAIWEt3/ tEEaRATCJPr/PmAHCTMLqEtcXRwEEhYWsJFo2rGTGaLEVmLKvRvsEHaZxMpZr1hBbBYBFYn+ l+sYQWxeAV+Jm0fOsUKsesEi0bFxDlgzp4CDxI8NLWA2I9Bx30+tYQKxmQXEJW49mc8EcbSA xJI955khbFGJl4//sULYihJXpy+HqteRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlI WmYhaZmFpGUBI8sqRvbcxMyc9HLDTYzAmDm45bfuDsZT50QOMUpzsCiJ8yZxNQYKCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYPReePQMl8nbdYXyGsy3g8K27+NclR348LrrzU89+wSN7h7/ e22C81Ym21Ce9ex+VqsmZtTHNTx9eSS7u7ky3WHTVmue7u26Abnc97UU0yuOyz2+soO5P+7u TbeunIVVW10WO/Flm8uHW/eqpydPqhN5PmWlbbgcT+RWsxqJ1/Nben7vee/8QImlOCPRUIu5 qDgRAJ6F7SFnAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:54:00 -0000 Hi, >>> But it doesn't seem that there is much to gain by mandating rtcp-mux=20 >>> in the first offer/answer, the one where actual bundling is not=20 >>> being done. All of the RTP/RTCP routing code that is active at that=20 >>> point has to support non-rtcp-mux operation already. >> >> [BA] Support for rtcp-mux in the first offer/answer is mandated by=20 >> RFC 5761 Section 5.1.3: >> The initial SDP offer MUST include this >> attribute at the media level to request multiplexing of RTP and RTCP >> on a single port.=20 > > I don't see how 5761 mandates that a=3Drtcp-mux MUST be used in the first= offer of a bundle negotiation. The context of your quote is: > > 5.1.3. Interactions with ICE > [...] > If it is desired to use both ICE and multiplexed RTP and RTCP, the > initial offer MUST contain an "a=3Drtcp-mux" attribute to indicate that > RTP and RTCP multiplexing is desired and MUST contain "a=3Dcandidate:" > lines for both RTP and RTCP along with an "a=3Drtcp:" line indicating a > fallback port for RTCP in the case that the answerer does not support > RTP and RTCP multiplexing. This MUST be done for each media where > RTP and RTCP multiplexing is desired.< > > That is, if the device desires to use both ICE and multiplex, it has to u= se a=3Drtcp-mux in the first offer of ICE's set of offers. But we're talki= ng about bundling, which (in the current design) contains > *two* ICE cycles, since the second offer (in the bundle spec) is going to= restart ICE. And the device need not "desire" to use "both ICE and multip= lexed RTP and RTCP" during the first of the ICE cycles. As indicated, BUNDLE actually already DOES mandate a=3Drtcp-mux in the firs= t offer, but it is optional for the answer, to the suggestion is to mandate= it in the first answer. Regards, Christer From christer.holmberg@ericsson.com Tue May 7 03:12:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDB921F85BF; Tue, 7 May 2013 03:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge-w-QSuBd9L; Tue, 7 May 2013 03:11:58 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 51D2421F8574; Tue, 7 May 2013 03:11:57 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-a6-5188d36ccc50 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A6.2E.32006.C63D8815; Tue, 7 May 2013 12:11:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Tue, 7 May 2013 12:11:55 +0200 From: Christer Holmberg To: Harald Alvestrand , Justin Uberti Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOR8S71uamUT1UgU2fGg1LHYFLV5j4GHYAgAE/1LA= Date: Tue, 7 May 2013 10:11:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> In-Reply-To: <5187BC04.1030200@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C36C8EBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+JvrW7O5Y5Ag2XzJS2O9XWxWWydKmQx dfljFou1/9rZHVg8rky4wuqxYFOpx5IlP5kCmKO4bFJSczLLUov07RK4Mm7d+Mdc0NjDWDH3 w1e2BsZF1V2MnBwSAiYS617uZoOwxSQu3FsPZHNxCAkcZpQ4fL+JHcJZzCix/VAfUIaDg03A QqL7nzZIg4hAkMTcjxvAmpkFfCQenZnOBGILC0RKvFo9nxGiJkri9/fb7BC2lcSR5u2sIDaL gIrE6WtNYL28Ar4Sq9bsZYTY9ZFRYt79drBmTgFdiYVNJ5hBbEag676fWsMEsUxc4taT+UwQ VwtILNlznhnCFpV4+fgfK4StKHF1+nKo+nyJxnPnGCGWCUqcnPmEZQKj6Cwko2YhKZuFpAwi riOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYmTPTczMSS832sQIjLiDW36r7mC8c07kEKM0 B4uSOG8yV2OgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYmoZtFD9mn51l3dlw56Hl98u3N VtviGTaf/LJ1cX2QJIdtkejW2PL8e48XHA1eVeE3K7xs6bP6E0f5LvEZbOWV6sm0exnbtPBd d9OJyrr1wu/4Lnzfy8NVzNz84J7A1g/MK1V0q6+9WcuzfMObUq+srgjJ2P5FERN9Iw79/v1y cvgtwYWP32gqsRRnJBpqMRcVJwIA0x9NxYYCAAA= Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 10:12:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C36C8EBESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A few questions on the draft: Q1_CODEC/CODEC CONFIGURATION: The examples only show one PT per m- line, and the draft seem to assume tha= t all PTs (ie codecs and/or codec configurations) apply to all SSRCs within= an m- line. I think that is very important to point out, because at least = in my opinion it is an important factor that we need to discuss. Example: I think Cullen often talks about using a camera with built in code= c X. But, Plan B does not allow to (or, at least does not describe how to) = explicitly offer codec X for the track/ssrc associated with the camera. Cod= ec X is offered for ALL tracks/ssrcs associated with the m- line. Q2_1_LEGACY: The text says that things must work with legacy devices, and that an endpoi= nt can choose a single source when communicating with a legacy device. But,= there is really no text about how the legacy device will know which source= to use, etc. Q2_2_LEGACY: The example in section 5.2 (and sub sections) confuses me a little. You ind= icate that the m- line itself represents "main", while ssrc attributes are = used to describe the left/center/right mic sources. Why is there no ssrc at= tribute for the main flow? Q3_NUMBER_OF_M_LINES: The draft does not explicitly forbid the usage of multiple m- lines for a g= iven media type (e.g. audio). It would probably be good to point that out a= lso. Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 6. toukokuuta 2013 17:20 To: Justin Uberti Cc: rtcweb@ietf.org; mmusic@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb= -plan-00.txt Note - I regard the Plan A / Plan B conflict as the "long end of the pole" = with regards to resolving issues regarding SDP signalling in RTCWEB - and a= s such, I regard it as very important to get it resolved. The silence on this issue is disquieting. Harald On 05/03/2013 08:08 AM, Justin Uberti wrote: Scribbled down the basic concepts of what I have been referring to as "Plan= B" - a way to signal multiple MediaStreamTracks in SDP without needing a s= eparate m=3D line for each. Hopefully this will make discussion of this topic easier. ---------- Forwarded message ---------- From: > Date: Thu, May 2, 2013 at 10:46 PM Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: Justin Uberti > A new version of I-D, draft-uberti-rtcweb-plan-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-rtcweb-plan Revision: 00 Title: Plan B: a proposal for signaling multiple media sources in= WebRTC. Creation date: 2013-05-03 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-pl= an-00.txt Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 Abstract: This document explains how multiple media sources can be signaled in WebRTC using SDP, in a fashion that avoids many common problems and provides a simple control surface to the receiver. The IETF Secretariat _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C36C8EBESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

A few questions on the dr= aft:

 <= /p>

Q1_CODEC/CODEC CONFIGURAT= ION:

 <= /p>

The examples only show on= e PT per m- line, and the draft seem to assume that all PTs (ie codecs and/= or codec configurations) apply to all SSRCs within an m- line. I think that is very important to point out, because at least in my = opinion it is an important factor that we need to discuss.

 <= /p>

Example: I think Cullen o= ften talks about using a camera with built in codec X. But, Plan B does not= allow to (or, at least does not describe how to) explicitly offer codec X for the track/ssrc associated with the camera. Codec X is of= fered for ALL tracks/ssrcs associated with the m- line.

 <= /p>

 <= /p>

Q2_1_LEGACY:

 <= /p>

The text says that things= must work with legacy devices, and that an endpoint can choose a single so= urce when communicating with a legacy device. But, there is really no text about how the legacy device will know which source to us= e, etc.

 <= /p>

 <= /p>

Q2_2_LEGACY:

 <= /p>

The example in section 5.= 2 (and sub sections) confuses me a little. You indicate that the m- line it= self represents “main”, while ssrc attributes are used to describe the left/center/right mic sources. Why is there no ssrc attribute= for the main flow?

 <= /p>

 <= /p>

Q3_NUMBER_OF_M_LINES:

 <= /p>

The draft does not explic= itly forbid the usage of multiple m- lines for a given media type (e.g. aud= io). It would probably be good to point that out also.

 <= /p>

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 <= /p>

 <= /p>

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 6. toukokuuta 2013 17:20
To: Justin Uberti
Cc: rtcweb@ietf.org; mmusic@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti= -rtcweb-plan-00.txt

 

Note - I regard the Plan A / Plan B conflict as the = "long end of the pole" with regards to resolving issues regarding= SDP signalling in RTCWEB - and as such, I regard it as very important to g= et it resolved.

The silence on this issue is disquieting.

           Harald


On 05/03/2013 08:08 AM, Justin Uberti wrote:

Scribbled down the basic concepts of what I have bee= n referring to as "Plan B" - a way to signal multiple MediaStream= Tracks in SDP without needing a separate m=3D line for each.

 

Hopefully this will make discussion of this topic ea= sier.

 

---------- Forwarded = message ----------
From: <int= ernet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling = multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ie= tf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/d= raft-uberti-rtcweb-plan-00


Abstract:
   This document explains how multiple media sources can be signa= led in
   WebRTC using SDP, in a fashion that avoids many common problem= s and
   provides a simple control surface to the receiver.




The IETF Secretariat

 

 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb

 

--_000_7594FB04B1934943A5C02806D1A2204B1C36C8EBESESSMB209erics_-- From harald@alvestrand.no Tue May 7 03:39:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E844B21F8EF2; Tue, 7 May 2013 03:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42bFgfqMjuKO; Tue, 7 May 2013 03:39:07 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2C21F8ED8; Tue, 7 May 2013 03:39:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D705F39E170; Tue, 7 May 2013 12:39:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR1gO-IvPOU8; Tue, 7 May 2013 12:39:02 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6969139E0D7; Tue, 7 May 2013 12:39:02 +0200 (CEST) Message-ID: <5188D9C5.3010209@alvestrand.no> Date: Tue, 07 May 2013 12:39:01 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------010502000906090604020403" Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 10:39:12 -0000 This is a multi-part message in MIME format. --------------010502000906090604020403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/07/2013 12:11 PM, Christer Holmberg wrote: > > Hi, > > A few questions on the draft: > > Q1_CODEC/CODEC CONFIGURATION: > > The examples only show one PT per m- line, and the draft seem to > assume that all PTs (ie codecs and/or codec configurations) apply to > all SSRCs within an m- line. I think that is very important to point > out, because at least in my opinion it is an important factor that we > need to discuss. > > Example: I think Cullen often talks about using a camera with built in > codec X. But, Plan B does not allow to (or, at least does not describe > how to) explicitly offer codec X for the track/ssrc associated with > the camera. Codec X is offered for ALL tracks/ssrcs associated with > the m- line. > My read: This is a very special use case. The sender always chooses the codec from the available codecs that the recipient can understand - and it's then free to choose the built in codec X if supported by the recipient. If, for some reason, the application is dependent on segregating the codecs, it can use the "a=content" mechanism to segregate the streams onto different M-lines. > Q2_1_LEGACY: > > The text says that things must work with legacy devices, and that an > endpoint can choose a single source when communicating with a legacy > device. But, there is really no text about how the legacy device will > know which source to use, etc. > The application that drives the API will have to decide that it can send only one source. The browser cannot (in my opinion) sensibly make that choice on behalf of the application. > Q2_2_LEGACY: > > The example in section 5.2 (and sub sections) confuses me a little. > You indicate that the m- line itself represents "main", while ssrc > attributes are used to describe the left/center/right mic sources. Why > is there no ssrc attribute for the main flow? > The MSID identifier is, by definition, meaningless. The association between the MSID and the function of the stream is not carried in the MSID attribute. The example is a bit unfortunate in that it uses MSIDs that look as if they're human-readable strings that carry semantics. > Q3_NUMBER_OF_M_LINES: > > The draft does not explicitly forbid the usage of multiple m- lines > for a given media type (e.g. audio). It would probably be good to > point that out also. > In fact the a=content mechanism (see section 3.1) depends on the ability to use multiple m- lines for a given media type, so it would be really hard to interpret the draft as forbidding this. There's an issue with representing the semantics of an incoming call that uses multiple m- lines for a given media type and doesn't give differing a=content attributes for those media types. I don't know if such a scenario ever occurs in practice. > > Regards, > > Christer > > *From:*rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Harald Alvestrand > *Sent:* 6. toukokuuta 2013 17:20 > *To:* Justin Uberti > *Cc:* rtcweb@ietf.org ; mmusic@ietf.org > > *Subject:* Re: [rtcweb] Fwd: New Version Notification for > draft-uberti-rtcweb-plan-00.txt > > Note - I regard the Plan A / Plan B conflict as the "long end of the > pole" with regards to resolving issues regarding SDP signalling in > RTCWEB - and as such, I regard it as very important to get it resolved. > > The silence on this issue is disquieting. > > Harald > > > On 05/03/2013 08:08 AM, Justin Uberti wrote: > > Scribbled down the basic concepts of what I have been referring to > as "Plan B" - a way to signal multiple MediaStreamTracks in SDP > without needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: > > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media > sources in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be > signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > --------------010502000906090604020403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/07/2013 12:11 PM, Christer Holmberg wrote:

Hi,

 

A few questions on the draft:

 

Q1_CODEC/CODEC CONFIGURATION:

 

The examples only show one PT per m- line, and the draft seem to assume that all PTs (ie codecs and/or codec configurations) apply to all SSRCs within an m- line. I think that is very important to point out, because at least in my opinion it is an important factor that we need to discuss.

 

Example: I think Cullen often talks about using a camera with built in codec X. But, Plan B does not allow to (or, at least does not describe how to) explicitly offer codec X for the track/ssrc associated with the camera. Codec X is offered for ALL tracks/ssrcs associated with the m- line.


My read: This is a very special use case. The sender always chooses the codec from the available codecs that the recipient can understand - and it's then free to choose the built in codec X if supported by the recipient.

If, for some reason, the application is dependent on segregating the codecs, it can use the "a=content" mechanism to segregate the streams onto different M-lines.

 

 

Q2_1_LEGACY:

 

The text says that things must work with legacy devices, and that an endpoint can choose a single source when communicating with a legacy device. But, there is really no text about how the legacy device will know which source to use, etc.


The application that drives the API will have to decide that it can send only one source. The browser cannot (in my opinion) sensibly make that choice on behalf of the application.

 

 

Q2_2_LEGACY:

 

The example in section 5.2 (and sub sections) confuses me a little. You indicate that the m- line itself represents “main”, while ssrc attributes are used to describe the left/center/right mic sources. Why is there no ssrc attribute for the main flow?


The MSID identifier is, by definition, meaningless. The association between the MSID and the function of the stream is not carried in the MSID attribute. The example is a bit unfortunate in that it uses MSIDs that look as if they're human-readable strings that carry semantics.

 

 

Q3_NUMBER_OF_M_LINES:

 

The draft does not explicitly forbid the usage of multiple m- lines for a given media type (e.g. audio). It would probably be good to point that out also.


In fact the a=content mechanism (see section 3.1) depends on the ability to use multiple m- lines for a given media type, so it would be really hard to interpret the draft as forbidding this.

There's an issue with representing the semantics of an incoming call that uses multiple m- lines for a given media type and doesn't give differing a=content attributes for those media types.
I don't know if such a scenario ever occurs in practice.

 

 

Regards,

 

Christer

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 6. toukokuuta 2013 17:20
To: Justin Uberti
Cc: rtcweb@ietf.org; mmusic@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

 

Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved.

The silence on this issue is disquieting.

           Harald


On 05/03/2013 08:08 AM, Justin Uberti wrote:

Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each.

 

Hopefully this will make discussion of this topic easier.

 

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00


Abstract:
   This document explains how multiple media sources can be signaled in
   WebRTC using SDP, in a fashion that avoids many common problems and
   provides a simple control surface to the receiver.




The IETF Secretariat

 

 




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

 


--------------010502000906090604020403-- From stefan.lk.hakansson@ericsson.com Tue May 7 03:45:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE77721F8519; Tue, 7 May 2013 03:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO4LvaH-aY2F; Tue, 7 May 2013 03:45:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1C91521F84F9; Tue, 7 May 2013 03:45:24 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-ea-5188db43254f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 00.84.32006.34BD8815; Tue, 7 May 2013 12:45:24 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 7 May 2013 12:45:23 +0200 Message-ID: <5188DB43.60406@ericsson.com> Date: Tue, 7 May 2013 12:45:23 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org, mmusic@ietf.org References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> In-Reply-To: <5187BC04.1030200@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+Jvra7L7Y5Ag0cfmS2mLn/MYrH2Xzu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgytq5dy15wQbiic8VS9gbGh/xdjJwcEgImEu0/57FC 2GISF+6tZ+ti5OIQEjjFKNHZt4gJwlnDKHGuZxoLSBWvgKbE5Slt7CA2i4CKxIItH8C62QQC Ja7//8UEYosKREn8e7ubEaJeUOLkzCdgvSJA9bPvnwCLCwuES8y6NJsRYsFrRok3n7rABnEK 6EosbDrBDGIzC9hKXJhznQXClpfY/nYOWFwIqObd63usExgFZiHZMQtJyywkLQsYmVcxsucm ZuaklxttYgQG3cEtv1V3MN45J3KIUZqDRUmcN5mrMVBIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY3JPUE9GuXHr1adfuc9fXD19kgDX4dszZWUnPH5/6GOS09rn0z/mRZkILPqtYPEhI1JE Y+mXj/+PxvcXL9S59OVsQvSZj7q3F7/JkBF77e8fdmKKBINJjODmMz8C6hKeHjIN+iy17KIX 20Hl2CWf0lV4hR53bxDeFntblVE058Hl5aLJ100/2yqxFGckGmoxFxUnAgAhLIvnCAIAAA== Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 10:45:31 -0000 On 2013-05-06 16:19, Harald Alvestrand wrote: > Note - I regard the Plan A / Plan B conflict as the "long end of the > pole" with regards to resolving issues regarding SDP signalling in > RTCWEB - and as such, I regard it as very important to get it resolved. > > The silence on this issue is disquieting. I agree. Thinking out loud: could a meeting (joint mmusic and rtcweb I guess), that has as objective to discuss and decided which Plan to move forward with, be set up? Then there would be concrete deadlines, and most likely things would not stay as quiet. I guess it is a question for the chairs of those groups. > > Harald > > > On 05/03/2013 08:08 AM, Justin Uberti wrote: >> Scribbled down the basic concepts of what I have been referring to as >> "Plan B" - a way to signal multiple MediaStreamTracks in SDP without >> needing a separate m= line for each. >> >> Hopefully this will make discussion of this topic easier. >> >> ---------- Forwarded message ---------- >> From: > >> Date: Thu, May 2, 2013 at 10:46 PM >> Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt >> To: Justin Uberti > >> >> >> >> A new version of I-D, draft-uberti-rtcweb-plan-00.txt >> has been successfully submitted by Justin Uberti and posted to the >> IETF repository. >> >> Filename: draft-uberti-rtcweb-plan >> Revision: 00 >> Title: Plan B: a proposal for signaling multiple media >> sources in WebRTC. >> Creation date: 2013-05-03 >> Group: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >> Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan >> Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 >> >> >> Abstract: >> This document explains how multiple media sources can be signaled in >> WebRTC using SDP, in a fashion that avoids many common problems and >> provides a simple control surface to the receiver. >> >> >> >> >> The IETF Secretariat >> >> >> >> >> >> _______________________________________________ >> 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 > From christer.holmberg@ericsson.com Tue May 7 05:08:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF3721F8EFC; Tue, 7 May 2013 05:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6kQj6wDNPVb; Tue, 7 May 2013 05:08:22 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D1B6821F8F3C; Tue, 7 May 2013 05:08:21 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-16-5188eeb4bdb8 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C5.D1.32006.4BEE8815; Tue, 7 May 2013 14:08:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Tue, 7 May 2013 14:08:20 +0200 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOSw8clsjra9RECEqdCjXAKrt6wpj5iT9g Date: Tue, 7 May 2013 12:08:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36C9F9@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> <5188D9C5.3010209@alvestrand.no> In-Reply-To: <5188D9C5.3010209@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre7Wdx2BBn+WMVkc6+tis9g6Vchi 6vLHLBZr/7WzO7B4XJlwhdVjwaZSjyVLfjIFMEdx2aSk5mSWpRbp2yVwZSy5+JSl4KZ+xeNP H1gbGJeodTFyckgImEi8+7CcFcIWk7hwbz1bFyMXh5DAYUaJG2f+sEI4ixklfsz4xtTFyMHB JmAh0f1PG6RBREBH4uH+BiYQm1mgSOL82weMILawQKTE1GtfGSFqoiQuHT3HBGEbSTzc+JER ZAyLgIrEjjX6ICavgK/E5uuOIBVCAjeYJL4f0gKxOQV0JRa+3Q7WyQh02vdTa6A2iUvcejKf CeJkAYkle84zQ9iiEi8f/4N6RVHi6vTlUPV6EjemTmGDsLUlli18DVbPKyAocXLmE5YJjGKz kIydhaRlFpKWWUhaFjCyrGJkz03MzEkvN9rECIycg1t+q+5gvHNO5BCjNAeLkjhvMldjoJBA emJJanZqakFqUXxRaU5q8SFGJg5OqQbGWR/nTnP/U2t3wnDDKS7vAjH2hQfOXHy6z+sB96T2 lrVO3UZxXPu2XNq1/oZZoqfDHgNV1zdy9+3cTbJVGsRt46KWC7P43s474CyXxaom6j+tx+Lc niXzF10O+FhfYb/fyshhy7SUWKuqqc+aw+MdVYPeBx+oZGS9L/1DRbI5fY0lL3ex+iYlluKM REMt5qLiRABxn+cZagIAAA== Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 12:08:27 -0000 Hi, =A0 >> A few questions on the draft: >> >> Q1_CODEC/CODEC CONFIGURATION: >>=A0 >> The examples only show one PT per m- line, and the draft seem to assume = that all PTs (ie codecs and/or codec configurations) apply to all SSRCs=20 >> within an m- line. I think that is very important to point out, because = at least in my opinion it is an important factor that we need to discuss. >> > Example: I think Cullen often talks about using a camera with built in co= dec X. But, Plan B does not allow to (or, at least does not describe how to= )=20 > explicitly offer codec X for the track/ssrc associated with the camera. C= odec X is offered for ALL tracks/ssrcs associated with the m- line. > > My read: This is a very special use case. The sender always chooses the c= odec from the available codecs that the recipient can understand - and it's= then free to choose the built in codec X if supported by the recipient. > > If, for some reason, the application is dependent on segregating the code= cs, it can use the "a=3Dcontent" mechanism to segregate the streams onto di= fferent M-lines. - Assume I have two cameras, one which can handle codec X, and one which ca= n handle codec Y.=20 - I send you an offer with a video m- line, offering X, Y and a ssrc for ea= ch camera - You only want one of my camera streams, AND you only support codec X. Now= , how do you know which ssrc to choose? You don't know which uses codec X. Now, maybe this is a theoretical problem, but I think the draft needs to de= scribe that codecs, and codec configurations, apply to all ssrcs associated= with an m- line. And, IF there is a need to apply codecs to a specific ssrc only, you need t= o use a separate m- line for that ssrc. >> Q2_1_LEGACY: >>=A0 >> The text says that things must work with legacy devices, and that an end= point can choose a single source when communicating with a=20 >> legacy device. But, there is really no text about how the legacy device = will know which source to use, etc. > > The application that drives the API will have to decide that it can send = only one source. The browser cannot (in my opinion) sensibly make that choi= ce on behalf of the application. Fair enough, but that needs to be clearly described. >> Q2_2_LEGACY: >>=A0 >> The example in section 5.2 (and sub sections) confuses me a little. You = indicate that the m- line itself represents "main", while ssrc=20 >> attributes are used to describe the left/center/right mic sources. Why i= s there no ssrc attribute for the main flow? > > The MSID identifier is, by definition, meaningless. The association betwe= en the MSID and the function of the stream is not carried in=20 > the MSID attribute. The example is a bit unfortunate in that it uses MSID= s that look as if they're human-readable strings that carry semantics. I wasn't referring to the MSID identifier, but more to the fact that you do= n't indicate the ssrc value for the "main" flow. I thought we were going to= mandate the indication of the ssrc value for each flow, but maybe I rememb= er wrong. >> Q3_NUMBER_OF_M_LINES: >> >> The draft does not explicitly forbid the usage of multiple m- lines for = a given media type (e.g. audio). It would probably be good to point that ou= t also. >> > In fact the a=3Dcontent mechanism (see section 3.1) depends on the abilit= y to use multiple m- lines for a given media type, so it would be really ha= rd to interpret the draft as forbidding this. Fair enough. My mistake. Regards, Christer There's an issue with representing the semantics of an incoming call that u= ses multiple m- lines for a given media type and doesn't give differing a= =3Dcontent attributes for those media types. I don't know if such a scenario ever occurs in practice. =A0 =A0 =A0 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 6. toukokuuta 2013 17:20 To: Justin Uberti Cc: rtcweb@ietf.org; mmusic@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb= -plan-00.txt =A0 Note - I regard the Plan A / Plan B conflict as the "long end of the pole" = with regards to resolving issues regarding SDP signalling in RTCWEB - and a= s such, I regard it as very important to get it resolved. The silence on this issue is disquieting. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald On 05/03/2013 08:08 AM, Justin Uberti wrote: Scribbled down the basic concepts of what I have been referring to as "Plan= B" - a way to signal multiple MediaStreamTracks in SDP without needing a s= eparate m=3D line for each.=20 =A0 Hopefully this will make discussion of this topic easier. =A0 ---------- Forwarded message ---------- From: Date: Thu, May 2, 2013 at 10:46 PM Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: Justin Uberti A new version of I-D, draft-uberti-rtcweb-plan-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-uberti-rtcweb-plan Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 Plan B: a proposal for signaling multiple media = sources in WebRTC. Creation date: =A0 2013-05-03 Group: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 15 URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-uber= ti-rtcweb-plan-00.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-uberti-rtc= web-plan Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-uberti-rtcweb-pla= n-00 Abstract: =A0 =A0This document explains how multiple media sources can be signaled in =A0 =A0WebRTC using SDP, in a fashion that avoids many common problems and =A0 =A0provides a simple control surface to the receiver. The IETF Secretariat =A0 =A0 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =A0 From ron.even.tlv@gmail.com Tue May 7 05:52:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8ABA21F8FEB; Tue, 7 May 2013 05:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCcCF7CwMapr; Tue, 7 May 2013 05:52:44 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5252921F86CB; Tue, 7 May 2013 05:52:32 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id z12so546555wgg.23 for ; Tue, 07 May 2013 05:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=2RWu8vEvaNNxgdOEgSPUq0KFcKvUdFCXvtl2aqaWnIY=; b=Zj1IE1eHWA7ZQMRF7jD/qyb8LwoyxQMxNoOIiwn4qxh3/Vqw0JQeEB/Txc71N/Fwxn zAjiQUHWJQ+RDHbOGRBw07mrceD4AK0E2s+gqdT0lsiaaTUyFuRp55sAlP+EY8GbaEuV qU29U8red0FprDT1EOEl2EQbUndBenOCaQ2xNjPF1fbK3uQPR4GV/Qn7U9OiOHac5QQF 6XJo90V9LO8z1dPdiuROEBLfjFqQ70S6ToXbz9F+26p5+cyfEZO+3Sup0k5ALKX0fZ0S AMMCS8NR7bAT3JdaqFVNIeygapOAG9HgPNJW/+IrcwOPATjSCvMxhLOQaF6xZFg2B0rk 9ErQ== X-Received: by 10.180.212.3 with SMTP id ng3mr3138032wic.22.1367931150438; Tue, 07 May 2013 05:52:30 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id q18sm2618430wiw.8.2013.05.07.05.52.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 05:52:29 -0700 (PDT) From: "Roni Even" To: "'Justin Uberti'" , , References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 7 May 2013 15:51:40 +0300 Message-ID: <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01CE4B3A.C5E88760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfv5wx4y9wP/O/FJv66Nx2OU8XsQM3rT1TAYHWzfiYMNuJkA== Content-Language: en-us Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 12:52:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0088_01CE4B3A.C5E88760 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I think that plan B is the right direction. I am wondering if this = should be discussed in RTCWEB or MMUSIC =20 I like the proposed solution for multicast support but there is also an = individual draft in MMUSIC see = http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02 . I = think that it will be good to have a separate document on simulcast = support =20 Some comments =20 1. In section 3.1 when talking about using more than one m-line = for a media type I think that there are other cases when this may be = required . for example, if an attribute is not specified at SSRC level = or if the SDP will be simpler when using multiple m-line )describing = different codec combinations 2. In section 3.2 the document says that collision will not happen = if the answerer sees the SDP from the Offer. I am not sure it will work = when joining a multipoint conference since the offer is joining an = existing session and do not know what SSRC have been used. I think that = the issue is handled in RFC5576 so you can point at it. 3. The draft, as far as I can tell, is discussing point to point = calls and full meshed conferences. I think we need to look at other = topologies including a centralized MCU doing video switch, for example. 4. In section 4.1 you suggest using the MSID as an indication for = supporting plan B. I think that this may be RTCWEB specific and other = usages like CLUE may use a different way to associate an SSRC to a Media = Capture. My proposal is to use maxssrc. I think that it will be needed = since an offer may include more options than can be really sent by the = offerer and the maxssrc can tell the answerer how many it can select. It = can also tell the answerer how many simultaneous RTP streams the offerer = can receive. Otherwise it may be better to have a specific identifier = that will tell that multiple RTP streams in an m-line are supported. 5. I have a question about the last paragraph of section 4.2. = Currently the answerer can start sending media immediately when getting = the offer in parallel to sending the SDP answer since the offer includes = receive capabilities and receive transport address. Are you suggesting = that media will flow only after the 3 way handshake? 6. Small nit on section 5.1.4, according to section 8 of the = Lennox source selection draft, the third offer must have sending:on for = the streams that are being sent so probably need a=3Dssrc:1 = msid:left-mic sending:on =20 =20 Roni Even =20 =20 =20 =20 =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Justin Uberti Sent: 03 May, 2013 9:09 AM To: rtcweb@ietf.org; mmusic@ietf.org Subject: [rtcweb] Fwd: New Version Notification for = draft-uberti-rtcweb-plan-00.txt =20 Scribbled down the basic concepts of what I have been referring to as = "Plan B" - a way to signal multiple MediaStreamTracks in SDP without = needing a separate m=3D line for each. =20 Hopefully this will make discussion of this topic easier. =20 ---------- Forwarded message ---------- From: Date: Thu, May 2, 2013 at 10:46 PM Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: Justin Uberti A new version of I-D, draft-uberti-rtcweb-plan-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-rtcweb-plan Revision: 00 Title: Plan B: a proposal for signaling multiple media sources = in WebRTC. Creation date: 2013-05-03 Group: Individual Submission Number of pages: 15 URL: = http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt Status: = http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 Abstract: This document explains how multiple media sources can be signaled in WebRTC using SDP, in a fashion that avoids many common problems and provides a simple control surface to the receiver. The IETF Secretariat =20 =20 _____ =20 ------=_NextPart_000_0088_01CE4B3A.C5E88760 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

I think that plan B is the right direction. I am wondering if this = should be discussed in RTCWEB or MMUSIC

 

I like the proposed solution for multicast support but there is also = an individual draft in MMUSIC see http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02= . I think that it will be good to have a separate document on = simulcast support

 

Some comments

 

1.       = In section 3.1 when talking about using more than one m-line for a = media type I think that there are other cases when this may be required = . for example, if an attribute is not specified at SSRC level or if the = SDP will be simpler when using multiple m-line =C2=A0)describing = different codec combinations

2.       = In section 3.2 the document says that collision will not happen if = the answerer sees the SDP from the Offer. I am not sure it will work = when joining a multipoint conference since the offer is joining an = existing session and do not know what SSRC have been used. I think that = the issue is handled in RFC5576 so you can point at = it.

3.       = The draft, as far as I can tell, is discussing point to point calls = and full meshed conferences. I think we need to look at other topologies = including a centralized MCU doing video switch, for = example.

4.       = In section 4.1 you suggest using the MSID as an indication for = supporting plan B. I think that this may be RTCWEB specific and other = usages like CLUE may use a different way to associate an SSRC to a Media = Capture. My proposal is to use maxssrc. I think that it will be needed = since an offer may include more options than can be really sent by the = offerer and the maxssrc can tell the answerer how many it can select. It = can also tell the answerer how many simultaneous RTP streams the offerer = can receive. Otherwise it may be better to have a specific identifier = that will tell that multiple RTP streams in an m-line are = supported.

5.       = I have a question about the last paragraph of section 4.2. Currently = the answerer can start sending media immediately when getting the offer = in parallel to sending the SDP answer since the offer includes receive = capabilities and receive transport address. Are you suggesting that = media will flow only after the 3 way handshake?

6.       = Small nit on section 5.1.4, according to section 8 of the Lennox = source selection draft, the third offer must have sending:on for the = streams that are being sent so probably need a=3Dssrc:1 msid:left-mic = sending:on

 

 

Roni Even

 

 

 

 

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Justin Uberti
Sent: 03 May, 2013 9:09 AM
To: = rtcweb@ietf.org; mmusic@ietf.org
Subject: [rtcweb] Fwd: New = Version Notification for = draft-uberti-rtcweb-plan-00.txt

 

Scribbled down the basic concepts of what I have been = referring to as "Plan B" - a way to signal multiple = MediaStreamTracks in SDP without needing a separate m=3D line for = each.

 

Hopefully this will make discussion of this topic = easier.

 

---------- Forwarded = message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, = 2013 at 10:46 PM
Subject: New Version Notification for = draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new = version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully = submitted by Justin Uberti and posted to the
IETF = repository.

Filename:       =  draft-uberti-rtcweb-plan
Revision:       =  00
Title:           Plan B: a proposal = for signaling multiple media sources in WebRTC.
Creation date:   = 2013-05-03
Group:           Individual = Submission
Number of pages: 15
URL:         =     http://www.ietf.org/internet-drafts/draft-uberti-rtcweb= -plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-pla= n
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00<= /a>


Abstract:
   This document explains how = multiple media sources can be signaled in
   WebRTC using = SDP, in a fashion that avoids many common problems and
  =  provides a simple control surface to the = receiver.




The IETF Secretariat

 

 

------=_NextPart_000_0088_01CE4B3A.C5E88760-- From harald@alvestrand.no Tue May 7 06:08:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7143F21F8BBC; Tue, 7 May 2013 06:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.699 X-Spam-Level: X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-XizyqwCGDf; Tue, 7 May 2013 06:08:41 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EE2A421F8A6B; Tue, 7 May 2013 06:08:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6515A39E1C4; Tue, 7 May 2013 15:08:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VOFtKWAT2pG; Tue, 7 May 2013 15:08:36 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7EF4339E0D7; Tue, 7 May 2013 15:08:36 +0200 (CEST) Message-ID: <5188FCD3.9050306@alvestrand.no> Date: Tue, 07 May 2013 15:08:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> <5188D9C5.3010209@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C9F9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36C9F9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 13:08:45 -0000 On 05/07/2013 02:08 PM, Christer Holmberg wrote: > Hi, > >>> A few questions on the draft: >>> >>> Q1_CODEC/CODEC CONFIGURATION: >>> >>> The examples only show one PT per m- line, and the draft seem to assume that all PTs (ie codecs and/or codec configurations) apply to all SSRCs >>> within an m- line. I think that is very important to point out, because at least in my opinion it is an important factor that we need to discuss. >>> >> Example: I think Cullen often talks about using a camera with built in codec X. But, Plan B does not allow to (or, at least does not describe how to) >> explicitly offer codec X for the track/ssrc associated with the camera. Codec X is offered for ALL tracks/ssrcs associated with the m- line. >> >> My read: This is a very special use case. The sender always chooses the codec from the available codecs that the recipient can understand - and it's then free to choose the built in codec X if supported by the recipient. >> >> If, for some reason, the application is dependent on segregating the codecs, it can use the "a=content" mechanism to segregate the streams onto different M-lines. > - Assume I have two cameras, one which can handle codec X, and one which can handle codec Y. > > - I send you an offer with a video m- line, offering X, Y and a ssrc for each camera > > - You only want one of my camera streams, AND you only support codec X. Now, how do you know which ssrc to choose? You don't know which uses codec X. Right. That's the part that goes all artificial on me. Two cameras, and I'm going to choose blindly between them if I support both codecs, but I can't accept both and let you deal with sending me only the one I can handle? You can, if you want to, send me two M-lines: "a=content:codec-x" and "a=content:codec-y". This is an example of "the application is dependent on segregating the codecs". > > Now, maybe this is a theoretical problem, but I think the draft needs to describe that codecs, and codec configurations, apply to all ssrcs associated with an m- line. > > And, IF there is a need to apply codecs to a specific ssrc only, you need to use a separate m- line for that ssrc. Agreed. > >>> Q2_1_LEGACY: >>> >>> The text says that things must work with legacy devices, and that an endpoint can choose a single source when communicating with a >>> legacy device. But, there is really no text about how the legacy device will know which source to use, etc. >> The application that drives the API will have to decide that it can send only one source. The browser cannot (in my opinion) sensibly make that choice on behalf of the application. > Fair enough, but that needs to be clearly described. > > >>> Q2_2_LEGACY: >>> >>> The example in section 5.2 (and sub sections) confuses me a little. You indicate that the m- line itself represents "main", while ssrc >>> attributes are used to describe the left/center/right mic sources. Why is there no ssrc attribute for the main flow? >> The MSID identifier is, by definition, meaningless. The association between the MSID and the function of the stream is not carried in >> the MSID attribute. The example is a bit unfortunate in that it uses MSIDs that look as if they're human-readable strings that carry semantics. > I wasn't referring to the MSID identifier, but more to the fact that you don't indicate the ssrc value for the "main" flow. I thought we were going to mandate the indication of the ssrc value for each flow, but maybe I remember wrong. I was trying to locate the flows in the example in section 5.2, and I couldn't find them anywhere but in the MSID attribute. So I couldn't parse your comment. The way I read the document, the first m=audio line is the main audio; it has 3 audio flows. The first m=video line is the main video; it has 3 video flows. The third m=video line is the slides video; it has 2 SSRCs, one for the main flow and one for the repair flow. So - the issue seems to be that the word "main" as in "main audio" is easy to mistake for "a single main flow". It isn't intended to be that way. I guess the text could be clearer. > > >>> Q3_NUMBER_OF_M_LINES: >>> >>> The draft does not explicitly forbid the usage of multiple m- lines for a given media type (e.g. audio). It would probably be good to point that out also. >>> >> In fact the a=content mechanism (see section 3.1) depends on the ability to use multiple m- lines for a given media type, so it would be really hard to interpret the draft as forbidding this. > Fair enough. My mistake. > > Regards, > > Christer > > There's an issue with representing the semantics of an incoming call that uses multiple m- lines for a given media type and doesn't give differing a=content attributes for those media types. > I don't know if such a scenario ever occurs in practice. > > > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: 6. toukokuuta 2013 17:20 > To: Justin Uberti > Cc: rtcweb@ietf.org; mmusic@ietf.org > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt > > Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved. > > The silence on this issue is disquieting. > > Harald > > > On 05/03/2013 08:08 AM, Justin Uberti wrote: > Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media sources in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From harald@alvestrand.no Tue May 7 06:25:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9AB21F85BF; Tue, 7 May 2013 06:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.848 X-Spam-Level: X-Spam-Status: No, score=-109.848 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFIm19FNwyFh; Tue, 7 May 2013 06:25:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF1A21F8528; Tue, 7 May 2013 06:25:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C18939E1C4; Tue, 7 May 2013 15:25:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fOxclB7mdGC; Tue, 7 May 2013 15:25:37 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9DAA439E170; Tue, 7 May 2013 15:25:36 +0200 (CEST) Message-ID: <518900CF.6050403@alvestrand.no> Date: Tue, 07 May 2013 15:25:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Roni Even References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> In-Reply-To: <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> Content-Type: multipart/alternative; boundary="------------050909030601020704020703" Cc: rtcweb@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 13:25:47 -0000 This is a multi-part message in MIME format. --------------050909030601020704020703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/07/2013 02:51 PM, Roni Even wrote: > > Hi, > > I think that plan B is the right direction. I am wondering if this > should be discussed in RTCWEB or MMUSIC > Good question. > I like the proposed solution for multicast support but there is also > an individual draft in MMUSIC see > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02 . > I think that it will be good to have a separate document on simulcast > support > > Some comments > > 1.In section 3.1 when talking about using more than one m-line for a > media type I think that there are other cases when this may be > required . for example, if an attribute is not specified at SSRC level > or if the SDP will be simpler when using multiple m-line )describing > different codec combinations > > 2.In section 3.2 the document says that collision will not happen if > the answerer sees the SDP from the Offer. I am not sure it will work > when joining a multipoint conference since the offer is joining an > existing session and do not know what SSRC have been used. I think > that the issue is handled in RFC5576 so you can point at it. > > 3.The draft, as far as I can tell, is discussing point to point calls > and full meshed conferences. I think we need to look at other > topologies including a centralized MCU doing video switch, for example. > I'm not sure the multipoint conference scenario (using a mixer, transport relay or multicast) is in scope here. Those scenarios can't be done with offer/answer anyway. With scenarios that do centralized call termination (and not using CSRC), doing per-leg SSRC allocation is reasonable. > 4.In section 4.1 you suggest using the MSID as an indication for > supporting plan B. I think that this may be RTCWEB specific and other > usages like CLUE may use a different way to associate an SSRC to a > Media Capture. My proposal is to use maxssrc. I think that it will be > needed since an offer may include more options than can be really sent > by the offerer and the maxssrc can tell the answerer how many it can > select. It can also tell the answerer how many simultaneous RTP > streams the offerer can receive. Otherwise it may be better to have a > specific identifier that will tell that multiple RTP streams in an > m-line are supported. > > 5.I have a question about the last paragraph of section 4.2. Currently > the answerer can start sending media immediately when getting the > offer in parallel to sending the SDP answer since the offer includes > receive capabilities and receive transport address. Are you suggesting > that media will flow only after the 3 way handshake? > > 6.Small nit on section 5.1.4, according to section 8 of the Lennox > source selection draft, the third offer must have sending:on for the > streams that are being sent so probably need a=ssrc:1 msid:left-mic > sending:on > > Roni Even > > *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* 03 May, 2013 9:09 AM > *To:* rtcweb@ietf.org; mmusic@ietf.org > *Subject:* [rtcweb] Fwd: New Version Notification for > draft-uberti-rtcweb-plan-00.txt > > Scribbled down the basic concepts of what I have been referring to as > "Plan B" - a way to signal multiple MediaStreamTracks in SDP without > needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: > > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media > sources in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > ------------------------------------------------------------------------ > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------050909030601020704020703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/07/2013 02:51 PM, Roni Even wrote:

Hi,

I think that plan B is the right direction. I am wondering if this should be discussed in RTCWEB or MMUSIC


Good question.

 

I like the proposed solution for multicast support but there is also an individual draft in MMUSIC see http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02 . I think that it will be good to have a separate document on simulcast support

 

Some comments

 

1.       In section 3.1 when talking about using more than one m-line for a media type I think that there are other cases when this may be required . for example, if an attribute is not specified at SSRC level or if the SDP will be simpler when using multiple m-line  )describing different codec combinations

2.       In section 3.2 the document says that collision will not happen if the answerer sees the SDP from the Offer. I am not sure it will work when joining a multipoint conference since the offer is joining an existing session and do not know what SSRC have been used. I think that the issue is handled in RFC5576 so you can point at it.

3.       The draft, as far as I can tell, is discussing point to point calls and full meshed conferences. I think we need to look at other topologies including a centralized MCU doing video switch, for example.


I'm not sure the multipoint conference scenario (using a mixer, transport relay or multicast) is in scope here. Those scenarios can't be done with offer/answer anyway.

With scenarios that do centralized call termination (and not using CSRC), doing per-leg SSRC allocation is reasonable.


4.       In section 4.1 you suggest using the MSID as an indication for supporting plan B. I think that this may be RTCWEB specific and other usages like CLUE may use a different way to associate an SSRC to a Media Capture. My proposal is to use maxssrc. I think that it will be needed since an offer may include more options than can be really sent by the offerer and the maxssrc can tell the answerer how many it can select. It can also tell the answerer how many simultaneous RTP streams the offerer can receive. Otherwise it may be better to have a specific identifier that will tell that multiple RTP streams in an m-line are supported.

5.       I have a question about the last paragraph of section 4.2. Currently the answerer can start sending media immediately when getting the offer in parallel to sending the SDP answer since the offer includes receive capabilities and receive transport address. Are you suggesting that media will flow only after the 3 way handshake?

6.       Small nit on section 5.1.4, according to section 8 of the Lennox source selection draft, the third offer must have sending:on for the streams that are being sent so probably need a=ssrc:1 msid:left-mic sending:on

 

 

Roni Even

 

 

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 03 May, 2013 9:09 AM
To: rtcweb@ietf.org; mmusic@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

 

Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each.

 

Hopefully this will make discussion of this topic easier.

 

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00


Abstract:
   This document explains how multiple media sources can be signaled in
   WebRTC using SDP, in a fashion that avoids many common problems and
   provides a simple control surface to the receiver.




The IETF Secretariat

 

 



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

--------------050909030601020704020703-- From christer.holmberg@ericsson.com Tue May 7 10:03:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81B21F90A1; Tue, 7 May 2013 10:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9troQlxFrNe; Tue, 7 May 2013 10:03:25 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 59AB921F908B; Tue, 7 May 2013 10:03:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-f6-518933da845b Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5A.68.28165.BD339815; Tue, 7 May 2013 19:03:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Tue, 7 May 2013 19:03:22 +0200 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOSw8clsjra9RECEqdCjXAKrt6wpj5iT9ggAAHEoCAAGIK0A== Date: Tue, 7 May 2013 17:03:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36CBE1@ESESSMB209.ericsson.se> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <5187BC04.1030200@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C8EB@ESESSMB209.ericsson.se> <5188D9C5.3010209@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C36C9F9@ESESSMB209.ericsson.se> <5188FCD3.9050306@alvestrand.no> In-Reply-To: <5188FCD3.9050306@alvestrand.no> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvre5t485Ag0Or5S2O9XWxWWydKmQx dfljFou1/9rZHVg8rky4wuqxYFOpx5IlP5kCmKO4bFJSczLLUov07RK4Mj61f2MvaOWrWPWv hbGBsYO7i5GTQ0LAROL70l3sELaYxIV769m6GLk4hAQOM0rM/z2PFcJZzCjxcOoOli5GDg42 AQuJ7n/aIA0iAjoSD/c3MIHYzAJFEuffPmAEsYUFIiUatt9lgqiJkrh09ByU7STR170XzGYR UJG48vQEWD2vgK/ErS0fWCB27WeW2PlzPytIglNAV+LuvJMsIDYj0HXfT62BWiYu8eHgdWaI qwUkluw5D2WLSrx8/I8VwlaSaFzyhBWiXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRj ZyFpmYWkZRaSlgWMLKsY2XMTM3PSyw03MQLj5+CW37o7GE+dEznEKM3BoiTOm8TVGCgkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBUaN7R7Xfnd2nlu9myHFdb5G778/cs8Gs146nXxe9l85p J/mct/7Umz6+KbtPCD+3miYn9W/ZukgFwQz7g10BSw89Oiul+eEJ58sLbFwf0nNiVDYXcF8L rgn/XuVgJZ/7guFB8juT3Ys/zymaGHU4Ra3YIVenrzn+Sc/Vu04++XsZ73S47Fl/TomlOCPR UIu5qDgRAPubvJptAgAA Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:03:31 -0000 Hi, =20 >>>> Q2_2_LEGACY: >>>> =20 >>>> The example in section 5.2 (and sub sections) confuses me a little. Yo= u indicate that the m- line itself represents "main", while ssrc >>>> attributes are used to describe the left/center/right mic sources. Why= is there no ssrc attribute for the main flow? >>> The MSID identifier is, by definition, meaningless. The association bet= ween the MSID and the function of the stream is not carried in >>> the MSID attribute. The example is a bit unfortunate in that it uses MS= IDs that look as if they're human-readable strings that carry semantics. >> I wasn't referring to the MSID identifier, but more to the fact that you= don't indicate the ssrc value for the "main" flow. I thought we were going= to mandate the indication of the ssrc value for each flow, but maybe I rem= ember wrong. > > I was trying to locate the flows in the example in section 5.2, and I=20 > couldn't find them anywhere but in the MSID attribute. So I couldn't=20 > parse your comment. > > The way I read the document, the first m=3Daudio line is the main audio;= =20 > it has 3 audio flows. > The first m=3Dvideo line is the main video; it has 3 video flows. > The third m=3Dvideo line is the slides video; it has 2 SSRCs, one for the= =20 > main flow and one for the repair flow. > > So - the issue seems to be that the word "main" as in "main audio" is=20 > easy to mistake for "a single main flow". It isn't intended to be that=20 > way. I guess the text could be clearer. That is how I understood it - that "main" is a flow by itself, separate fro= m the left/center/right mic flows :) Maybe "media description for main audio flows" would be a move clear descri= ption, rather than simply "main audio". Regards, Christer From internet-drafts@ietf.org Tue May 7 11:29:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DAF21F9467; Tue, 7 May 2013 11:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvQ00Yyhiip8; Tue, 7 May 2013 11:29:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0814021F941D; Tue, 7 May 2013 11:29:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> Date: Tue, 07 May 2013 11:29:05 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:29:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Latching: Hosted NAT Traversal (HNT) for Media in Real-T= ime Communication Author(s) : Emil Ivov Hadriel Kaplan Dan Wing Filename : draft-ietf-mmusic-latching-01.txt Pages : 14 Date : 2013-05-07 Abstract: This document describes behavior of signalling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-latching-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-latching-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From emil@sip-communicator.org Tue May 7 11:32:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE1B21F9223 for ; Tue, 7 May 2013 11:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emCxZ7xim1xm for ; Tue, 7 May 2013 11:32:58 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id EF93921F915A for ; Tue, 7 May 2013 11:32:57 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id jf3so474144bkc.35 for ; Tue, 07 May 2013 11:32:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=pkfgj3D/sBxjoix4hX8ke5FLp+NX9SmRlfh1WZ1WPx0=; b=AuzaFACIEVWxc9RThpWlpMy8xk4C1yyWvUupArxniPNq63esFQbiN7KKRTiONEex9l D2bpeJvTz5B5mBHezd0tx19xaaqn0OHrOI3OKlonr3z6WeZRj+oXNTSmS1qa2H2IK5ZX SsZGeG6tHkDe1scLhXfnB1JBnvM6pKJEHUh4sRzEKeWRwTEPcLsgTZhFfdfED/Hulvrj D/Fp6twzy8dG3q/Y3T4C2NGYPkdXIhG/EQYVicZPwzHU0Tbbq6ot6R/Q2rrkPykYmL34 meljk0URWcCV+8f2gu94nSydSl5ud6Wugra2vgtn7pUmd0Ht2B3KLJOmoHjtxMTemIVL QnxQ== X-Received: by 10.205.128.204 with SMTP id hf12mr935189bkc.30.1367951576653; Tue, 07 May 2013 11:32:56 -0700 (PDT) Received: from camionet.local ([83.228.76.175]) by mx.google.com with ESMTPSA id f14sm7015340bky.16.2013.05.07.11.32.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 11:32:55 -0700 (PDT) Message-ID: <518948D3.5080600@jitsi.org> Date: Tue, 07 May 2013 21:32:51 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> In-Reply-To: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnzLO+8e1Mh+dj7fi7DsPTm+MUL8cZuwMDtCaWYjZ+Rxa6SXOpW0MXbbcC7sf20BwRVOQre Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:32:59 -0000 Hey all, We believe this draft addresses all comments that we've received during the last call so far. Thanks to everyone for the reviews! (The WGLC is still active for a few more hours so any other comments would of course be welcome). Cheers, Emil On 07.05.13, 21:29, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication > Author(s) : Emil Ivov > Hadriel Kaplan > Dan Wing > Filename : draft-ietf-mmusic-latching-01.txt > Pages : 14 > Date : 2013-05-07 > > Abstract: > This document describes behavior of signalling intermediaries in > Real-Time Communication (RTC) deployments, sometimes referred to as > Session Border Controllers (SBCs), when performing Hosted NAT > Traversal (HNT). HNT is a set of mechanisms, such as media relaying > and latching, that such intermediaries use to enable other RTC > devices behind NATs to communicate with each other. This document is > non-normative, and is only written to explain HNT in order to provide > a reference to the IETF community, as well as an informative > description to manufacturers, and users. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-latching-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-01 > > > 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 > -- https://jitsi.org From pkyzivat@alum.mit.edu Tue May 7 11:33:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E732621F93F8 for ; Tue, 7 May 2013 11:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.068 X-Spam-Level: X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-NTsA1ah7su for ; Tue, 7 May 2013 11:33:20 -0700 (PDT) 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 ECF0B21F9223 for ; Tue, 7 May 2013 11:33:19 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id YzNa1l0031ei1Bg5A6ZKd8; Tue, 07 May 2013 18:33:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id Z6ZK1l00U3ZTu2S3k6ZKvW; Tue, 07 May 2013 18:33:19 +0000 Message-ID: <518948EE.7030703@alum.mit.edu> Date: Tue, 07 May 2013 14:33:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> <5183D141.7060607@alum.mit.edu> <201305061800.r46I0R6t4259110@shell01.TheWorld.com> In-Reply-To: <201305061800.r46I0R6t4259110@shell01.TheWorld.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=1367951599; bh=dCV6xS9lKceWlzYw796TRGZe67WaJLByLwLULQqk9eY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UEcdGbDCHl0tkoIjrFWrUlR36qT99ayXN1C86GHGrOkn5wEuUfDr8K5EFexSnuRpN zRRVbjL8NnR0ABmIjDPstjUTMa5B44oYum0QWKWhT3f2hOyuvzXUVpd0PlteLGf9ZS R+zeqPQBSybcYxZIHaf1lHv3VDeL3NxQgkRN/bCwH4WX3L6AMoX1amdTP/pchA8qlq dCxP1qnl/q3aIf14RtlOxJFKEw18ICh9qc4X8zLagcoHzC+0jp4qGWaZI34sZ4Gb5u VB7HfF0qKUe48iTEsAyxXJPiVIaAxUUhHvsW/7TNLLh0Ehi/L00xpoSePsgU9P2r5m LPdO6Lj2755jg== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:33:26 -0000 On 5/6/13 2:00 PM, Dale R. Worley wrote: >> From: Paul Kyzivat >> >> (Note, this is a degenerate case of bundle splitting. There are real use >> cases for it. If it can be done without a 2nd o/a, then lets allow that.) > > Strictly speaking, it's not like other cases of bundle splitting, > because the separated m= line is not put into another bundle, but > remains unbundled. Because of that, the design considerations are > likely to be somewhat different. In my view it is a degenerate form that admits to special optimizations. It *could* be handled by establishing new bundles containing only the single m-line. But there is no value in doing that. And by *not* doing it, it is possible to handle everything in a single O/A rather than requiring a 2nd one. Thanks, Paul From pkyzivat@alum.mit.edu Tue May 7 11:36:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6528921F8B38 for ; Tue, 7 May 2013 11:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.142 X-Spam-Level: X-Spam-Status: No, score=-0.142 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmIqWlusWz0P for ; Tue, 7 May 2013 11:36:37 -0700 (PDT) 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 82C9921F8B2B for ; Tue, 7 May 2013 11:36:37 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id Yz4l1l0011ei1Bg556ccuF; Tue, 07 May 2013 18:36:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id Z6cc1l00b3ZTu2S3k6ccrK; Tue, 07 May 2013 18:36:36 +0000 Message-ID: <518949B4.9060601@alum.mit.edu> Date: Tue, 07 May 2013 14:36:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se>, <517FFB7E.8050801@alum.mit.edu>, , <51801BBD.1010505@alum.mit.edu>, , , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se>, <201305030115.r431Fis33999826@shell01.TheWorld.com> <201305061800.r46I0jM84247693@shell01.TheWorld.com> In-Reply-To: <201305061800.r46I0jM84247693@shell01.TheWorld.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=1367951796; bh=MkQsyFq7M8ksSf3IzNfZJcbjK6YnCfuw2HOxQaYATTU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=a7y1ZktiMxvvKY5c1IWc+JC2ziJeV7FKFkz6HBPgLicVjlOOrFon2rpOOgbrCOMrQ bLjBd/BjWdwy+BpsH2HeqJ5FW/iyegAVBgK4FHRdhGY7gzXmoUt9BrquKDWC/kadJ4 5nCooINoLYamZygcSSjydAtPiTvZJQ8kLGxKINKxAYijAteff5lucwN5X9SL08NPTX qc+ppO0HvgGSB+85sj/BsrEo6PcUXNtFL+QZOxcpeOwNXg+HSMoHjDFoOKYZUJQwyP xWGOFhrLccLn/bpW+qeNA1/+skvLLMYXO2obWrONz72JiQXKqUj13v7F91c67f9anF 3+OibufQrnoWg== Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:36:42 -0000 I'd just like to point out that AFAIK bundling doesn't *require* ICE. So lets not make any assumptions that assume ICE is used. Thanks, Paul On 5/6/13 2:00 PM, Dale R. Worley wrote: >> From: Bernard Aboba >> >>> But it doesn't seem that there is much to gain by mandating rtcp-mux >>> in the first offer/answer, the one where actual bundling is not being >>> done. All of the RTP/RTCP routing code that is active at that point >>> has to support non-rtcp-mux operation already. >> >> [BA] Support for rtcp-mux in the first offer/answer is mandated by >> RFC 5761 Section 5.1.3: >> The initial SDP offer MUST include this >> attribute at the media level to request multiplexing of RTP and RTCP >> on a single port. > > I don't see how 5761 mandates that a=rtcp-mux MUST be used in the > first offer of a bundle negotiation. The context of your quote is: > > 5.1.3. Interactions with ICE > [...] > If it is desired to use both ICE and multiplexed RTP and RTCP, the > initial offer MUST contain an "a=rtcp-mux" attribute to indicate that > RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" > lines for both RTP and RTCP along with an "a=rtcp:" line indicating a > fallback port for RTCP in the case that the answerer does not support > RTP and RTCP multiplexing. This MUST be done for each media where > RTP and RTCP multiplexing is desired. > > That is, if the device desires to use both ICE and multiplex, it has > to use a=rtcp-mux in the first offer of ICE's set of offers. But > we're talking about bundling, which (in the current design) contains > *two* ICE cycles, since the second offer (in the bundle spec) is going > to restart ICE. And the device need not "desire" to use "both ICE and > multiplexed RTP and RTCP" during the first of the ICE cycles. > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Tue May 7 12:23:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7484521F8F4D for ; Tue, 7 May 2013 12:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMeTh7RjvY1t for ; Tue, 7 May 2013 12:23:24 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BB7D721F8E7B for ; Tue, 7 May 2013 12:23:23 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-43-518954aa57ee Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 14.60.28165.AA459815; Tue, 7 May 2013 21:23:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Tue, 7 May 2013 21:23:22 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? Thread-Index: Ac5FpkrHryzI/aQNT0iUvXy00zH5hwADtcYAAAPFvoAAAQhZgAA4imSAABwqMXAABklLyAAANmRgABmo8HEABBaqAAC15MErAC9TbAAABct34A== Date: Tue, 7 May 2013 19:23:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36CCA8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se>, <517FFB7E.8050801@alum.mit.edu>, , <51801BBD.1010505@alum.mit.edu>, , , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se>, <201305030115.r431Fis33999826@shell01.TheWorld.com> <201305061800.r46I0jM84247693@shell01.TheWorld.com> <518949B4.9060601@alum.mit.edu> In-Reply-To: <518949B4.9060601@alum.mit.edu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre6qkM5Ag6XTLS2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj8cXVrAUHhSruzVzA2sB4hK+LkZNDQsBE YvraFewQtpjEhXvr2boYuTiEBA4zSqx72sUE4SxmlHjc8Zyli5GDg03AQqL7nzZIg4iAr8Sz x7fZQGxhARuJw409rBBxW4kp926wQ9h1Ene2fmACsVkEVCSef+wBi/MC9e6aupURaj6rxIM3 LxhB5nMK6Ej8vmUPUsMIdND3U2vAepkFxCU+HLzODHGogMSSPeehbFGJl4//sULYShKNS56w QtTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSN7bmJmTnq5 4SZGYCwc3PJbdwfjqXMihxilOViUxHmTuBoDhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDq dJfMm//mgtmSeK2jlWyLjQMeCLLtsYwPdbW94fg7Zb/vUZP6Y7Hi5x3Xhb1/cb0g8sxUc8e1 fS4HDTtyMrZah02XUVppteXIzQi+CZl/tyg5n9vbtJ8/Q17wR1GYkNHq30n9Ou4bvqY6Mzxe pXj2z5pi7WDuxKb8NWk9aTtXTXRf3rk6xUmJpTgj0VCLuag4EQAOgyH8UwIAAA== Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:23:36 -0000 Hi, >I'd just like to point out that AFAIK bundling doesn't *require* ICE. >So lets not make any assumptions that assume ICE is used. Agree. We do need to describe how ICE is used with BUNDLE, but BUNDLE can also be = used without ICE. Regards, Christer On 5/6/13 2:00 PM, Dale R. Worley wrote: >> From: Bernard Aboba >> >>> But it doesn't seem that there is much to gain by mandating rtcp-mux=20 >>> in the first offer/answer, the one where actual bundling is not=20 >>> being done. All of the RTP/RTCP routing code that is active at that=20 >>> point has to support non-rtcp-mux operation already. >> >> [BA] Support for rtcp-mux in the first offer/answer is mandated by=20 >> RFC 5761 Section 5.1.3: >> The initial SDP offer MUST include this >> attribute at the media level to request multiplexing of RTP and RTCP >> on a single port. > > I don't see how 5761 mandates that a=3Drtcp-mux MUST be used in the=20 > first offer of a bundle negotiation. The context of your quote is: > > 5.1.3. Interactions with ICE > [...] > If it is desired to use both ICE and multiplexed RTP and RTCP, the > initial offer MUST contain an "a=3Drtcp-mux" attribute to indicate th= at > RTP and RTCP multiplexing is desired and MUST contain "a=3Dcandidate:= " > lines for both RTP and RTCP along with an "a=3Drtcp:" line indicating= a > fallback port for RTCP in the case that the answerer does not support > RTP and RTCP multiplexing. This MUST be done for each media where > RTP and RTCP multiplexing is desired. > > That is, if the device desires to use both ICE and multiplex, it has=20 > to use a=3Drtcp-mux in the first offer of ICE's set of offers. But=20 > we're talking about bundling, which (in the current design) contains > *two* ICE cycles, since the second offer (in the bundle spec) is going=20 > to restart ICE. And the device need not "desire" to use "both ICE and=20 > multiplexed RTP and RTCP" during the first of the ICE cycles. > > Dale > _______________________________________________ > 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 worley@shell01.TheWorld.com Tue May 7 13:31:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A839221F8618 for ; Tue, 7 May 2013 13:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nH0F7s8wO3lc for ; Tue, 7 May 2013 13:31:06 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9F97E21F8B49 for ; Tue, 7 May 2013 13:31:06 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r47KU04c008780; Tue, 7 May 2013 16:30:02 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r47KTxqZ4319984; Tue, 7 May 2013 16:29:59 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r47KTxpv4300525; Tue, 7 May 2013 16:29:59 -0400 (EDT) Date: Tue, 7 May 2013 16:29:59 -0400 (EDT) Message-Id: <201305072029.r47KTxpv4300525@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C36C6D3@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> <201304251933.r3PJXuon3430760@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36098D@ESESSMB209.ericsson.se> <201304292200.r3TM0GmX3712511@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C368754@ESESSMB209.ericsson.se> <201305062201.r46M1F9j4269523@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36C6D3@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:31:12 -0000 > From: Christer Holmberg > > > But *the case I'm considering* is when the intermediate element > > (it might not be a proper SBC) edits the SDP but does not need to > > reprocess media. > > Well, in that case it doesn't need to support the codec either, does it? And conveniently, I've been told that in those cases, the intermediate device usually doesn't look at the codec specifications (though they often look at the media type in the m= line). Dale From worley@shell01.TheWorld.com Tue May 7 13:31:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B21421F92F5 for ; Tue, 7 May 2013 13:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrym0b-KzzeS for ; Tue, 7 May 2013 13:31:12 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1A721F8E4C for ; Tue, 7 May 2013 13:31:07 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r47KUIjj013722; Tue, 7 May 2013 16:30:20 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r47KUIEn4335890; Tue, 7 May 2013 16:30:18 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r47KUI534331379; Tue, 7 May 2013 16:30:18 -0400 (EDT) Date: Tue, 7 May 2013 16:30:18 -0400 (EDT) Message-Id: <201305072030.r47KUI534331379@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Magnus Westerlund In-reply-to: <517F7859.4060600@ericsson.com> (magnus.westerlund@ericsson.com) References: <201304292159.r3TLxwMs3753609@shell01.TheWorld.com> <517F7859.4060600@ericsson.com> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Demultiplexing via indexes in RTCP SDES packets X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:31:22 -0000 > From: Magnus Westerlund > > I do agree that part of a solution is the possibility to bind one or a > set of SSRCs to a particular usage that is signalled somehow. However, > there is several different types of bindings that is needed here. Just > binding to a m= line is likely short sighted, restrictive and incomplete. > > I support your proposal of including a level of indirection enabling us > to avoid having to update the SDP for any addition of SSRCs, which a > a=ssrc based solution would require. > > However, SDP is not the only signalling solution, it is the currently > dominating one, but if you ever is going enable us of breaking out of > the SDP trap, we need to ensure that the solutions around are not SDP > specific. > [A lot of examples of additional "binding" information that is > needed.] What you say is true, but those aren't the problems I'm looking at. My assumption is that any problem that needs to be solved will be solved (by somebody else) in a way that is workable in "SDP without bundling". Once that has been solved, then how do you solve the problem in a way that is workable in "SDP with bundling"? The latter is the part of the problem I'm looking to solve. It breaks into two parts: One part is the particular way bundling is signaled in SDP. The other part is the way that the RTP/RTCP over the bundled connection is demultiplexed. At this layer of analysis, all that is needed is to be able to sort the RTP and RTCP regarding which m= line it is associated with. The remaining parts of the SDP provide the other binding information that you discuss -- once the RTP is associated with the correct m= line, the problem is reduced to what the problem would be without bundling. Of course, if the signaling protocol isn't SDP, the demultiplexing I'm considering does not apply. But in that case, "bundling" as such isn't a consideration, because "bundling" is essentially how to use only one transport association to carry all of the packets described by an SDP description. Presumably any newer and better signaling protocol would be designed to not have the limitations of the existing SDP, and so the bundling problem would be taken care of from the beginnin. > I think one important question here is if you really want and think it > is possible to bind have each different usage or purpose for an RTP > media stream (specific SSRC) can be captured with its own unique Media > Description (m= block)? I've previously believed that media sources can be separated into a small number of "roles"; that any application intrinsically defines a (very) small number of roles; and that the multiple SSRCs for the multiple media sources that all have the same role can all be sent under one SDP m= line without confusion. But it appears that the above belief is not true, so I'm considering a different demultiplexing algorithm, one that does not require distinct payload type numbers for different m= lines (and thus can support a large number of m= lines and a large number of payload type numbers for each m= line). A fundamental problem with this sort of demultiplexing is how to do it without putting a prefix or encapsulation on every RTP packet (as that makes it harder for intermediate devices to see the nature of the contained data). But we can do indirection, following the SSRC from the RTP packet to information carried in the corresponding RTCP. Dale From christer.holmberg@ericsson.com Tue May 7 14:06:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994ED21F8AA6 for ; Tue, 7 May 2013 14:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0fy5h5LJzZ3 for ; Tue, 7 May 2013 14:06:05 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E656D21F8A6B for ; Tue, 7 May 2013 14:06:04 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-b6-51896cbb3161 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1E.95.01956.BBC69815; Tue, 7 May 2013 23:06:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Tue, 7 May 2013 23:06:03 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOS2Gki+cVnxjNCEKSb6lvFRbbnJj6NlNg Date: Tue, 7 May 2013 21:06:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36CE31@ESESSMB209.ericsson.se> References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> <201304251933.r3PJXuon3430760@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36098D@ESESSMB209.ericsson.se> <201304292200.r3TM0GmX3712511@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C368754@ESESSMB209.ericsson.se> <201305062201.r46M1F9j4269523@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36C6D3@ESESSMB209.ericsson.se> <201305072029.r47KTxpv4300525@shell01.TheWorld.com> In-Reply-To: <201305072029.r47KTxpv4300525@shell01.TheWorld.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre6enM5Ag3l/2SymLn/MYvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbFo+VzmgmksFU/2r2RpYFzM3MXIySEhYCIx b80SNghbTOLCvfVANheHkMBhRonFz6ayQjiLGSW6nk4C6uDgYBOwkOj+pw1iighoSnQsyAEx mQXUJa4uDgIZIwxU8O3IbHYQW0TAUuLm8vMsELaRRNOP9WCrWARUJE593ANm8wr4Snw++wVq 7RJWieWPT4IlOAUcJHbMaGUCsRmBbvt+ag2YzSwgLvHh4HWo+wUkluw5D2WLSrx8/I8VwlaS +LHhEgtEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYxsucm Zuakl5tvYgTGx8Etvw12MG66L3aIUZqDRUmcN5mrMVBIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY4mfUiDTGV/r+9550S91DEqf7RDPOVZ/6ACLlcWSkpmrFDaf5r//eJJZ968jEyq2bSjx y27YJLI6NtTs2YOdYuzWD1W0DxXk5abuOBRhwGx2fJrO773Bb24+T33HmrD13QcvY9UFIvlt cTq7+SeGNesfThKYuqV52wLFU507A74Jl3jES07fpcRSnJFoqMVcVJwIAMWnO4ddAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 21:06:11 -0000 Hi, >>> But *the case I'm considering* is when the intermediate element (it=20 >>> might not be a proper SBC) edits the SDP but does not need to=20 >>> reprocess media. >>=20 >> Well, in that case it doesn't need to support the codec either, does it? > > And conveniently, I've been told that in those cases, the intermediate de= vice usually doesn't look at the codec specifications (though they often lo= ok at the media type in the m=3D line). Media type and codec are two separate things. Regards, Christer From bernard_aboba@hotmail.com Tue May 7 14:56:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9BD21F8F2C; Tue, 7 May 2013 14:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15y4-BNv82iq; Tue, 7 May 2013 14:56:11 -0700 (PDT) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5AD21F8F03; Tue, 7 May 2013 14:56:11 -0700 (PDT) Received: from BLU169-W108 ([65.55.111.73]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 14:56:10 -0700 X-EIP: [izp0FB9rnfTVCJ71FBPs+TcF4RFmoqVd5NwWkxvuy8M=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_a6681fa6-d553-4a7a-9cfe-d3526eb65904_" From: Bernard Aboba To: Roni Even , 'Justin Uberti' , "rtcweb@ietf.org" , "mmusic@ietf.org" Date: Tue, 7 May 2013 14:56:10 -0700 Importance: Normal In-Reply-To: <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 21:56:10.0889 (UTC) FILETIME=[AF89DF90:01CE4B6D] Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 21:56:18 -0000 --_a6681fa6-d553-4a7a-9cfe-d3526eb65904_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni said: =20 3. The draft=2C as far as I can tell=2C is discussing point to point = calls and full meshed conferences. I think we need to look at other topolog= ies including a centralized MCU doing video switch=2C for example. [BA] There should be an evaluation against the RTP topology bis draft which= would include assessment of compatibility. In addition to "video switch" = I would be interested in RTP translator compatibility as well.=20 4. In section 4.1 you suggest using the MSID as an indication for sup= porting plan B. I think that this may be RTCWEB specific and other usages l= ike CLUE may use a different way to associate an SSRC to a Media Capture. M= y proposal is to use maxssrc.=20 [BA] Among other things=2C putting maxssrc in the Offer partially addresses= the issue of being able to receive streams before the Answer is received. = However=2C since the Offerer will not know the SSRCs that it is expected t= o receive there has got to be a way to map the incoming streams to WebRTC m= ediastreams. =20 5. I have a question about the last paragraph of section 4.2. Current= ly the answerer can start sending media immediately when getting the offer = in parallel to sending the SDP answer since the offer includes receive capa= bilities and receive transport address. Are you suggesting that media will = flow only after the 3 way handshake? [BA] Yes=2C I think that is the implication=2C though it doesn't seem eithe= r necessary or desirable to me. Actually=2C I don't think that "Peer B" wi= ll be able to send until it gets an Answer to its Offer (the second Offer/A= nswer exchange)=2C because it won't know what streams "Peer A" is prepared = to accept (assuming there is no maxssrc in the initial offer). =20 = --_a6681fa6-d553-4a7a-9cfe-d3526eb65904_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roni said:

 =3B


3.&= nbsp=3B =3B =3B =3B =3B =3B The draft=2C= as far as I can tell=2C is discussing point to point calls and full meshed= conferences. I think we need to look at other topologies including a centr= alized MCU doing video switch=2C for example.


[BA] There should be an evaluation against the RTP to= pology bis draft which would include assessment of compatibility. =3B I= n addition to "video switch" I would be interested in RTP translator compat= ibility as well.


4. =3B =3B =3B =3B =3B =3B In section 4.1 you suggest using the MSID as an indication for support= ing plan B. I think that this may be RTCWEB specific and other usages like = CLUE may use a different way to associate an SSRC to a Media Capture. My pr= oposal is to use maxssrc.

=


[BA] Among = other things=2C putting maxssrc in the Offer partially addresses the issue = of being able to receive streams before the Answer is received. =3B How= ever=2C since the Offerer will not know the SSRCs that it is expected to re= ceive there has got to be a way to map the incoming streams to WebRTC media= streams.  =3B



5. =3B =3B =3B =3B =3B =3B I h= ave a question about the last paragraph of section 4.2. Currently the answe= rer can start sending media immediately when getting the offer in parallel = to sending the SDP answer since the offer includes receive capabilities and= receive transport address. Are you suggesting that media will flow only af= ter the 3 way handshake?


=

[BA] Yes=2C I think that is the implication=2C though it doesn't= seem either necessary or desirable to me. =3B Actually=2C I don't thin= k that "Peer B" will be able to send until it gets an Answer to its Offer (= the second Offer/Answer exchange)=2C because it won't know what streams "Pe= er A" is prepared to accept (assuming there is no maxssrc in the initial of= fer). =3B



= --_a6681fa6-d553-4a7a-9cfe-d3526eb65904_-- From bernard_aboba@hotmail.com Tue May 7 15:02:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E47A21F905F; Tue, 7 May 2013 15:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8VzJSP47cD9; Tue, 7 May 2013 15:02:11 -0700 (PDT) Received: from blu0-omc1-s25.blu0.hotmail.com (blu0-omc1-s25.blu0.hotmail.com [65.55.116.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8D49121F86F0; Tue, 7 May 2013 15:02:11 -0700 (PDT) Received: from BLU169-W108 ([65.55.116.9]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 15:02:09 -0700 X-EIP: [z+ikBbIH0mZ0gFFuDSFbCAnQhucye7spSp/gk4LOp2Y=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_f739abbd-a421-4394-b155-2762a690f704_" From: Bernard Aboba To: Harald Alvestrand , Roni Even Date: Tue, 7 May 2013 15:02:09 -0700 Importance: Normal In-Reply-To: <518900CF.6050403@alvestrand.no> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <518900CF.6050403@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 22:02:09.0543 (UTC) FILETIME=[85502170:01CE4B6E] Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 22:02:17 -0000 --_f739abbd-a421-4394-b155-2762a690f704_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni said:=20 I=0A= think that plan B is the right direction. I am wondering if=0A= this should be discussed in RTCWEB or MMUSIC=0A= =0A= =0A= =20 =0A= To the extent that the proposals are attempts to "profile" existing RFC= s or MMUSIC work in progress for use in WebRTC=2C it seems to me like the d= iscussion belongs in RTCWEB. One advantage of that approach is that the sol= ution need not necessarily apply to "all uses of SDP for any scenario for a= ll time"=2C just to the WebRTC use cases.=20 To the extent that NEW SDP functionality is needed=2C MMUSIC discussion wou= ld be appropriate. But until the general direction is decided=2C it won't = be clear what the required new functionality is (if any). =20 =0A= =20 =0A= =0A= =0A= =20 = --_f739abbd-a421-4394-b155-2762a690f704_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roni said:

I=0A= think that plan B is the right direction. I am wondering if=0A= this should be discussed in RTCWEB or MMUSIC

=0A=
=0A= =0A=
=0A= To the extent that the proposals are attempts to "profile" existing RFC= s or MMUSIC work in progress for use in WebRTC=2C it seems to me like the d= iscussion belongs in RTCWEB. One advantage of that approach is that the sol= ution need not necessarily apply to "all uses of SDP for any scenario for a= ll time"=2C just to the WebRTC use cases.

To the extent that NEW SD= P functionality is needed=2C MMUSIC discussion would be appropriate. = =3B But until the general direction is decided=2C it won't be clear what th= e required new functionality is (if any). =3B
=0A=
=0A=
=0A=
=0A=


= --_f739abbd-a421-4394-b155-2762a690f704_-- From bernard_aboba@hotmail.com Tue May 7 15:28:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A251421F8FA3 for ; Tue, 7 May 2013 15:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXVp9eRiZmy2 for ; Tue, 7 May 2013 15:28:23 -0700 (PDT) Received: from blu0-omc3-s17.blu0.hotmail.com (blu0-omc3-s17.blu0.hotmail.com [65.55.116.92]) by ietfa.amsl.com (Postfix) with ESMTP id C61AE21F8F28 for ; Tue, 7 May 2013 15:28:22 -0700 (PDT) Received: from BLU169-W126 ([65.55.116.73]) by blu0-omc3-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 15:28:22 -0700 X-EIP: [g+oTpYYNHCuewQ3CRzghxZfsLp91icHhCcbwWBZlOL4=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_bbc70912-89fb-4d2b-95b7-10b201cc239e_" From: Bernard Aboba To: Magnus Westerlund Date: Tue, 7 May 2013 15:28:21 -0700 Importance: Normal In-Reply-To: <517F7859.4060600@ericsson.com> References: <201304292159.r3TLxwMs3753609@shell01.TheWorld.com>, <517F7859.4060600@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 22:28:22.0627 (UTC) FILETIME=[2EF1B330:01CE4B72] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Demultiplexing via indexes in RTCP SDES packets X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 22:28:27 -0000 --_bbc70912-89fb-4d2b-95b7-10b201cc239e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Magnus said:=20 > I support your proposal of including a level of indirection enabling us > to avoid having to update the SDP for any addition of SSRCs=2C which a > a=3Dssrc based solution would require. >=20 > However=2C SDP is not the only signalling solution=2C it is the currently > dominating one=2C but if you ever is going enable us of breaking out of > the SDP trap=2C we need to ensure that the solutions around are not SDP > specific.=20 [BA] Indeed. It is one thing to chain the WebRTC API to the SDP boat ancho= r=3B it is another thing to require use of SDP eyeglasses to navigate the = ship by REQUIRING SDP to be used in order to make sense of RTP SDES packets= . Overall=2C I think that various aspects of WebRTC (including things like= signalling resolution or frame rate changes) should be handled in RTP/RTCP= rather than in signalling so as to maintain WebRTC signalling independence= .=20 >Thus=2C using SDES items for in stream bindings are something I > support=2C but the label should be done in such a way that it can be > handled as labels for a particular purpose and thus be included in other > signalling solutions. [BA] Agree.=20 > - Application related usage of video streams=2C for example if a SSRC is > currently carrying a main video or a thumbnail and thus which negotiated > constraints it tries to adhere to. [BA] I believe that this is often handled today by cooperation between the = mixer and application without new RTP/SDP functionality (other than simultc= ast/layering support). For example=2C the mixer can decide to forward a h= igher bandwidth simulcast stream or more layers since the audio indicates t= hat the stream relates to the speaker. The application sees the change and= promotes the stream to the main video and demotes the stream previously oc= cupying the main video to a thumbnail. Why couldn't this approach work for= WebRTC as well? Isn't enabling dynamism the goal of frameworks such as An= gularJS?=20 =20 > - Is the this SSRC part of a simulcast set=2C and if which quality strata > does it carry [BA] This could potentially be indicated inband within the codec=2C which = would enable a receiver to figure things out before the Answer arrived.=20 =20 > - Is this SSRC a related repair or retransmission stream to another > primary media carrying SSRC. >=20 > One issue is that for example the first can easily be a dynamic process= =2C > some implementations will reconfigure a SSRC between application purpose > due to user or application input. >=20 > Just these three above examples points to one very clear issues in > making progress here. We must try to clearly define the usage different > people see. See which is the same=2C which is orthogonal and which must b= e > possible to have in place at the same time. >=20 > This is the realization we have come to with in the discussion around > the SRCNAME proposal: > http://tools.ietf.org/html/draft-westerlund-avtext-rtcp-sdes-srcname [BA] Yes=2C there are advantages to additional SDES information that should= be explored further=2C particularly in situations where signalling indepen= dence is a goal. Personally=2C I was ok with the initial drafts of SRCNAME= =2C but am not sure it can be stretched to handle all the simulcast/layerin= g info (since that may end up in-band within the codec anyway) . > This discussion has proven the importance of having common terminology > and I hope we can make progress with the grouping taxonomy=2C because tha= t > document will discuss both object names and different possible relation > ships between these different types of object=2C like RTP sessions=2C SSR= Cs=2C > FEC groups. [BA] IMHO=2C I think it has proven we do not have agreement about some very= basic architectural issues :) > I think one important question here is if you really want and think it > is possible to bind have each different usage or purpose for an RTP > media stream (specific SSRC) can be captured with its own unique Media > Description (m=3D block)? [BA] I don't know that each SSRC has to be bound to its own unique Media Description (e.g. only one SSRC to an "m=3D" line). I also don't think tha= t each SSRC should have to have its own a=3Dssrc line either. As long as it is po= ssible to figure out what parameters apply to a given SSRC (some of which could be transmitted within the codec and some within SDES)=2C that is enough. =20 Applications are built today and they work without the restrictions being proposed in either Plan A or Plan B. Handling these things isn't even all that complicated.=20 > I also think it is important to realize that a particular SSRC may at > the same time have multiple relationships=2C for example it can be the > primary for a retransmission=2C part of a FEC group=2C be a particular > simulcast quality strata. [BA] Personally=2C I'd like to see an Internet-Draft describing what existi= ng implementations do before advocating that we allow infinite degrees of flexibility here. For example=2C there are implementations that use distin= ct SSRCs for different simulcast streams and layers (which is why things like SDP SSRC groups and SDES SRCNAME can be useful to bind them together). =20 > Please don't bind identifier and group ides to SDP concepts. Lets use a > level of indirection that both enables usage without SDP in certain > cases=2C and which can be bound to other signalling solutions in the futu= re. [BA] I agree -- and thank you for sending this to the list.=20 = --_bbc70912-89fb-4d2b-95b7-10b201cc239e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Magnus said:

>=3B= I support your proposal of including a level of indirection enabling us>=3B to avoid having to update the SDP for any addition of SSRCs=2C whic= h a
>=3B a=3Dssrc based solution would require.
>=3B
>=3B H= owever=2C SDP is not the only signalling solution=2C it is the currently>=3B dominating one=2C but if you ever is going enable us of breaking ou= t of
>=3B the SDP trap=2C we need to ensure that the solutions around = are not SDP
>=3B specific.

[BA] Indeed. =3B It is one thin= g to chain the WebRTC API to the SDP boat anchor=3B =3B it is another t= hing to require use of SDP eyeglasses to navigate the ship by REQUIRING SDP= to be used in order to make sense of RTP SDES packets. =3B Overall=2C = I think that various aspects of WebRTC (including things like signalling re= solution or frame rate changes) should be handled in RTP/RTCP rather than i= n signalling so as to maintain WebRTC signalling independence.

>= =3BThus=2C using SDES items for in stream bindings are something I
>= =3B support=2C but the label should be done in such a way that it can be>=3B handled as labels for a particular purpose and thus be included in = other
>=3B signalling solutions.

[BA] Agree.

>=3B - A= pplication related usage of video streams=2C for example if a SSRC is
&g= t=3B currently carrying a main video or a thumbnail and thus which negotiat= ed
>=3B constraints it tries to adhere to.

[BA] I believe that = this is often handled today by cooperation between the mixer and applicatio= n without new RTP/SDP functionality (other than simultcast/layering support= ). =3B =3B For example=2C the mixer can decide to forward a higher = bandwidth simulcast stream or more layers since the audio indicates that th= e stream relates to the speaker. =3B The application sees the change an= d promotes the stream to the main video and demotes the stream previously o= ccupying the main video to a thumbnail. =3B Why couldn't this approach = work for WebRTC as well? =3B Isn't enabling dynamism the goal of framew= orks such as AngularJS?
 =3B
>=3B - Is the this SSRC part of a= simulcast set=2C and if which quality strata
>=3B does it carry
[BA] =3B This could potentially be indicated inband within the codec= =2C which would enable a receiver to figure things out before the Answer ar= rived.
 =3B
>=3B - Is this SSRC a related repair or retransmis= sion stream to another
>=3B primary media carrying SSRC.
>=3B >=3B One issue is that for example the first can easily be a dynamic pro= cess=2C
>=3B some implementations will reconfigure a SSRC between appl= ication purpose
>=3B due to user or application input.
>=3B
&= gt=3B Just these three above examples points to one very clear issues in>=3B making progress here. We must try to clearly define the usage diffe= rent
>=3B people see. See which is the same=2C which is orthogonal and= which must be
>=3B possible to have in place at the same time.
>= =3B
>=3B This is the realization we have come to with in the discussi= on around
>=3B the SRCNAME proposal:
>=3B http://tools.ietf.org/h= tml/draft-westerlund-avtext-rtcp-sdes-srcname

[BA] Yes=2C there are = advantages to additional SDES information that should be explored further= =2C particularly in situations where signalling independence is a goal.&nbs= p=3B Personally=2C I was ok with the initial drafts of SRCNAME=2C but am no= t sure it can be stretched to handle all the simulcast/layering info (since= that may end up in-band within the codec anyway) .

>=3B This disc= ussion has proven the importance of having common terminology
>=3B and= I hope we can make progress with the grouping taxonomy=2C because that
= >=3B document will discuss both object names and different possible relat= ion
>=3B ships between these different types of object=2C like RTP ses= sions=2C SSRCs=2C
>=3B FEC groups.

[BA] IMHO=2C I think it has = proven we do not have agreement about some very basic architectural issues = :)
>=3B I think one important question here is if you really want and = think it
>=3B is possible to bind have each different usage or purpose= for an RTP
>=3B media stream (specific SSRC) can be captured with its= own unique Media
>=3B Description (m=3D block)?

[BA] I don't k= now that each SSRC has to be bound to its own unique Media
Description (= e.g. only one SSRC to an "m=3D" line). =3B I also don't think that each=
SSRC should have to have its own a=3Dssrc line either. =3B As long = as it is possible
to figure out what parameters apply to a given SSRC (s= ome of which could
be transmitted within the codec and some within SDES)= =2C that is enough. =3B
Applications are built today and they work = without the restrictions being
proposed in either Plan A or Plan B. = =3B =3B Handling these things isn't even all
that complicated.
<= br>>=3B I also think it is important to realize that a particular SSRC ma= y at
>=3B the same time have multiple relationships=2C for example it = can be the
>=3B primary for a retransmission=2C part of a FEC group=2C= be a particular
>=3B simulcast quality strata.

[BA] Personally= =2C I'd like to see an Internet-Draft describing what existing
implement= ations do before advocating that we allow infinite degrees of
flexibilit= y here. =3B For example=2C there are implementations that use distinct<= br>SSRCs for different simulcast streams and layers (which is why things li= ke
SDP SSRC groups and SDES SRCNAME can be useful to bind them together)= . =3B

>=3B Please don't bind identifier and group ides to SDP= concepts. Lets use a
>=3B level of indirection that both enables usag= e without SDP in certain
>=3B cases=2C and which can be bound to other= signalling solutions in the future.

[BA] I agree -- and thank you f= or sending this to the list.
= --_bbc70912-89fb-4d2b-95b7-10b201cc239e_-- From ron.even.tlv@gmail.com Tue May 7 15:47:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FC321F90DF; Tue, 7 May 2013 15:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGr+cS5E3zaV; Tue, 7 May 2013 15:47:54 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6F27921F9054; Tue, 7 May 2013 15:47:53 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so4472242wgg.4 for ; Tue, 07 May 2013 15:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=JW6aovL1kjSKH3Tn6s2HOMeS5xbMjeJ+HgmursTftZU=; b=cPYHRT3+unJnI9wPZRs3S1ZEhzW1yc906EnB/BoEb9j9pWCo6k7AxHS3SRnQZpEoBG /rjKHNd7uxv6vJzVfQr35G94BKDMl5QqBkpJA1HfTnkGzEO1HfgH5LF8hhJQmfG6qRjJ jCWUglox70VjjDmhwyIRQ9riKtzYYnpbpqb9XY9sow/I6cBObKMdnANK7Si9PPGXxHcB HFEFNdVMWw3OzNHLqP1WySD8k73zpF7/bR8ICaxeZH7gMpHhf2o19zv/x4X4xi3UwKlH KBAgb6IZ7NTU+CM087uNN+nfYXFk50cEujYqfQRz/3mPemikZNuslCmMUklrfjqbSn71 MWyw== X-Received: by 10.180.160.134 with SMTP id xk6mr9833360wib.21.1367966872493; Tue, 07 May 2013 15:47:52 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id s1sm5737569wiz.2.2013.05.07.15.47.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 15:47:51 -0700 (PDT) From: "Roni Even" To: "'Bernard Aboba'" , "'Harald Alvestrand'" References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <518900CF.6050403@alvestrand.no> In-Reply-To: Date: Wed, 8 May 2013 01:47:02 +0300 Message-ID: <00d701ce4b74$cc846000$658d2000$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01CE4B8D.F1D23440" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfv5wx4y9wP/O/FJv66Nx2OU8XsQM3rT1TAYHWzfgBm/E5GwHeOU28Aj4bM9CYA9p5gA== Content-Language: en-us Cc: rtcweb@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 22:47:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D8_01CE4B8D.F1D23440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bernard, The reason I asked was before plan A and plan B were discussed in MMUSIC in Orlando. Yet I understand that if the purpose of this draft and Adam's one are to describe how to do things in RTCweb it should be discussed in RTCWEB. And we will need a similar one in CLUE probably in draft-ietf-clue-rtp-mapping Roni From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: 08 May, 2013 1:02 AM To: Harald Alvestrand; Roni Even Cc: rtcweb@ietf.org; mmusic@ietf.org Subject: RE: [rtcweb] [MMUSIC] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt Roni said: I think that plan B is the right direction. I am wondering if this should be discussed in RTCWEB or MMUSIC To the extent that the proposals are attempts to "profile" existing RFCs or MMUSIC work in progress for use in WebRTC, it seems to me like the discussion belongs in RTCWEB. One advantage of that approach is that the solution need not necessarily apply to "all uses of SDP for any scenario for all time", just to the WebRTC use cases. To the extent that NEW SDP functionality is needed, MMUSIC discussion would be appropriate. But until the general direction is decided, it won't be clear what the required new functionality is (if any). ------=_NextPart_000_00D8_01CE4B8D.F1D23440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bernard,

The reason I asked was before plan A and plan B were discussed in = MMUSIC in Orlando. Yet I understand that if the purpose of this draft = and Adam’s one are to describe how to do things in RTCweb it = should be discussed in RTCWEB. And we will need a similar one in CLUE = probably in draft-ietf-clue-rtp-mapping

Roni

 

From:= = Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: 08 = May, 2013 1:02 AM
To: Harald Alvestrand; Roni = Even
Cc: rtcweb@ietf.org; mmusic@ietf.org
Subject: = RE: [rtcweb] [MMUSIC] Fwd: New Version Notification for = draft-uberti-rtcweb-plan-00.txt

 

Roni said: =

I think that plan B is the right direction. I am wondering if this = should be discussed in RTCWEB or MMUSIC

=


To the extent that the = proposals are attempts to "profile" existing RFCs or MMUSIC = work in progress for use in WebRTC, it seems to me like the discussion = belongs in RTCWEB. One advantage of that approach is that the solution = need not necessarily apply to "all uses of SDP for any scenario for = all time", just to the WebRTC use cases.

To the extent that = NEW SDP functionality is needed, MMUSIC discussion would be = appropriate.  But until the general direction is decided, it won't = be clear what the required new functionality is (if any).  =


 

=
------=_NextPart_000_00D8_01CE4B8D.F1D23440-- From bernard_aboba@hotmail.com Tue May 7 16:07:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C261121F90CD; Tue, 7 May 2013 16:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJmS5SrUTu3j; Tue, 7 May 2013 16:07:06 -0700 (PDT) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by ietfa.amsl.com (Postfix) with ESMTP id C8BAA21F905F; Tue, 7 May 2013 16:07:06 -0700 (PDT) Received: from BLU169-W4 ([65.55.111.71]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 16:07:06 -0700 X-EIP: [z8UyhQM504Tf75ckwG92qWmBYhYCPrBNPjyVqZXitwE=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d290e148-fa9f-4ebf-9aac-15bb029a37ec_" From: Bernard Aboba To: Roni Even , 'Harald Alvestrand' Date: Tue, 7 May 2013 16:07:06 -0700 Importance: Normal In-Reply-To: <00d701ce4b74$cc846000$658d2000$@gmail.com> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <518900CF.6050403@alvestrand.no> , <00d701ce4b74$cc846000$658d2000$@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 23:07:06.0388 (UTC) FILETIME=[98037D40:01CE4B77] Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 23:07:13 -0000 --_d290e148-fa9f-4ebf-9aac-15bb029a37ec_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Roni said:=20 "If the purpose of this draft and Adam=92s one are to describe how to do th= ings in RTCweb it should be discussed in RTCWEB. And we will need a similar= one in CLUE probably in draft-ietf-clue-rtp-mapping." [BA] There are RTP issues to discuss (e.g. draft-ietf-clue-rtp-mapping rela= tionship to draft-ietf-rtcweb-rtp-usage)=2C and there are SDP issues. To d= ate=2C I believe we have somewhat neglected the RTP discussion=2C which is = unfortunate=2C because if all the time is spent talking about the SDP Hamme= r=2C then the inclination is to use it to pound every nail=2C and if there = is no SDP=2C then we have no tools at all.=20 The place for the RTP discussion is probably not in RTCWEB (more like AVTCO= RE).=20 = --_d290e148-fa9f-4ebf-9aac-15bb029a37ec_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Roni said:
"If the purpose of this draft and Adam=92s = one are to describe how to do things in RTCweb it should be discussed in RT= CWEB. And we will need a similar one in CLUE probably in draft-ietf-clue-rt= p-mapping."

[BA] There are RTP issues to discuss (e.g. draft-= ietf-clue-rtp-mapping relationship to draft-ietf-rtcweb-rtp-usage)=2C and t= here are SDP issues. =3B To date=2C I believe we have somewhat neglecte= d the RTP discussion=2C which is unfortunate=2C because if all the time is = spent talking about the SDP Hammer=2C then the inclination is to use it to = pound every nail=2C and if there is no SDP=2C then we have no tools at all.=

The place for the RTP discussion is probably not in RTCWEB (more l= ike AVTCORE).



 =3B

= --_d290e148-fa9f-4ebf-9aac-15bb029a37ec_-- From stefan.lk.hakansson@ericsson.com Wed May 8 01:54:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5100321F8F53 for ; Wed, 8 May 2013 01:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi17WyNTOmFO for ; Wed, 8 May 2013 01:54:19 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1932921F8EDA for ; Wed, 8 May 2013 01:54:18 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-f3-518a12b8cc85 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C1.07.01956.8B21A815; Wed, 8 May 2013 10:54:16 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 8 May 2013 10:54:16 +0200 Message-ID: <518A12B7.6090409@ericsson.com> Date: Wed, 8 May 2013 10:54:15 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <518A1268.8090107@ericsson.com> In-Reply-To: <518A1268.8090107@ericsson.com> X-Forwarded-Message-Id: <518A1268.8090107@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre4Ooa5Ag52/bCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO5nL9gLJspXzJ/UzdLAuEKyi5GDQ0LAROL3ac0uRk4gU0zi wr31bF2MXBxCAqcYJfoPvmWHcNYwSrQtmcgMUsUroC0xb8szNhCbRUBFYtOSgywgNptAoMT1 /7+YQGxRgSiJf293M0LUC0qcnPkErEZEQFhixtu/YL3CAjESlz8tBKsXApq55/tzVhCbU0BH Ys3Gf+wQF5lLHN90A6yXWcBW4sKc61C2vETz1tnMEL26Eu9e32OdwCg4C8m6WUhaZiFpWcDI vIqRPTcxMye93HwTIzD8Dm75bbCDcdN9sUOM0hwsSuK8yVyNgUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoYa5JOODn+O3eYy1j9mrzP3N262RN9LPXP7575w/21KIf+5LCMK/P53df7rdtX /sZadKpgyb6WXzmPz9jz3Nght20py7m+rYI8n4xsZseHqyhPbBDk3x+vZ2Jw/73d2mvMfBfX Gtu/7q1c9MRgWQ7nlkNLXm8+sFdYJkDY2zj7qfOhAxGWsXEzlViKMxINtZiLihMBxczhsw0C AAA= Subject: [MMUSIC] Fwd: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 08:54:25 -0000 This should probably have gone to this list as well. -------- Original Message -------- Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt Date: Wed, 8 May 2013 10:52:56 +0200 From: Stefan Håkansson LK To: I think this could work. There are some parts that I like a lot (and, yes, I tend to have a narrow rtcweb centric perspective): * The (3-way) handshake is well aligned with the API (where the sending app initiates the sending of media) * That simulcast and layered encoding is supported * The text about end-points ensuring that its SSRC's are unique - I think this enables mixers/translators to form arbitrary RTP sessions * It is outlined how sending, or stop sending, is signaled per MediaStreamTrack One thing I do not understand is why the imageattr is signaled in the sending direction in the examples. Is not this info anyway part of the bitstream and will become apparent during the decoding process? It would be more natural to signal imageattr from the receiver (e.g. the receiver telling the sender the size of the video display). (An alternative would be to not signal it at all but leave it to app proprietary signaling and the APIs available to the sending application). I think that an alternative for simulcast could be that, instead of sending several resolutions for the same MediaStreamTrack, it was designed so that a separate MediaStreamTrack would have to be used (and the tracks would of course have to be synced) for each resolution. The primary reason is that the application can only really handle data down to the MediaStreamTrack level - there are no handles below that level in the API's currently. I thing that strikes me is that perhaps we could lift out the msid signaling into its own block, that established the MediaStream and MediaStreamTrack structure of the outgoing media and how is relates to SSRC's. The MediaStream-id/MediaStreamTrack-id info is only relevant to WebRTC endpoints and could be ripped out if the endpoint is legacy, and the remaining SDP would have fewer strange (to legacy) elements. On 2013-05-03 08:08, Justin Uberti wrote: > Scribbled down the basic concepts of what I have been referring to as > "Plan B" - a way to signal multiple MediaStreamTracks in SDP without > needing a separate m= line for each. > > Hopefully this will make discussion of this topic easier. > > ---------- Forwarded message ---------- > From: ** > > Date: Thu, May 2, 2013 at 10:46 PM > Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt > To: Justin Uberti > > > > > A new version of I-D, draft-uberti-rtcweb-plan-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-plan > Revision: 00 > Title: Plan B: a proposal for signaling multiple media sources > in WebRTC. > Creation date: 2013-05-03 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan > Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > > > Abstract: > This document explains how multiple media sources can be signaled in > WebRTC using SDP, in a fashion that avoids many common problems and > provides a simple control surface to the receiver. > > > > > The IETF Secretariat > > > > > > _______________________________________________ > 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 From harald@alvestrand.no Wed May 8 03:05:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2321F85EF; Wed, 8 May 2013 03:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.198 X-Spam-Level: X-Spam-Status: No, score=-110.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x87e0g4UoGqY; Wed, 8 May 2013 03:05:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DE24821F85CC; Wed, 8 May 2013 03:05:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0243A39E18D; Wed, 8 May 2013 12:05:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2ifBMiQxOAS; Wed, 8 May 2013 12:05:37 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CC45939E062; Wed, 8 May 2013 12:05:36 +0200 (CEST) Message-ID: <518A236F.6060909@alvestrand.no> Date: Wed, 08 May 2013 12:05:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Bernard Aboba References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> , , <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <518900CF.6050403@alvestrand.no> , <00d701ce4b74$cc846000$658d2000$@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080302090407080003090203" Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 10:05:47 -0000 This is a multi-part message in MIME format. --------------080302090407080003090203 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 05/08/2013 01:07 AM, Bernard Aboba wrote: > Roni said: > "If the purpose of this draft and Adam’s one are to describe how to do > things in RTCweb it should be discussed in RTCWEB. And we will need a > similar one in CLUE probably in draft-ietf-clue-rtp-mapping." > > [BA] There are RTP issues to discuss (e.g. draft-ietf-clue-rtp-mapping > relationship to draft-ietf-rtcweb-rtp-usage), and there are SDP > issues. To date, I believe we have somewhat neglected the RTP > discussion, which is unfortunate, because if all the time is spent > talking about the SDP Hammer, then the inclination is to use it to > pound every nail, and if there is no SDP, then we have no tools at all. I felt that the discussion of draft-ietf-rtcweb-rtp-usage was largely uncontroversial in the Stockholm interim, and that not much further discussion of that level of the stack was needed - so I have not been worrying much about it after that. It's more like we've got the RTP nail in place, and are hammering on it with the SDP hammer... if we were to use an axe instead (hopefully the back end of it), not much in RTP would change. > > The place for the RTP discussion is probably not in RTCWEB (more like > AVTCORE). > > I think we've already done most of the discussion needed in AVTCORE - we seem to have the dictum of "don't send audio and video on the same 5-tuple" changed to "if you send audio and video on the same 5-tuple, here's what you need to consider", which was really the only critical *change* I saw in RTP-land. > --------------080302090407080003090203 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 05/08/2013 01:07 AM, Bernard Aboba wrote:
Roni said:
"If the purpose of this draft and Adam’s one are to describe how to do things in RTCweb it should be discussed in RTCWEB. And we will need a similar one in CLUE probably in draft-ietf-clue-rtp-mapping."

[BA] There are RTP issues to discuss (e.g. draft-ietf-clue-rtp-mapping relationship to draft-ietf-rtcweb-rtp-usage), and there are SDP issues.  To date, I believe we have somewhat neglected the RTP discussion, which is unfortunate, because if all the time is spent talking about the SDP Hammer, then the inclination is to use it to pound every nail, and if there is no SDP, then we have no tools at all.

I felt that the discussion of draft-ietf-rtcweb-rtp-usage was largely uncontroversial in the Stockholm interim, and that not much further discussion of that level of the stack was needed - so I have not been worrying much about it after that.

It's more like we've got the RTP nail in place, and are hammering on it with the SDP hammer... if we were to use an axe instead (hopefully the back end of it), not much in RTP would change.


The place for the RTP discussion is probably not in RTCWEB (more like AVTCORE).


I think we've already done most of the discussion needed in AVTCORE - we seem to have the dictum of "don't send audio and video on the same 5-tuple" changed to "if you send audio and video on the same 5-tuple, here's what you need to consider", which was really the only critical *change* I saw in RTP-land.


 


--------------080302090407080003090203-- From andrew.hutton@siemens-enterprise.com Wed May 8 05:24:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21A421F9253 for ; Wed, 8 May 2013 05:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK5io94XoZZM for ; Wed, 8 May 2013 05:24:17 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7F36621F9223 for ; Wed, 8 May 2013 05:24:15 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 4B1B61EB84FF; Wed, 8 May 2013 14:24:14 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Wed, 8 May 2013 14:24:14 +0200 From: "Hutton, Andrew" To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? Thread-Index: AQHOS1HVryzI/aQNT0iUvXy00zH5h5j5+ICAgAElEYA= Date: Wed, 8 May 2013 12:24:13 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1158FF3E@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se>, <517FFB7E.8050801@alum.mit.edu>, , <51801BBD.1010505@alum.mit.edu>, , , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se>, <201305030115.r431Fis33999826@shell01.TheWorld.com> <201305061800.r46I0jM84247693@shell01.TheWorld.com> <518949B4.9060601@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36CCA8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36CCA8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 12:24:34 -0000 Whilst I agree that BUNDLE should not assume ICE is used as Christer stated= we do need to show how it is used with ICE. The interaction between ICE and Bundle is a potential problem and looks qui= te messy to me given the multitude of transport addresses that might be con= tained in the various candidates relating to the different candidate type, = components, and rel-addr/port. The meaning/relevance of all these addresses= when bundle is used needs to be explained. My initial feeling was that we should include something in the candidate it= self to make it clear what transport address is relevant if bundle is used = but so far I have not had much feedback and I am not sure whether it makes = things worse or better. Regards Andy > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: 07 May 2013 20:23 > To: Paul Kyzivat; mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? >=20 > Hi, >=20 > >I'd just like to point out that AFAIK bundling doesn't *require* ICE. > >So lets not make any assumptions that assume ICE is used. >=20 > Agree. >=20 > We do need to describe how ICE is used with BUNDLE, but BUNDLE can also > be used without ICE. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > On 5/6/13 2:00 PM, Dale R. Worley wrote: > >> From: Bernard Aboba > >> > >>> But it doesn't seem that there is much to gain by mandating rtcp- > mux > >>> in the first offer/answer, the one where actual bundling is not > >>> being done. All of the RTP/RTCP routing code that is active at > that > >>> point has to support non-rtcp-mux operation already. > >> > >> [BA] Support for rtcp-mux in the first offer/answer is mandated by > >> RFC 5761 Section 5.1.3: > >> The initial SDP offer MUST include this > >> attribute at the media level to request multiplexing of RTP and > RTCP > >> on a single port. > > > > I don't see how 5761 mandates that a=3Drtcp-mux MUST be used in the > > first offer of a bundle negotiation. The context of your quote is: > > > > 5.1.3. Interactions with ICE > > [...] > > If it is desired to use both ICE and multiplexed RTP and RTCP, > the > > initial offer MUST contain an "a=3Drtcp-mux" attribute to indicate > that > > RTP and RTCP multiplexing is desired and MUST contain > "a=3Dcandidate:" > > lines for both RTP and RTCP along with an "a=3Drtcp:" line > indicating a > > fallback port for RTCP in the case that the answerer does not > support > > RTP and RTCP multiplexing. This MUST be done for each media > where > > RTP and RTCP multiplexing is desired. > > > > That is, if the device desires to use both ICE and multiplex, it has > > to use a=3Drtcp-mux in the first offer of ICE's set of offers. But > > we're talking about bundling, which (in the current design) contains > > *two* ICE cycles, since the second offer (in the bundle spec) is > going > > to restart ICE. And the device need not "desire" to use "both ICE > and > > multiplexed RTP and RTCP" during the first of the ICE cycles. > > > > Dale > > _______________________________________________ > > 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 prvs=484031e1b9=stefan.lk.hakansson@ericsson.com Wed May 8 05:38:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39EA21F9352; Wed, 8 May 2013 05:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJCJ3QGfEzNc; Wed, 8 May 2013 05:38:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB2D21F8F0A; Wed, 8 May 2013 05:38:38 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-6d-518a474cb831 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C6.3D.32006.C474A815; Wed, 8 May 2013 14:38:37 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 8 May 2013 14:38:36 +0200 Message-ID: <518A474C.5020200@ericsson.com> Date: Wed, 8 May 2013 14:38:36 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtcweb@ietf.org, mmusic@ietf.org References: <51894846.3090102@nostrum.com> In-Reply-To: <51894846.3090102@nostrum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvra6ve1egwacZZhZTlz9msVj7r53d gcljyZKfTAGMUdw2SYklZcGZ6Xn6dgncGU2TbzAXfOev+PV7E0sDYwNvFyMnh4SAiUTT+/9M ELaYxIV769lAbCGBU4wSa2fkdzFyAdlrGCV+XvkDVsQroC2x9cRksCIWARWJr8uus4LYbAKB Etf//wKrERWIkvj3djcjRL2gxMmZT1hAbBGg+tn3TwDFOTiEgezDl8sgdmlJrP/1AKyEE2j8 vUVrmEFsZgFbiQtzrrNA2PIS29/OYYao15V49/oe6wRGgVlINsxC0jILScsCRuZVjOy5iZk5 6eVGmxiBAXdwy2/VHYx3zokcYpTmYFES503magwUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwQki uKQaGG3Tjkxf6XDK9uNzvchDIvol6zz/5K1yfqbU0qx1n6Fd9/azjP2Fq2N+CiUI5RzN6Deq ZThvZFMuc2f1V6O0piNlNj+rzQ/d/tfrNGume/XJTu6Fs3RzLi0/97t+j/6z4xfD1vm+7JHj 4XRe9OTqyvkC6wL09100nibN9d/Lc8maheseHlrzlEOJpTgj0VCLuag4EQA+6+CyCwIAAA== Subject: Re: [MMUSIC] [rtcweb] Plan A, respun X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 12:38:45 -0000 A couple of questions (and sorry for the rtcweb/webrtc centric perspective) for clarification: * How would the info about PC-track and PC-stream id's be conveyed (I assume the msid draft)? * What is your thinking regarding mapping between PC-tracks and m-lines? For example, if Alice's app initiates a session with two video PC-track's flowing to Bob's app, that would presumable create a session with two sendonly m-lines. If, at a later stage, Bob's app upgrades the session by sending three video PC-tracks to Alice's app. How would the Bob -> Alice video PC-tracks be allocated to the existing m-lines (becoming sendrecv), and how would pick which one to use a new m-line? E.g., would it be random, or should the app decide, and based on what in that case? Stefan On 2013-05-07 20:30, Adam Roach wrote: > In order to facilitate discussion between the two SDP format > alternatives we're considering, I've put together a document that more > clearly spells out the Plan A approach as we originally envisioned it. > Note that this is a slightly different approach than Cullen outlined in > Orlando. I fear the Orlando approach may have suffered from its attempts > to incorporate some elements of Plan B in an attempt to appease > proponents of that approach; and, in doing so, lost some of its clean > architecture. > > The cleaned up, new-and-improved description of the Plan A approach is > available here: > > http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt > > Note that we've omitted discussion of glare reduction from that > document, as I believe that mid-session glare can be completely avoided > by applications implementing a set of non-normative behaviors. These > behaviors are described in the a separate companion document: > > http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt > > Thanks. > > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Wed May 8 08:43:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0F21F9380; Wed, 8 May 2013 08:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.949 X-Spam-Level: X-Spam-Status: No, score=-6.949 tagged_above=-999 required=5 tests=[AWL=-3.650, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5MRfIy8gC5a; Wed, 8 May 2013 08:43:22 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 121B021F8FE9; Wed, 8 May 2013 08:43:21 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id w20so2070151lbh.6 for ; Wed, 08 May 2013 08:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=N9ihVS0ZXB0UU37MQNXmnVfu26qNip0AT4Tt2ltMEq8=; b=hNpPGfFzeXZp0IHUD6v/hhIVQj0NnnQ0n1YO9eRgSABBMYQcSf+iQrQcDHy1anqCK+ 61h7Q+jR6SfM7Ed7Mk++CsbEX0O6jml08nGQo1EOoO4dIqQof4CaLA8JJNlIDNZ/6sVW izXmivgeaXfrJmc2sSyL41rPYLpnazlfwfCYBeSFqZyuA41RarxWBB0JjvBlkqxIHSkH aTrKn6cMHGDkR+eTHULbryfqQ20esZ98g2cIxZSqAJntL0tn9Js+eZ4rhHElHcwZ45hk ZEs6eI/snrJIZZXl6zpZWpCR2Y5G47NtCp3gqEVcrTJR6paB2msl54/WCP31vgUhFOvQ gZpA== MIME-Version: 1.0 X-Received: by 10.152.5.37 with SMTP id p5mr3498669lap.13.1368027800947; Wed, 08 May 2013 08:43:20 -0700 (PDT) Received: by 10.112.159.138 with HTTP; Wed, 8 May 2013 08:43:20 -0700 (PDT) In-Reply-To: <518A474C.5020200@ericsson.com> References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> Date: Wed, 8 May 2013 08:43:20 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Plan A, respun X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:43:27 -0000 On 8 May 2013 05:38, Stefan H=C3=A5kansson LK wrote: > A couple of questions (and sorry for the rtcweb/webrtc centric perspectiv= e) > for clarification: > > * How would the info about PC-track and PC-stream id's be conveyed (I ass= ume > the msid draft)? Yes, that's a solved problem. No sense reiterating it in the draft (it's orthogonal to what the draft actually addresses). > * What is your thinking regarding mapping between PC-tracks and m-lines? = For > example, if Alice's app initiates a session with two video PC-track's > flowing to Bob's app, that would presumable create a session with two > sendonly m-lines. If, at a later stage, Bob's app upgrades the session by > sending three video PC-tracks to Alice's app. How would the Bob -> Alice > video PC-tracks be allocated to the existing m-lines (becoming sendrecv), > and how would pick which one to use a new m-line? E.g., would it be rando= m, > or should the app decide, and based on what in that case? Alice's offer would contain at least two m-lines. Those would not necessarily be sendonly. If she was capable of receiving more than 2 inbound, the offer could contain recvonly lines too (I believe that this fits with the OfferToReceiveVideo=3Dn constraint). Of course, if those lines were not compatible with what Bob wanted to send (too much, different codecs, different constraints, etc...), then Bob is required to send another offer to get his media out. From fandreas@cisco.com Wed May 8 13:38:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8515621F8F4F for ; Wed, 8 May 2013 13:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLxYC9FBUcMr for ; Wed, 8 May 2013 13:38:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CD49721F8D6A for ; Wed, 8 May 2013 13:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7291; q=dns/txt; s=iport; t=1368045500; x=1369255100; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=y3GJw3aNHixJH6vkiENXsI+zSTXKyMXCtue2g63N4hM=; b=SU+qswQTga/esialZmaZmIgG3ovO7Jrg8xNqjCwBCQTe7X3gc/vujFcb yNbVHwJAlJFoavydW+ENEupZY2EwfWd+Tct7Mf0WvkUjIglXDAbjnR+Qg qx10cmWgafu83rH+AKSuwc7S0FG7G584dHnrSuq1fvB87ohtNlsL9rYaJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FANa1ilGtJXG9/2dsb2JhbABSgwc3vxd6FnSCHwEBAQQ4QAEMBBwEAQEBCRYEBAcJAwIBAgE0CQgTAQUCAQEXh3EMwWCPKAcGg08DlyyBJpAPgVeBVCA X-IronPort-AV: E=Sophos;i="4.87,636,1363132800"; d="scan'208";a="208054605" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 08 May 2013 20:38:20 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r48KcJhf009840; Wed, 8 May 2013 20:38:19 GMT Message-ID: <518AB7BB.3090105@cisco.com> Date: Wed, 08 May 2013 16:38:19 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <514FA8F7.7060203@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> <5168A94B.20608@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> <516EB28A.1050003@cisco.com> <517956CB.2040701@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jonathan@vidyo.com, christer.holmberg@ericsson.com Subject: [MMUSIC] Last chance to comment: Re: Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 20:38:25 -0000 As there has been no further comments on the proposed text or the subsequently updated draft, we conclude that all issues have been resolved at this point. In the absence of any objections by the end of this week (May 12), we will proceed with the publication request of the -05 version of the draft. Thanks -- Flemming (MMUSIC co-chair) On 5/3/13 3:29 AM, Simo.Veikkolainen@nokia.com wrote: > I didn't find any additional comments on this, so I went ahead and changed the paragraphs according to Flemming's proposal and submitted a new version. > > Regards, > Simo > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Veikkolainen Simo (Nokia-CTO/Espoo) > Sent: 26. huhtikuuta 2013 12:22 > To: fandreas@cisco.com > Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com > Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > See below [SV]. > > -----Original Message----- > From: ext Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: 25. huhtikuuta 2013 19:16 > To: Veikkolainen Simo (Nokia-CTO/Espoo) > Cc: mohamed.boucadair@orange.com; aallen@blackberry.com; HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com > Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > > On 4/23/13 4:37 AM, Simo.Veikkolainen@nokia.com wrote: >> Below the original and proposed text on the usage of ccap attribute in >> Section 3.1.2. of >> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 >> >> This is pretty much the same text I proposed earlier, including Jonathan's wording on IN address families. >> >> --- begin original text --- >> The 'ccap' capability attribute allows for expressing alternative >> connection address ('c=') lines in SDP as part of the SDP capability >> negotiation process. The 'ccap' capability attribute is intended to >> be used only when there is no other mechanism available for >> negotiating alternative connection address information, such as when >> the is different among the alternative addresses (e.g. >> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >> situations where an existing mechanism (such as Interactive >> Connectivity Establishment (ICE) [RFC5245]) can be used to select >> between different connection addresses (e.g. "IP4" and "IP6" or >> different IP addresses within the same IP address family). >> --- end original text --- >> >> --- begin proposed text --- >> The 'ccap' capability attribute is intended for offering >> alternative connection addresses where the >> is "IN" or "PSTN", i.e. selecting between an IP based >> bearer or a circuit-switched bearer. >> >> The 'ccap' attribute MUST NOT be used to indicate more >> than one address with an IN network type in actual >> or potential configurations for any given media description >> (e.g. between "IP4" and "IP6" address families or different >> IP addresses within the same IP address family). >> --- end proposed text--- > I'm ok with the overall restriction but I think the opening wording is overly constraining. With that in mind, a slightly modified proposal below: > > > The 'ccap' capability attribute allows for expressing alternative > connection address ('c=') lines in SDP as part of the SDP capability > negotiation process. One of the primary use cases for this is offering > alternative connection addresses where the > is "IN" or "PSTN", i.e., selecting between an IP based > bearer or a circuit-switched bearer. > > By supporting the "IN" , the 'ccap' attribute enables the signaling of multiple IPv4 and IPv6 addresses, however the Standards Track mechanism for negotiation of alternative IP addresses in SDP is Interactive Connectivity Establishment (ICE) [RFC5245]. The 'ccap' attribute does not change that and hence the combined set of actual and potential configurations (as defined in [RFC5939]) for any given media description MUST NOT use the 'ccap' attribute to negotiate more than one address with an IN network type (i.e., it is not permissible to select between "IP4" and "IP6" address families or different IP addresses within the same IP address family). > > > > [SV] I think your proposal makes the intent clearer; I'll edit the text accordingly. > > Simo > >> Also, since no alternative port numbers can be offered, add this sentence at the end the of the last paragraph to clarify how alternative IP and PSTN media descriptions are offered: >> >> This document does not define any mechanism for negotiating or >> describing different port numbers and hence the port number from the >> "m=" line MUST be used by default. Exceptions to this default can be >> provided by extension mechanisms or network type specific rules. >> This draft defines an exception when the network type is "PSTN", in >> which case the port number is replaced with 9 (the "discard" port) as >> described in Session Decription Protocol (SDP) Extension For Setting >> Up Audio and Video Media Streams over Circuit-Switched Bearers in the >> Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs]. >> --- begin new text --- >> An endpoint offering alternative IP and PSTN bearers MUST include the >> IP media description in the actual configuration (IP address in the "c=" line >> and port number in the "m=" line), and the PSTN media descriptions in the >> potential configuration. >> --- end new text --- > Looks good. > > Thanks > > -- Flemming > >> Regards, >> Simo >> >> >> -----Original Message----- >> From: ext Flemming Andreasen [mailto:fandreas@cisco.com] >> Sent: 17. huhtikuuta 2013 17:33 >> To: mohamed.boucadair@orange.com >> Cc: Veikkolainen Simo (Nokia-CTO/Espoo); aallen@blackberry.com; >> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; >> christer.holmberg@ericsson.com >> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and >> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >> >> >> On 4/17/13 7:08 AM, mohamed.boucadair@orange.com wrote: >>> Hi Felmming, >>> >>> Because it does not allow to indicate an alternate port number. >> Correct - a connection address does not provide a port number; a different capability would be needed for that. >>> This makes it a no working solution for various scenarios. >> No - it simply means that you would need to define another capability to convey port numbers if you wanted such a solution (however we have ICE as the complete solution for that and the WG has not indicated a desire to change that). >> >>> The text which triggered this discussion was confusing. I hope the updated version will be much more clear and reflect what have been discussion so far in this thread. >> I have asked Simo to update the draft. >> >> Thanks >> >> -- Flemming >> >> >>> Cheers, >>> Med >>> From fandreas@cisco.com Wed May 8 18:57:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB0E21F8E77; Wed, 8 May 2013 18:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7ACThsSW0bQ; Wed, 8 May 2013 18:57:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 73A6821F8E6D; Wed, 8 May 2013 18:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1169; q=dns/txt; s=iport; t=1368064658; x=1369274258; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=I5YiKPod+9kpwq2qE00oe3OVGPRiRIgnTGfz+2/rKDo=; b=YlycQq4jftjIRuxBRZXt8J3rvGFRZd26Pk3rr/6J3evXFIFNiZUQiR5l mnI7AdtASnOf0nWwN04+BmHFDf0VkfG7xd/9Ho9P0Bc8fq44BZHsyocez nihgLjctGcq9FNm3UosT/qJm/EA7ikJXcbIYNV1NbdO/AFh9hni/N9kOK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAHwBi1GtJXG9/2dsb2JhbABSgwc3vzB7FnSCXkABPBYYAwIBAgFLDQEHAQEFiAMMwTSPKINcA5cskTWDKyA X-IronPort-AV: E=Sophos;i="4.87,638,1363132800"; d="scan'208";a="208146053" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 09 May 2013 01:57:37 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r491vaa1005747; Thu, 9 May 2013 01:57:37 GMT Message-ID: <518B0290.1070509@cisco.com> Date: Wed, 08 May 2013 21:57:36 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rai-ads , IESG Secretary Subject: [MMUSIC] MMUSIC Virtual Interim Meeting Announcement for May 23, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 01:57:43 -0000 Greetings This is to announce a virtual interim meeting for the MMUSIC Working Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari & Flemming (MMUSIC co-chairs) PS: We are currently also considering having a physical interim meeting the week of June 24th, likely on the US West Coast. We will await the outcome of the virtual interim meeting before making a decision on this but wanted to give people a heads-up for now. From stefan.lk.hakansson@ericsson.com Thu May 9 04:41:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6139B21F8E6B; Thu, 9 May 2013 04:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVI5uTR8ocOm; Thu, 9 May 2013 04:41:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7705B21F8E51; Thu, 9 May 2013 04:41:49 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-dc-518b8b7bb3d3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CF.B1.28165.B7B8B815; Thu, 9 May 2013 13:41:48 +0200 (CEST) Received: from [153.88.16.182] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 9 May 2013 13:41:47 +0200 Message-ID: <518B8B7A.3050509@ericsson.com> Date: Thu, 9 May 2013 13:41:46 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGfG3VremuzvQ4PFrDotrZ/4xWkxd/pjF Yu2/dnYHZo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PQ1yPMBZcFK770vmVqYJzC18XI ySEhYCKx899hVghbTOLCvfVsXYxcHEICpxgl1h9eyAjhrGKUWHDrOhtIFa+AtsSxX/uZQGwW ARWJC+fWMoPYbALBEvuXrwerERWIkvj3djcjRL2gxMmZT1hAbBEBXYlFZx+wg9jMAv4S567s B6rh4BAGmnP4chnErn5GiUW/L7KDxDkFAiVeL3KBKLeQWPzmIFSrvETz1tlga4WARr57fY91 AqPgLCTbZiFpmYWkZQEj8ypG9tzEzJz0csNNjMDgPLjlt+4OxlPnRA4xSnOwKInzJnE1BgoJ pCeWpGanphakFsUXleakFh9iZOLglGpglOPTKpzzKzD58/w0UxXxc9ZrI40mHtwtL673NkSv d7Pbm/98qkmVqzlcX2ubhPoc1lSZ61CuK3REg+tNJuujucLbmDScuaObD63IXiD1fjnLf8ZH +adNZrOJvsmal34nKShLr9Vhs6dm1tuNi+fNaFHQcTrns3+v6YuyTVoTGVyZF/d8MbJVYinO SDTUYi4qTgQAoHP9ChwCAAA= Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Plan A, respun X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 11:41:56 -0000 On 2013-05-08 17:43, Martin Thomson wrote: > On 8 May 2013 05:38, Stefan HÃ¥kansson LK > wrote: >> A couple of questions (and sorry for the rtcweb/webrtc centric perspective) >> for clarification: >> >> * How would the info about PC-track and PC-stream id's be conveyed (I assume >> the msid draft)? > > Yes, that's a solved problem. No sense reiterating it in the draft > (it's orthogonal to what the draft actually addresses). Right, just wanted it clarified. > >> * What is your thinking regarding mapping between PC-tracks and m-lines? For >> example, if Alice's app initiates a session with two video PC-track's >> flowing to Bob's app, that would presumable create a session with two >> sendonly m-lines. If, at a later stage, Bob's app upgrades the session by >> sending three video PC-tracks to Alice's app. How would the Bob -> Alice >> video PC-tracks be allocated to the existing m-lines (becoming sendrecv), >> and how would pick which one to use a new m-line? E.g., would it be random, >> or should the app decide, and based on what in that case? > > Alice's offer would contain at least two m-lines. Those would not > necessarily be sendonly. If she was capable of receiving more than 2 > inbound, the offer could contain recvonly lines too (I believe that > this fits with the OfferToReceiveVideo=n constraint). OK. So if Alice's app used OfferToReceiveVideo=0, then both m-lines would be sendonly, 1 would give one sendrecv and one sendonly and so on. So, if OfferToReceiveVideo=0 was used (or was even the default), we would in the case of a symmetric service (Alices's and Bob's apps intending to send the same amount of audio and video tracks, and doing it from the start of the session) actually end up with the same 3-way handshake as in Plan B (since sendonly/recvonly can't be upgraded to sendrecv without a new offer)? (I have no problem with that behavior, I just want to understand) > Of course, if > those lines were not compatible with what Bob wanted to send (too > much, different codecs, different constraints, etc...), then Bob is > required to send another offer to get his media out. ...because new m-lines are required. > From fluffy@cisco.com Thu May 9 07:34:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3959521F8FDB for ; Thu, 9 May 2013 07:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d19uVBC0FWGf for ; Thu, 9 May 2013 07:34:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA4721F8F53 for ; Thu, 9 May 2013 07:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1130; q=dns/txt; s=iport; t=1368110034; x=1369319634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VWo4XsAXpLcNmby6lIiIiOs3nYtNAxiGIEPctS0pAXA=; b=EaXRo9eKnAveDV2ZA8FjCkm8abBhQrveF/4rDNxSDcKi203uzPATbXGN 8katdhX3F/dO45udxLgkhU1eJZvGNN2PNAb5n4pOi5HdGFkm1xcjDikOz DqMdzFZW7X55K0aV89F27peQj2crkBXqlF54aHdeTroSzSCBiozocLDcg Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAMGyi1GtJXHB/2dsb2JhbABSgwc3rW6SGHoWdIIfAQEBAwEBAQFrCwULAgEIEQMBAgskJwsdCAIEDgUIAYdxAwkFAQy9UIxICoIjAjEHgnRhA4hijGeNdoUigw+CJw X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208331064" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 09 May 2013 14:33:53 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r49EXrQB007852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 14:33:53 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 9 May 2013 09:33:53 -0500 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? Thread-Index: AQHOTMI6HitSLbIiHUe96QE8QukVTQ== Date: Thu, 9 May 2013 14:33:52 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C368E12@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: [171.68.20.68] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:34:05 -0000 +1=20 On Apr 30, 2013, at 8:21 AM, Bernard Aboba wrot= e: > No objection here to requiring rtcp-mux with BUNDLE. Implementations no= t supporting rtcp-mux probably don't support BUNDLE either. =20 >=20 > From: christer.holmberg@ericsson.com > To: mmusic@ietf.org > Date: Tue, 30 Apr 2013 13:26:35 +0000 > Subject: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? >=20 > Hi, > =20 > As currently indicated in BUNDLE, and SDP offer for RTP must contain an r= tcp-mux attribute, indicating support of RTP/RTCP multiplexing. > =20 > However, it is currently optional to include it in the SDP answer. > =20 > There has been some discussions on whether we should MANDATE the usage of= rtcp-mux whenever BUNDLE is enabled. > =20 > Would anyone OBJECT to that? > =20 > Regards, > =20 > Christer >=20 > _______________________________________________ mmusic mailing list mmusi= c@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Thu May 9 07:52:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD40E21F8F53 for ; Thu, 9 May 2013 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkleOjdsi1Cc for ; Thu, 9 May 2013 07:52:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0070F21F8EAC for ; Thu, 9 May 2013 07:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40856; q=dns/txt; s=iport; t=1368111141; x=1369320741; h=message-id:date:from:mime-version:to:cc:subject; bh=M0xBs7mDcldGXx0Si+X1f/rJCjqPDDM3zK9nGZnWMh8=; b=SkR2aszkGnNCtAGWq3WJ0X4PO22Io79ujvF000J15VaIGjk4DylvbSCz Nx4YGxmHzuL7oT5RuqBQYbBzsUoXSKfl932z8racLinFXs8LGpKzpnP5L dQbfBEnwgG2e7idryLI8RQUuwe79PD67mtY3RNS33wHYx23WQdM8I+rdR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMGAG+3i1GtJXG+/2dsb2JhbABSgwc3RIhWtmx6FnSCQ1sBPBYBARYDAgECAUsNAQcBAQWIAwcFvVOPKINcA5csgSaQD4MrIA X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208,217";a="208392959" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 09 May 2013 14:52:20 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r49EqJw2018295; Thu, 9 May 2013 14:52:19 GMT Message-ID: <518BB81A.8090608@cisco.com> Date: Thu, 09 May 2013 10:52:10 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------080503040603060200050000" Cc: draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:52:26 -0000 This is a multi-part message in MIME format. --------------080503040603060200050000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We previously had a 2 week WGLC on the rtsp-nat-evaluation draft which resulted in several updates to the draft. The resulting -06 has been out for review without any additional comments for quite some time now. Based on that, we are announcing a 1 week Working Group Last Call for draft-ietf-mmusic-rtsp-nat-evaluation-06 as Informational. Please review and provide any comments you may have on the document by May 16, 2013. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks Flemming Draft Info: 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) Author(s) : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-06.txt Pages : 41 Date : 2012-11-23 Abstract: This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description on 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 relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0. 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-06 --------------080503040603060200050000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We previously had a 2 week WGLC on the rtsp-nat-evaluation draft which resulted in several updates to the draft. The resulting -06 has been out for review without any additional comments for quite some time now. Based on that, we are announcing a 1 week Working Group Last Call for

    draft-ietf-mmusic-rtsp-nat-evaluation-06

as Informational. Please review and provide any comments you may have on the document by May 16, 2013. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.

Thanks

       Flemming


Draft Info: 

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)
	Author(s)       : Magnus Westerlund
                          Thomas Zeng
	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-06.txt
	Pages           : 41
	Date            : 2012-11-23

Abstract:
   This document describes several Network Address Translator (NAT)
   traversal techniques that were considered to be used for establishing
   the RTP media flows controlled by the Real-time Streaming Protocol
   (RTSP).  Each technique includes a description on 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 relates to firewalls and how each technique can
   be applied in different use cases.  These findings where used when
   selecting the NAT traversal for RTSP 2.0.


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-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-06

--------------080503040603060200050000-- From martin.thomson@gmail.com Thu May 9 08:45:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411D621F85CB; Thu, 9 May 2013 08:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeoG4iK3Zqth; Thu, 9 May 2013 08:45:48 -0700 (PDT) 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 6B45721F85BF; Thu, 9 May 2013 08:45:48 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w60so3168008wes.3 for ; Thu, 09 May 2013 08:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ukWSpKbf6MM2KQxhC7ZTnjmZ76kgr2Ey1KEPLeOf19o=; b=la5YERbAM26xEtVQZKJ4C4tCrqu6ZTKrmBs5swxfDHKsswvBSkB654zwmTCh+2WCvN FJFNKHspVC03cWcogZEByw5N/sW+4GKLb4UHb80pSEZ/f0gPrX6veheIJJL1vjulY+I1 i1j/Hg0iMbzZmJZJ9GOMNN/L7jtbnKAwk0JE0h7L406UhqpUrMNefh8+d+Fx4g3BC76U exI7dpPEF+mD5rU7WiiYK2+BKCaowFEjMrxNBHcXWr76NCJ6tUjtBHiyBtt0BszgmAaO qQ1GWZ3iR/J2E/7Z06Ru37AMZ9hP/ngFL+N/rEvSJSvNi4hlG+jqSF2jfERbnJhO8CvN Umtg== MIME-Version: 1.0 X-Received: by 10.194.61.10 with SMTP id l10mr18964247wjr.32.1368114347411; Thu, 09 May 2013 08:45:47 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Thu, 9 May 2013 08:45:47 -0700 (PDT) In-Reply-To: <518B8B7A.3050509@ericsson.com> References: <51894846.3090102@nostrum.com> <518A474C.5020200@ericsson.com> <518B8B7A.3050509@ericsson.com> Date: Thu, 9 May 2013 08:45:47 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Plan A, respun X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:45:49 -0000 On 9 May 2013 04:41, Stefan H=C3=A5kansson LK wrote: >> Alice's offer would contain at least two m-lines. Those would not >> necessarily be sendonly. If she was capable of receiving more than 2 >> inbound, the offer could contain recvonly lines too (I believe that >> this fits with the OfferToReceiveVideo=3Dn constraint). > > > OK. So if Alice's app used OfferToReceiveVideo=3D0, then both m-lines wou= ld be > sendonly, 1 would give one sendrecv and one sendonly and so on. > > So, if OfferToReceiveVideo=3D0 was used (or was even the default), we wou= ld in > the case of a symmetric service (Alices's and Bob's apps intending to sen= d > the same amount of audio and video tracks, and doing it from the start of > the session) actually end up with the same 3-way handshake as in Plan B > (since sendonly/recvonly can't be upgraded to sendrecv without a new offe= r)? > > (I have no problem with that behavior, I just want to understand) I think that you have it understood. >> Of course, if >> those lines were not compatible with what Bob wanted to send (too >> much, different codecs, different constraints, etc...), then Bob is >> required to send another offer to get his media out. > > > ...because new m-lines are required. Yep. From fluffy@cisco.com Thu May 9 08:49:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A2121F9305; Thu, 9 May 2013 08:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmyTl50THxJ5; Thu, 9 May 2013 08:49:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C737F21F90F1; Thu, 9 May 2013 08:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=557; q=dns/txt; s=iport; t=1368114587; x=1369324187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z+9lviSorJsEo7S5ZmyVnkCoNr0nEc1cJYjzM4+bxqE=; b=mWsuhH/nV7qFGLBZSKgbKhq8eL9XngCtsggxMxqpQnyPQDESaf5F8Jfg sJABIcR4aJitZkCZN+rJXVQvfDQfG4nEiH7HlOe8sbY2zBs5Zjk0zk8OV eM68vlKCPQKMS+M0vM7M3AXoglNC6XKapvAG2yDVZqNa5NrxfpQdCbzmb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAOHEi1GtJXHA/2dsb2JhbABSgweDLL0SehZ0gh8BAQEDATouDwIFCwIBCA4UFBAyJQIEDgUIh34FAb17jnUCMQeCdGEDqGGDD4In X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208388537" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 09 May 2013 15:49:46 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r49FnkkX029273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 15:49:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 9 May 2013 10:49:45 -0500 From: "Cullen Jennings (fluffy)" To: Justin Uberti Thread-Topic: [MMUSIC] New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOTMzUZ6qA2ycCEU+xahGCAxHFJg== Date: Thu, 9 May 2013 15:49:45 +0000 Message-ID: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FE03FE977CBB546B4A57423082B5009@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:49:52 -0000 On May 2, 2013, at 11:08 PM, Justin Uberti wrote: > Scribbled down the basic concepts of what I have been referring to as "Pl= an B" - a way to signal multiple MediaStreamTracks in SDP without needing a= separate m=3D line for each. >=20 > Hopefully this will make discussion of this topic easier. I think my largest questions was does an endpoint have to know when it care= ts an offer if that is going to be sent to a legacy end point or not. I'm p= articularly interested in multiscreen video conferences systems.=20 From fluffy@cisco.com Thu May 9 08:55:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10BF21F8651; Thu, 9 May 2013 08:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngHOuV1qCxRQ; Thu, 9 May 2013 08:55:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C219421F85E8; Thu, 9 May 2013 08:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2166; q=dns/txt; s=iport; t=1368114947; x=1369324547; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=x8zslPkmsuXnk0Tx6gT5XTo1DLjXW/+ywzfkF7er9Gs=; b=QDWWea99FVlmhsV9P608/VF3SOVHHFW8Vy7E+4krUvKpDSOXwG6RZURA OCDnrDOZ1n7bM8e2e1ReLhapbMvtoOsjazNGvkHnHdSgDPjHsL0+Vj+UN vKrbmH/7+xenhIcXJP4VrMzFvvOmoD+37CnoNkr+fp6LYAhrWE198OH+g A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAH7Gi1GtJV2Z/2dsb2JhbABSgwc3wAd6FnSCHwEBAQMBAQEBJEcLBQsCAQgiJCcLJQIEDgUIh34FAQy9egSOdQIxB4J0YQOoYYMPgic X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208407207" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 May 2013 15:55:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r49Ftk0k011974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 15:55:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 9 May 2013 10:55:45 -0500 From: "Cullen Jennings (fluffy)" To: "Mo Zanaty (mzanaty)" Thread-Topic: [MMUSIC] Is bundle just a port override? Thread-Index: AQHOTM2qLSobb9TZDkGuVuUzGWRiZA== Date: Thu, 9 May 2013 15:55:45 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.68] Content-Type: text/plain; charset="Windows-1252" Content-ID: <851923EC09F7454FBB300324ADEB3ACC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Is bundle just a port override? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:56:00 -0000 Mo,=20 I think the key part of the grouping was it gave a way to say which m-line = to use that still allowed that m-line to later be set to zero. I'm not sayi= ng the grouping adds much but keep in mind it is not really just the port y= ou are selecting. It's all the ICE transport stuff in the candidates so we= would have to more than just a=3Dport, you would also need the a=3Dbundle-= ice-candiaate and perhaps some DTLS info but I'm not sure. It seems somethi= ng like this could work. not sure it would change too much.=20 my 2 cents.. On Mar 18, 2013, at 9:19 PM, Mo Zanaty (mzanaty) wrote: > Does bundle imply anything beyond a simple port override of the m-line po= rt? If not, then why not just directly signal the port override in an attri= bute without any grouping semantics? > =20 > Offer to mux audio and video on the same port: > m=3Daudio 10000 RTP/AVP 0 > m=3Dvideo 10002 RTP/AVP 31 > a=3Dport 10000 > i=3DI really want 10000, but lied on the m-line for fear of confusing you= . Confused yet? > =20 > Answer supports the port override attribute and agrees to mux audio and v= ideo: > m=3Daudio 40000 RTP/AVP 0 > m=3Dvideo 40000 RTP/AVP 31 > a=3Dport 40000 > =85so audio and video ports are 10000<->40000. > =20 > Answer supports the port override attribute but doesn=92t want to demux o= n his end: > m=3Daudio 40000 RTP/AVP 0 > m=3Dvideo 40002 RTP/AVP 31 > a=3Dport 40002 > =85so audio ports are 10000<->40000 and video ports are 10000<->40002. > =20 > Answer doesn=92t support the port override attribute, or doesn=92t want e= ither end to mux: > m=3Daudio 40000 RTP/AVP 0 > m=3Dvideo 40002 RTP/AVP 31 > =85so audio ports are 10000<->40000 and video ports are 10002<->40002. > =20 > Either end can re-offer without lies about ports on the m-line after conf= irming the peer is not confused by muxing, if they want to avoid confusing = intermediaries. > =20 > Has this approach been tried yet? Dismissed? > =20 > Mo > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Thu May 9 08:56:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BBD21F941D; Thu, 9 May 2013 08:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0I2pczsw4XX; Thu, 9 May 2013 08:56:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D857821F8FB6; Thu, 9 May 2013 08:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=457; q=dns/txt; s=iport; t=1368114978; x=1369324578; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sH+Ra7Www1YXksbNBBmytqz/ao9hiDn7iPUCdnqxmr0=; b=Ai2/xqiL9gBTZ+LtYwONb9Qw50huDrBi2bKQKDjFJNBPiHsQjmmo3EnJ U3eOkjFihGWMCWgCtbQT2YcNhcFK+Xtfal3wqC329Swmbn2X2pDOJRGdA G0xwiw7LI0TPHhF7u/mgBS56KbyKqHiNwjmfKQT2pgigamCgg2f4K5pmv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsFAN/Fi1GtJXG+/2dsb2JhbABSgweDLL0SehZ0gh8BAQEDATo/EAIBCBUNFBAyJQIEDgUIh34FAb4JjnUCMQeCdGEDqGGDD4In X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208483206" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 09 May 2013 15:56:05 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r49Fu5d9010339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 15:56:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 9 May 2013 10:56:05 -0500 From: "Cullen Jennings (fluffy)" To: "Dale R. Worley" Thread-Topic: [MMUSIC] [rtcweb] Is bundle just a port override? Thread-Index: AQHOTM21I5ApWExVKkWVb2vtaIzXwA== Date: Thu, 9 May 2013 15:56:04 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D90F695235@xmb-rcd-x14.cisco.com> <201303221928.r2MJSOvW960763@shell01.TheWorld.com> In-Reply-To: <201303221928.r2MJSOvW960763@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Is bundle just a port override? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:56:25 -0000 On Mar 22, 2013, at 12:28 PM, Dale R. Worley wrote: >> From: "Mo Zanaty (mzanaty)" >>=20 >> BTW, has anyone actually observed failures? >=20 > My memory is that Cullen Jennings knows of a significant installed > base of SBCs that choke on SDP that contains duplicated port > references. >=20 > Dale Some of them are using the port as the think to uniquely key into the activ= e data structures.=20 From iesg-secretary@ietf.org Thu May 9 11:02:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F271A21F91A3; Thu, 9 May 2013 11:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw7Qr7r05Yy9; Thu, 9 May 2013 11:02:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9186321F8EC7; Thu, 9 May 2013 11:02:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130509180236.18184.2703.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2013 11:02:36 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, May 23, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 18:02:37 -0000 Greetings This is to announce a virtual interim meeting for the MMUSIC Working Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=3D" lines or very few "m=3D" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari & Flemming (MMUSIC co-chairs) PS: We are currently also considering having a physical interim meeting the week of June 24th, likely on the US West Coast. We will await the outcome of the virtual interim meeting before making a decision on this but wanted to give people a heads-up for now. From andrew.hutton@siemens-enterprise.com Thu May 9 11:43:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C7121F914C; Thu, 9 May 2013 11:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_110=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn+2NU3HWcZj; Thu, 9 May 2013 11:43:12 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 021A521F90D2; Thu, 9 May 2013 11:43:11 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 9E09A1EB8534; Thu, 9 May 2013 20:43:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Thu, 9 May 2013 20:43:10 +0200 From: "Hutton, Andrew" To: "Cullen Jennings (fluffy)" , Justin Uberti Thread-Topic: [MMUSIC] New Version Notification for draft-uberti-rtcweb-plan-00.txt Thread-Index: AQHOTMzUZ6qA2ycCEU+xahGCAxHFJpj9LqVA Date: Thu, 9 May 2013 18:43:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF11591D10@MCHP04MSX.global-ad.net> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 18:43:17 -0000 ON: 09 May 2013 16:50 Cullen Jennings (fluffy) Wrote: >=20 > I think my largest questions was does an endpoint have to know when it > carets an offer if that is going to be sent to a legacy end point or > not. I'm particularly interested in multiscreen video conferences > systems. >=20 The same question also seems relevant to the respun plan A given that the t= emptation will be to use a=3Dbundleonly which greatly simplifies the offer = (i.e. less confusion over candidates etc.) but at the cost of interoperabil= ity with legacy multiscreen systems. Don't you agree? Andy=20 From stefan.lk.hakansson@ericsson.com Thu May 9 23:37:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2086E21F8E8F; Thu, 9 May 2013 23:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mh-tlfysoXo; Thu, 9 May 2013 23:37:24 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CB66121F8FA5; Thu, 9 May 2013 23:37:23 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-18-518c95a25c72 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EB.CE.01956.2A59C815; Fri, 10 May 2013 08:37:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 10 May 2013 08:37:22 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Adam Roach Thread-Topic: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 Thread-Index: AQHOS2hQZBBwa2OZtEiOSK4AxzMZ0w== Date: Fri, 10 May 2013 06:37:21 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.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+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre6iqT2BBmf2q1ns+buI3WLq8scs Fis2HGC1WPuvnd2BxePv+w9MHkuW/GTymLXzCUsAcxSXTUpqTmZZapG+XQJXxs3721gLevkq TnT+YWxgXMrdxcjJISFgInFm22kmCFtM4sK99WxdjFwcQgKHGSXWbF3ECOEsYZQ41viVEaSK TSBQYuu+BWwgtoiAokTb4ZvMIDazQInE25NHWEFsYQFviW0bFjJD1PhIrL95iB3C1pNo6d0C VsMioCrxZP5TsM28Ar4Sx9evgFq2gVHiysujYA2MQCd9P7WGCWKBuMStJ/OhThWQWLLnPDOE LSrx8vE/VghbSeLHhkssEPV6EjemTmGDsLUlli18zQyxTFDi5MwnLBMYRWchGTsLScssJC2z kLQsYGRZxciem5iZk15uvokRGC0Ht/w22MG46b7YIUZpDhYlcd5krsZAIYH0xJLU7NTUgtSi +KLSnNTiQ4xMHJxSDYyBDdzWXXkST/wm7+IX51LTLqt0COX1O79FZnZbjcGKmY2Mki1qPWUv c3Pqk9QevHs+cVFD3qu/k+cu3Z108ciLU4XfPpy89/BThPt3Z8WjnBIa6j8dGtYH7VELZeCI WFo0U91zu/N2heOPMgNk7mYoyjje5NWxvhLjv3dj2n5bEX8VI0GXhUosxRmJhlrMRcWJAC0x PJtkAgAA Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 06:37:44 -0000 On 5/8/13 11:19 PM, Adam Roach wrote:=0A= > On 5/8/13 15:07, Paul Kyzivat wrote:=0A= =0A= >> I remain dubious that this glare situation is a problem that needs to=0A= >> be fixed.=0A= >=0A= > So am I, but Justin seems to be obsessed with it. That's why I'm=0A= > proposing a non-normative recipe that allows people who are=0A= > unnecessarily preoccupied with the issue to indulge their peccadillos.=0A= > The rest of us are free to ignore it.=0A= =0A= I think that glare coming from simultaneous add or remove of media may =0A= not be that common.=0A= =0A= But I can easily think of other situations that would lead to glare for =0A= Plan A.=0A= =0A= Just as an example, think about a conference scenario with a centralized = =0A= node. Now, one of the participants wants to mute her/his audio, and as a = =0A= result the audio m-line would go from sendrecv to recvonly. At roughly =0A= the same time the server wants to disable the high res video and enable =0A= the low res video (because this user will be moved, based e.g. on the =0A= recent audio activity, from being displayed in the main video window to =0A= be in a thumbnail on the screen of the other participants in the =0A= conference), so it wants to manipulate the direction attribute of other =0A= m-lines.=0A= =0A= So there would be two offers sent at roughly the same time, which means =0A= we would have glare.=0A= =0A= I think the result would be similar if the server would instead ask for =0A= another resolution using the imageattr.=0A= =0A= You could argue that all control should be left to one end-point, but it = =0A= is sort of clumsy.=0A= =0A= Plan B, with the individual control of sources, seems better fitted to =0A= handle this kind of situations.=0A= =0A= >=0A= > /a=0A= =0A= From fluffy@iii.ca Fri May 10 11:45:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4B521F90DF; Fri, 10 May 2013 11:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaOe-Y2C4cDG; Fri, 10 May 2013 11:45:11 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 829A921F9104; Fri, 10 May 2013 11:44:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 5C03C2FD7D9; Fri, 10 May 2013 14:44:51 -0400 (EDT) Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 89F1F22E25C; Fri, 10 May 2013 14:44:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Fri, 10 May 2013 10:55:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D90F695235@xmb-rcd-x14.cisco.com> <201303221928.r2MJSOvW960763@shell01.TheWorld.com> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1503) Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Is bundle just a port override? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:45:15 -0000 On May 9, 2013, at 9:56 AM, Cullen Jennings (fluffy) = wrote: >=20 > On Mar 22, 2013, at 12:28 PM, Dale R. Worley = wrote: >=20 >>> From: "Mo Zanaty (mzanaty)" >>>=20 >>> BTW, has anyone actually observed failures? >>=20 >> My memory is that Cullen Jennings knows of a significant installed >> base of SBCs that choke on SDP that contains duplicated port >> references. >>=20 >> Dale >=20 > Some of them are using the port as the think to uniquely key into the = active data structures.=20 Sorry, apple auto correct got me. I mean "thing" not "think" From fluffy@cisco.com Fri May 10 13:47:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A6D21F9360 for ; Fri, 10 May 2013 13:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq1eubISTfuU for ; Fri, 10 May 2013 13:47:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AC87C21F9375 for ; Fri, 10 May 2013 13:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1830; q=dns/txt; s=iport; t=1368218840; x=1369428440; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ngr0HosFOsH7vw206Drw+AoF7T7qqa21vcIOo60GxCM=; b=UoKfrIUJY/gid4/LOkVhM8ggG1pGP3EDd+ouZ9kiW6Yzqkb+rLluAP/K GoaIQbWC1xGywm4Dyg3kzlYsDkFwaGiwnH6h9fvqTk4M+s9zwK9ahEyPN A3QlLN3B+EQMSW08a0TYyERThZmPxZzR01KliuuGg62YkZ2WlBQMURGuG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJFbjVGtJV2Z/2dsb2JhbABSgwfAU3wWdIIfAQEBAwE6PwULAgEIIhQQMiUCBA4FCId+Br1AjnUCMQeCdGEDqGGDD4In X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="208791405" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 10 May 2013 20:47:20 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4AKlK1t013557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 20:47:20 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 10 May 2013 15:47:19 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE: Accept m- line, reject bundle Thread-Index: AQHOTb+PU16TeJ6FrEWNpsoFyGcqnQ== Date: Fri, 10 May 2013 20:47:19 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> 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="us-ascii" Content-ID: <6131A93D5BF0B8478A8CE80DEE3BDBC2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:47:26 -0000 On May 3, 2013, at 7:07 AM, Christer Holmberg wrote: > Hi, > =20 > Assume the following case: > =20 > 1. An SDP offer contains an m- line associated with a BUNDLE group > 2. The answerer wants to accept the m- line, but wants to reject it= being in the specific BUNDLE group. > =20 > A few alternatives on how this could be achieved have been presented: > =20 > Alt 1. The answerer accepts the m- line, but does not associate it w= ith a BUNDLE group. > =20 > Alt 2. The answerer accepts the m- line, associates it with a BUNDLE= group, and then sends a new offer which removes the m- line from the BUNDL= E group. > =20 > Alt 3. The answerer rejects the m- line, and then sends a new offer = which adds the m- line outside a BUNDLE group. > =20 > In my opinion, Alt 1 does not work, at least not if the offer contains id= entical port values for the m- lines associated with the BUNDLE group. It w= ould mean that the m- line is not added to a BUNDLE group, but still has th= e same port value (at least at the offerer side) as the m- lines in the BUN= DLE group, which is not allowed. > =20 > So, my suggestion would be to specify that the answerer must use Alt 2 an= d/or Alt 3. > =20 > Comments? > =20 I think you want to to Alt 1.=20 Say Alice sends offer with with three m lines in a bundle. Note they will h= ave different ports.=20 Then Bob sends answer with two of these in the bundle and the one of them n= ot in the bundle. The two in the bundle will have the same port and be in t= he bundle group but the third will not be in a bundle and will have a diffe= rent port.=20 And like all bundle & ice usage, when everything is done negotiating there = can be the final O/A to clean up all the SBCs.=20 From fluffy@cisco.com Fri May 10 13:53:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C73D21F93A5 for ; Fri, 10 May 2013 13:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARD25vlSCjfX for ; Fri, 10 May 2013 13:53:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 86E1E21F845D for ; Fri, 10 May 2013 13:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2112; q=dns/txt; s=iport; t=1368219192; x=1369428792; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=70+rImGAHlYnhgmdYKqjYaXndxXP8PyJBJXQWtrQOek=; b=gjMjyM8D0fsG8cba/26xjpcufaTtlsI4foSGD42SVxT9/oMBZ8j87q4Q bvyfS/h8OAc1z6fyv8Nt+3T2XDQCeUVFqyuxkiHRdj34l800cBNSswgfz P1sdwxIaLd+vOv67L77hHKswugYUMLJl9IT1AOyglCgiMbFbzh949AmWd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABNdjVGtJXHB/2dsb2JhbABSgwc3RL9ZfBZ0gh8BAQEDAQEBATc0GwIBCCIUECcLJQIEEwgBC4dyBgcFvTSOdQI4gnRhA5NdhHWQD4MPgic X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="208983868" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 10 May 2013 20:53:11 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4AKrBAe028454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 10 May 2013 20:53:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 10 May 2013 15:53:10 -0500 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org WG" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt Thread-Index: AQHOTcBhpd8nHq46pk+GLJr09DVgWQ== Date: Fri, 10 May 2013 20:53:10 +0000 Message-ID: References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> In-Reply-To: <20130507182905.15924.84115.idtracker@ietfa.amsl.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="us-ascii" Content-ID: <5DD5732CA4EAB841ADF59E59280ED062@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:53:47 -0000 I think the security section series underestimates the security vulnerabili= ties this introduces. I'm very sad to see the IETF publishing this at all w= ith anything other than "This is not the recommended way to solve this prob= lem" and why. On May 7, 2013, at 12:29 PM, internet-drafts@ietf.org wrote: >=20 > 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 Wo= rking Group of the IETF. >=20 > Title : Latching: Hosted NAT Traversal (HNT) for Media in Real= -Time Communication > Author(s) : Emil Ivov > Hadriel Kaplan > Dan Wing > Filename : draft-ietf-mmusic-latching-01.txt > Pages : 14 > Date : 2013-05-07 >=20 > Abstract: > This document describes behavior of signalling intermediaries in > Real-Time Communication (RTC) deployments, sometimes referred to as > Session Border Controllers (SBCs), when performing Hosted NAT > Traversal (HNT). HNT is a set of mechanisms, such as media relaying > and latching, that such intermediaries use to enable other RTC > devices behind NATs to communicate with each other. This document is > non-normative, and is only written to explain HNT in order to provide > a reference to the IETF community, as well as an informative > description to manufacturers, and users. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-latching-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-latching-01 >=20 >=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 martin.thomson@gmail.com Fri May 10 13:54:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E2221F93D1 for ; Fri, 10 May 2013 13:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rasMPJgert9 for ; Fri, 10 May 2013 13:54:31 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AC83F21F93C6 for ; Fri, 10 May 2013 13:54:25 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id j13so1073883wgh.3 for ; Fri, 10 May 2013 13:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XCNq4MEApbkVmm0TET6hdIZ63/JSwXf+AUekh57JYkY=; b=L3j0pgEgxUYEEEndElvnHVH3xs5k3YzGFNa9RZdQGzhzz2gapp1GKVHHXwAwA6UYRQ q2PccAdNIj4a3VfByuW+JwKdxjkZweRbkb13cc5P9byD1mW+mjCAJaCttZLGZs48JIEQ I+hxCsXgdqwxz5K+jzPYLWmiz1qcPce/m9qldthhrKOpUKNQWWEmkuvjjcLcmaeLPH2o iFz00BXIRrnTlfhuYtYgJR+MDwy08ZiTD8zaRBbxDFvm0o27Ai9Nr7+vrb3teyvBC8MD B/i1xqzPiqiKTv+VMhp/pdpHmaR087fpCN3A2qWwHdKLYBzL8AwKuVP7VJAVE9yPsTIW 7V3A== MIME-Version: 1.0 X-Received: by 10.194.61.10 with SMTP id l10mr27016810wjr.32.1368219264847; Fri, 10 May 2013 13:54:24 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Fri, 10 May 2013 13:54:24 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> Date: Fri, 10 May 2013 13:54:24 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:54:32 -0000 On 10 May 2013 13:47, Cullen Jennings (fluffy) wrote: >> A few alternatives on how this could be achieved have been presented: >> >> Alt 1. The answerer accepts the m- line, but does not associate it with a BUNDLE group. >> >> Alt 2. The answerer accepts the m- line, associates it with a BUNDLE group, and then sends a new offer which removes the m- line from the BUNDLE group. >> >> Alt 3. The answerer rejects the m- line, and then sends a new offer which adds the m- line outside a BUNDLE group. > > I think you want to to Alt 1. I'm on Alt 1 as well. There are two signals that this is unbundled: a. The port is different. b. The BUNDLE group doesn't include the mid. The former wouldn't be sufficient, but the latter is always enough. From fluffy@cisco.com Fri May 10 14:19:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAFC21F90BB; Fri, 10 May 2013 14:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSXRDTi15JvM; Fri, 10 May 2013 14:19:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 22C7D21F9012; Fri, 10 May 2013 14:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=583; q=dns/txt; s=iport; t=1368220760; x=1369430360; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kb+Rn7mtlFkEyhGGIoDTacP4zwoKlRLU4Si8UyXe1RE=; b=arlXtkXTXDBOFkendgWeq/v1lWxkQbRcardSPean1Q7MFxhDwjXSFRlU PSUVe4QoMWfc0C0kLDJUBqcbP/1lBWSayDyua79m+8hyPwexojLASybLM FseXNgFsitODc9ESb+UsZjDOSAwQE65PFUvOh5KLNe9fRlfFtY3OGgg9W Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADhjjVGtJV2Y/2dsb2JhbABSgwfAVnwWdIIfAQEBAwE6PwULAgEIIhQQMiUCBA4Nh34GvUOOdQIxB4J0YQOoYYMPgic X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="208990655" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 10 May 2013 21:19:15 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4ALJFpA027334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 21:19:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 10 May 2013 16:19:15 -0500 From: "Cullen Jennings (fluffy)" To: "Dale R. Worley" Thread-Topic: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? Thread-Index: AQHOTcQG0FWtFMhXHUOIqYR0Ncup8g== Date: Fri, 10 May 2013 21:19:15 +0000 Message-ID: References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> In-Reply-To: <201304261820.r3QIKq913501941@shell01.TheWorld.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="us-ascii" Content-ID: <3D957E974AB28D4097794FEE7879B157@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Magnus Westerlund , "mmusic@ietf.org" , "payload@ietf.org" Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 21:19:25 -0000 >=20 64-65 have been obsolete and given the lack of H.261 being used in deployme= nts I think it is safe if they are in the secondary pool.=20 I think they would be better to ref=20 65 [RFC2032] 66 [RFC5484] For the rest, I think it should be more like=20 65 [RFC2032] 66 [RFC5484] 67 [RFC5450] 72 [RFC3550] 73 [RFC3550] 74 [RFC3550] 75 [RFC3550] 76 [RFC3550] 77 [RFC4585] 78 [RFC4585] 79 [RFC3611] 80 IEEE Std 1733TM-2011 Given how the next two are used, bit hard to decide what the impact is whe= n doing O/A=20 81 [RFC5760]=20 82 [RFC6284] From pkyzivat@alum.mit.edu Fri May 10 14:20:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBA621F9343 for ; Fri, 10 May 2013 14:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmCJjgzgz8qc for ; Fri, 10 May 2013 14:20:04 -0700 (PDT) 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 4D86021F90BB for ; Fri, 10 May 2013 14:20:04 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id aLGy1l00216LCl05DML39H; Fri, 10 May 2013 21:20:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id aML31l00p3ZTu2S3SML36P; Fri, 10 May 2013 21:20:03 +0000 Message-ID: <518D6482.2010008@alum.mit.edu> Date: Fri, 10 May 2013 17:20:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> 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=1368220803; bh=FT8XmLPiOWIV4si8k3wBZVTlF0Bco3cgaGat0HWENTg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hIcGmXzc/BgRIaApuI91dME/+pAQd3vkLAMevivcuYBk/hS5sb/+nMnnZxAn24s8F yla7fAOIaAQSEunhaQFQgevTK9eZcP3dra66fqfRoqIiO9Kvh2kQeymnJYROX9Bss5 QNkvup5R2ygXCfPJ2d6XcpENc1erJi2Z2+sPWqM9+aIDCVEwGz6sQ5byZwc1I31MQ5 CnCgMjdxvgTut9DeGWOWg+xpW/eY373/+eUwbA0MYiwliSsel1Z3q8zxheGEmduBjb DBNyv2C0bYfWkviBOUVuogUgSoa65H9x7vbwb+Zp7RBtTsa7rN/T0Ag/NqvTkqRquF eyJRwYiyd1ahg== Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 21:20:10 -0000 On 5/10/13 2:37 AM, Stefan Håkansson LK wrote: ... > But I can easily think of other situations that would lead to glare for > Plan A. > > Just as an example, think about a conference scenario with a centralized > node. Now, one of the participants wants to mute her/his audio, and as a > result the audio m-line would go from sendrecv to recvonly. At roughly > the same time the server wants to disable the high res video and enable > the low res video (because this user will be moved, based e.g. on the > recent audio activity, from being displayed in the main video window to > be in a thumbnail on the screen of the other participants in the > conference), so it wants to manipulate the direction attribute of other > m-lines. > > So there would be two offers sent at roughly the same time, which means > we would have glare. What do you mean by "roughly"? How long does it take to do an O/A exchange that doesn't require human input? Presumably less than a second, maybe considerably less. (Or will it be more with RTCWEB and web servers in the path?) What is the probability that the other side, for independent reasons, decides to make a change within that interval? (And it isn't really the whole interval - it is only the first part of it.) There may indeed be realistic cases for glare, but they will probably be because both changes are keyed to a common event. Thanks, Paul From fluffy@cisco.com Fri May 10 14:21:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF74321F84E7 for ; Fri, 10 May 2013 14:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcvg29QztGwj for ; Fri, 10 May 2013 14:21:45 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BA0FD21F90B9 for ; Fri, 10 May 2013 14:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1213; q=dns/txt; s=iport; t=1368220904; x=1369430504; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6zcUB5l8XTk3O6GhWGDFQt2nO6r9071kTbw++EzE13w=; b=MAR/TIcAoFpN/0Z+ov431u0y+fDYpJEeOBpf/0GJ6ik2HzweXPm9z3/A BgPzqrKhLfl21H++tcavNXXXyiK/UhtqyCn7MCWOLGGHOKYpVkVf19gFC Wx4+7qIZw5w3/Ym9+9nGNDblNx61JTlRyVYGodb+0cIf5oZcvm5AjoqCS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAL5jjVGtJV2c/2dsb2JhbABSgwc3wB98FnSCHwEBAQMBAQEBawsFCwIBCCIkJwslAgQOBQiHfgYMvTQEjnUCMQeCdGEDk12VBIMPgic X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="208802106" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 10 May 2013 21:21:35 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4ALLZs4027954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 21:21:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 10 May 2013 16:21:35 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: AQHOTcRZqC8pbEHECUumCdCpA++uHg== Date: Fri, 10 May 2013 21:21:35 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> 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: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 21:21:50 -0000 On May 3, 2013, at 6:53 AM, Christer Holmberg wrote: > Hi, > =20 > In order to try to close issues on BUNDLE, based on the discussions we=92= ve had, I intend to update the BUNDLE draft based on the following assumpti= ons: > =20 > 1. We mandate usage of rtcp-mux when BUNDLE is used. agree with this > =20 > 2. SDP m- lines with a zero port value MUST NOT be put inside a BUN= DLE group (not in an offer, nor in an answer). There will be a note indicat= ing that, due to this, the number of m- lines associated with a BUNDLE grou= p may differ between the offer and the associated answer. There will also b= e a note indicating that this is due to RFC 5888, in case people later star= t to wonder where the =93MUST NOT=94 comes from. object to this. I think EKR's idea of doing this explicitly in an offer to = indicate that the line is only being offered in a bundle is a good one.=20 > =20 > Please indicate if you OBJECT to any of these assumptions. > =20 > Regards, > =20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Fri May 10 15:01:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBF021F8FDB for ; Fri, 10 May 2013 15:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNc4r6b5EG6a for ; Fri, 10 May 2013 15:01:46 -0700 (PDT) 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 1951621F902D for ; Fri, 10 May 2013 15:01:45 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id aBcu1l0010EZKEL55N1lVS; Fri, 10 May 2013 22:01:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id aN1l1l00Y3ZTu2S3MN1l2E; Fri, 10 May 2013 22:01:45 +0000 Message-ID: <518D6E48.5060700@alum.mit.edu> Date: Fri, 10 May 2013 18:01:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@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=1368223305; bh=mL6Wcb+lgHRvty6v0Upv4upczCg2iZMZTFQgV68CDY8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=d89EV60OLc4kQONcvMwzbmCrPMEL/uAi+nfDDHUECvLEGT7tskE2YGRwF5gRDYY6H zgOApUUbRiFKu8w9TL9c+SwqIBkqR1V0n14uju84gRZQ/Mfcu8nSGruVhzFkC3AouD r/+ZHoK3HG2R/xc9PhTPBdKCImC9dxhF2Wjx6MvjlCoa0teyoBGci5q10liDWAaTrP uCT1jg8iikQdgRl2NCbnl0/A0TXYQrLvWwLo9TgdpndSG2dhrot1zeEA+xa15jKmEl JT8B2IRYahRzfyLNbnByaBkUe9o1N3WxTOScPc35qSdsO9wtD+rj6AGNY/WYY0OwaD LJhRB2LzbfMTQ== Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:01:51 -0000 It sounds like we are approaching violent agreement on this. But what about "bundle splitting" that I introduced even before this discussion began? It is more complex. Because of the rule that a bundle can't include an m-line with zero port, it is forced to use Alt-3. IMO Alt 1-3 are all "valid", if the answerer finds them acceptable to it. But for certain common cases its pretty clear that one is clearly better than another. Alt 1 is better in cases when you can use it. Alt 3 should work when Alt 1 won't. I envision no cases when Alt 2 is useful, but I see no reason to ban it. Thanks, Paul On 5/10/13 4:54 PM, Martin Thomson wrote: > On 10 May 2013 13:47, Cullen Jennings (fluffy) wrote: >>> A few alternatives on how this could be achieved have been presented: >>> >>> Alt 1. The answerer accepts the m- line, but does not associate it with a BUNDLE group. >>> >>> Alt 2. The answerer accepts the m- line, associates it with a BUNDLE group, and then sends a new offer which removes the m- line from the BUNDLE group. >>> >>> Alt 3. The answerer rejects the m- line, and then sends a new offer which adds the m- line outside a BUNDLE group. >> >> I think you want to to Alt 1. > > I'm on Alt 1 as well. There are two signals that this is unbundled: > a. The port is different. > b. The BUNDLE group doesn't include the mid. > The former wouldn't be sufficient, but the latter is always enough. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Fri May 10 15:06:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EE121F8FFC for ; Fri, 10 May 2013 15:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsmPDL96hzqr for ; Fri, 10 May 2013 15:06:21 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id B77DE21F8FB6 for ; Fri, 10 May 2013 15:06:20 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta12.westchester.pa.mail.comcast.net with comcast id aMtC1l0021wpRvQ5CN6Lg6; Fri, 10 May 2013 22:06:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id aN6K1l00y3ZTu2S3eN6LVa; Fri, 10 May 2013 22:06:20 +0000 Message-ID: <518D6F5A.305@alum.mit.edu> Date: Fri, 10 May 2013 18:06:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C36B485@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=1368223580; bh=jNVSQ5C4JHm7RqBLhb03aOOMfQ8bwiiJNT9S/55doDU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MHJjA5+2A4bY8PaND9Fl6SQpKN917L/CTQxJUxtyKrlt7x+8D9T/LKqCC/xfcL60G sLEuu/Mi/ozUBt/0Hzi1pI6K9ZjgIO1Rmpmlsx1IOWRk/Z5NgAzbnBG5PLnJKhQhop 0Y8O9MbEOmBgr+PYnUt4IWj9TjMlxY+2cvd1BEvPoK8F3fUsgjGrEoZdDHACJZvjEp I3DPHWFnDPZQWXMlqdVVZq9Z6UCDnm1gWS3GV2DY+OIW1tyHPxsX2FP0I7Lmqn9aYC NO2p5XQU4LNlVO6zpxK7VQaSN9VJmvb0Eg/Q7dyXFx3hjjfLHFAorA60Sql2H63xjY GpMiF0GA5LBuQ== Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:06:26 -0000 On 5/10/13 5:21 PM, Cullen Jennings (fluffy) wrote: >> 2. SDP m- lines with a zero port value MUST NOT be put inside a BUNDLE group (not in an offer, nor in an answer). There will be a note indicating that, due to this, the number of m- lines associated with a BUNDLE group may differ between the offer and the associated answer. There will also be a note indicating that this is due to RFC 5888, in case people later start to wonder where the “MUST NOT” comes from. > > object to this. I think EKR's idea of doing this explicitly in an offer to indicate that the line is only being offered in a bundle is a good one. Then we must revise 5888. Its hard to say whether we could get away with making that change without dealing with backward compatibility issues. Maybe we should ask the authors (Gonzalo and Henning) why that limitation was put in. It does seem pretty arbitrary. Thanks, Paul From ekr@rtfm.com Fri May 10 15:06:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9721F9347 for ; Fri, 10 May 2013 15:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmPhVgQLp5ul for ; Fri, 10 May 2013 15:06:27 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 16DE421F8FB6 for ; Fri, 10 May 2013 15:06:27 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 9so2716997qea.21 for ; Fri, 10 May 2013 15:06:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=sxzHHH5DToiel/ujg+XOUcKsMrpHNwMOXHRrzL1qok8=; b=bNYNhgd1+3/+mIFvyLn+HJ6Y1OTBIsbiMi5e3HEY9HSFoZpM7k60TELI9EdsE4Q28O J269FsbsYENp6eVHaPAJwckk80BCO6osm2Si9XDWSpmqXn9kLjhIEQsvG7jnWDl7ngG7 wio1CMc5HuwGCKkMhJKktrpsvVWW1g0iEc8obe2aj5qzRNmYJHQUEmCxiLLyG0m0lWea peco7IaZBeeiWq+qqj7AsF6l+HT1nGmvyU34weV/C4HRDhoVsHaQFgBPuzPtgFEqQ3eu YgQqVUgQrZ7RcTVde949G9LHxLgaFcjNVEjyjWKxuz3ANq0+rnAFx178Ob6Oar752j2I eZ0Q== X-Received: by 10.49.116.67 with SMTP id ju3mr15075507qeb.8.1368223586465; Fri, 10 May 2013 15:06:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.96.169 with HTTP; Fri, 10 May 2013 15:05:46 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Fri, 10 May 2013 15:05:46 -0700 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b5d5a3ed84a4904dc6460d7 X-Gm-Message-State: ALoCoQlejAiQ/citWlEs4WXlrtilRASvRePAyaVdj+CTj6hkmcaExC211ZkLXGOvrqbzgCiGiiz2 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:06:33 -0000 --047d7b5d5a3ed84a4904dc6460d7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2013 at 2:21 PM, Cullen Jennings (fluffy) wrote: > > On May 3, 2013, at 6:53 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Hi, > > > > In order to try to close issues on BUNDLE, based on the discussions > we=92ve had, I intend to update the BUNDLE draft based on the following > assumptions: > > > > 1. We mandate usage of rtcp-mux when BUNDLE is used. > > agree with this > > > > > 2. SDP m- lines with a zero port value MUST NOT be put inside a > BUNDLE group (not in an offer, nor in an answer). There will be a note > indicating that, due to this, the number of m- lines associated with a > BUNDLE group may differ between the offer and the associated answer. Ther= e > will also be a note indicating that this is due to RFC 5888, in case peop= le > later start to wonder where the =93MUST NOT=94 comes from. > > object to this. I think EKR's idea of doing this explicitly in an offer t= o > indicate that the line is only being offered in a bundle is a good one. > > I'm sorry to be slow today, but can you point me to the specific MUST NOT in RFC 5888. -Ekr --047d7b5d5a3ed84a4904dc6460d7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2013 at 2:21 PM, Cullen Jennings (fluffy) <fluffy@cisco.com= > wrote:

On May 3, 2013, at 6:53 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
>
> In order to try to close issues on BUNDLE, based on the discussions we= =92ve had, I intend to update the BUNDLE draft based on the following assum= ptions:
>
> 1. =A0 =A0 =A0 We mandate usage of rtcp-mux when BUNDLE is used.

agree with this

>
> 2. =A0 =A0 =A0 SDP m- lines with a zero port value MUST NOT be put ins= ide a BUNDLE group (not in an offer, nor in an answer). There will be a not= e indicating that, due to this, the number of m- lines associated with a BU= NDLE group may differ between the offer and the associated answer. There wi= ll also be a note indicating that this is due to RFC 5888, in case people l= ater start to wonder where the =93MUST NOT=94 comes from.

object to this. I think EKR's idea of doing this explicitly in an= offer to indicate that the line is only being offered in a bundle is a goo= d one.


I'm= sorry to be slow today, but can you point me to the specific MUST NOT in R= FC 5888.=A0

-Ekr

--047d7b5d5a3ed84a4904dc6460d7-- From martin.thomson@gmail.com Fri May 10 15:06:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7C221F940B for ; Fri, 10 May 2013 15:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5n2bpedtf00 for ; Fri, 10 May 2013 15:06:58 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBAE21F9408 for ; Fri, 10 May 2013 15:06:53 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x53so4397903wes.33 for ; Fri, 10 May 2013 15:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=a2cJq0Q6FOodgR0g2AmY4KWtEwGo/Z949bowdmAXoP8=; b=C7VMcrBx3BYxF9PSZT944HAw/grbLcIvak5EqoswADDBF7N3SXkgHxOhWambolr2AQ id+2uNOMvSEJSKIKM6fQdYHoINyTcfffYPR/wTz8oKaLWVwsTf9F59jgODwjxC8XpAnL D0mVmI5EDqFe8pOVGYFDySrILcgUKZSU4Z9+0XyFBw6Fy0PkQHCuYLgUxP00mKYy3sui JRjMCA7vbONfiTl39DOObBRckUqA1KmhIMZ778CXkuiEsmBIE+tYblDiGO1tjdqpV1XJ 6aqJ93HUZzAA97ofnfxjeOhnkJddM5gUIjwjvYABwtLssYeu3ZpNL37pUHQaR+ejlcvR Qh+Q== MIME-Version: 1.0 X-Received: by 10.180.83.199 with SMTP id s7mr6472977wiy.19.1368223607285; Fri, 10 May 2013 15:06:47 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Fri, 10 May 2013 15:06:47 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> Date: Fri, 10 May 2013 15:06:47 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:06:59 -0000 On 10 May 2013 14:21, Cullen Jennings (fluffy) wrote: > On May 3, 2013, at 6:53 AM, Christer Holmberg wrote: >> 2. SDP m- lines with a zero port value MUST NOT be put inside a BU= NDLE group (not in an offer, nor in an answer). There will be a note indica= ting that, due to this, the number of m- lines associated with a BUNDLE gro= up may differ between the offer and the associated answer. There will also = be a note indicating that this is due to RFC 5888, in case people later sta= rt to wonder where the =E2=80=9CMUST NOT=E2=80=9D comes from. > > object to this. I think EKR's idea of doing this explicitly in an offer t= o indicate that the line is only being offered in a bundle is a good one. +1 I'd prefer to keep the concepts of bundling (in-out) and negotiated (on-off) as two orthogonal switches. From martin.thomson@gmail.com Fri May 10 15:14:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF9421F944A for ; Fri, 10 May 2013 15:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8ZPER8OpiVr for ; Fri, 10 May 2013 15:14:13 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id F254721F9428 for ; Fri, 10 May 2013 15:14:12 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so4464648wes.41 for ; Fri, 10 May 2013 15:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=t76/DPdIqbaHuw0/JU3UwUUN5FeiZXk1+J09+NDHE/8=; b=j1Vg3APA4NmU5R5VMjvZAlfthj6htsU0JwosqlbFNqVkgIdBHm9DUlm726wpu/Oea3 382sfod1XII0MpDmi7Y/Dn9Knd+DGsiYBL5FDE4XZrANwDcMmbKveRa3MbRsQ0+zOgoV Zc3fTh7A31kh1mgJ7tbyEeoc8rnwbwazkOiGVNcyv7r5WXtKxgc+/OuyTNDIvaA99moV 9hfZY2Y50V/H6/wiylR7bp1y8SYDMOnryoWkF62hgk+Go3iv2w7QymZqQoayWqiCfPE8 LH8BIobHo3V1Q0naAyULzJcreQfc2yY0mAAmmTQaAyff6hL6BXTFzLzX1M3PrGSYJJVK 3piA== MIME-Version: 1.0 X-Received: by 10.194.63.239 with SMTP id j15mr27365345wjs.30.1368224051931; Fri, 10 May 2013 15:14:11 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Fri, 10 May 2013 15:14:11 -0700 (PDT) In-Reply-To: <518D6E48.5060700@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> <518D6E48.5060700@alum.mit.edu> Date: Fri, 10 May 2013 15:14:11 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:14:16 -0000 On 10 May 2013 15:01, Paul Kyzivat wrote: > Alt 1 is better in cases when you can use it. Alt 3 should work when Alt 1 > won't. I envision no cases when Alt 2 is useful, but I see no reason to ban > it. I agree. A good summary. From martin.thomson@gmail.com Fri May 10 15:17:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059D821F90DF for ; Fri, 10 May 2013 15:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBxyH1X+KLCH for ; Fri, 10 May 2013 15:17:06 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D106921F9130 for ; Fri, 10 May 2013 15:17:02 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t59so4340643wes.38 for ; Fri, 10 May 2013 15:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CQAMc7ufrlTPLwcNSbEWPkrsNDuDy/NmoE+Paf50HK8=; b=gsdOauLDEBYzC6IbntQbTZAu84okaKG0BWC7KckWYySSmwNBhbatc4MUaiHnpi2LY9 TWUsxeS2MGTDR9oF24BiWEsiTLxcM+wBXUAZyHYxA95L/nAgf3kxYbZwItRX57wo1D2b lCWXjrr0ltjEczpVLAOrYvDdZzet7JKIkxpGxLKo58teE0/kB3AP8B9T6uH538nO/6Ij mvoMq03BgnMr+GvVMgqnnIg4jirtgVBoxfi3vkR1SedhTRXUTDE0i8+hLJHfkECf4PiQ NhPA/ePWnjeC+G384aMImQL2fiahqciOJ27rGfk+zOV344CiQCqend1O19I+Ypplnxq5 PxWw== MIME-Version: 1.0 X-Received: by 10.194.78.204 with SMTP id d12mr27354981wjx.42.1368224217929; Fri, 10 May 2013 15:16:57 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Fri, 10 May 2013 15:16:57 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> Date: Fri, 10 May 2013 15:16:57 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:17:07 -0000 On 10 May 2013 15:05, Eric Rescorla wrote: > I'm sorry to be slow today, but can you point me to the specific MUST NOT in > RFC 5888. I struggled to find it too. It's in 9.2: SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero. From ekr@rtfm.com Fri May 10 15:18:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF1A21F92F5 for ; Fri, 10 May 2013 15:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.701 X-Spam-Level: X-Spam-Status: No, score=-101.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUibb+rAgy-P for ; Fri, 10 May 2013 15:18:36 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 53F5721F9164 for ; Fri, 10 May 2013 15:18:36 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id d1so2506118qcz.38 for ; Fri, 10 May 2013 15:18:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=1uGNHuD06MT0iEazqQ1fMOGC2dvy6RuFYc80I9UEC+s=; b=SEn/H3GNgwGoOD1ZmQ7+9Wgbr9vrGA/KwLPw84T9iYt/RCE52WQMbOEm14ncCAiEEl Fbo2Ts51sGJhz8bpsZqDYUgzr7/aG3J8W+qYINOn4QfnLz8MonrBDGyYVswqJ6CJTgnj Dcuaa6c/voSLUUtziVIYGB4mGSfcM+iYBez1IL3EE8K+cWilQeP1yCUDtMNn4X//RASn 3hsoTSMyNSzYug/JOQJMOT6oKhZWCkS0Z0NaMKtrHu2dYsjkDLekv/d+Zb62Z0CZ4Oyv MnEAAxwHWn+kKo03m3Y59Vcp0GgMpLpEr3oeR0w1saYiI2L8MLe/Ihmwas4iJsL/VdtL GXhw== X-Received: by 10.49.116.67 with SMTP id ju3mr15103122qeb.8.1368224314540; Fri, 10 May 2013 15:18:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.96.169 with HTTP; Fri, 10 May 2013 15:17:54 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Fri, 10 May 2013 15:17:54 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b5d5a3e3dcbf604dc648c8c X-Gm-Message-State: ALoCoQn+egR3x6KlCFJdkzNNUbr/LMUisBkoUlF0PGR0pBIQkVA4CXFTTtDzLG0ewdap3iApQkl2 Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:18:41 -0000 --047d7b5d5a3e3dcbf604dc648c8c Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 10, 2013 at 3:16 PM, Martin Thomson wrote: > On 10 May 2013 15:05, Eric Rescorla wrote: > > I'm sorry to be slow today, but can you point me to the specific MUST > NOT in > > RFC 5888. > > I struggled to find it too. It's in 9.2: > > SIP entities refuse media streams by setting the port to zero in the > corresponding "m" line. "a=group" lines MUST NOT contain > identification-tags that correspond to "m" lines with the port set to > zero. > This feels like something we could relax for the offer. --047d7b5d5a3e3dcbf604dc648c8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, May 10, 2013 at 3:16 PM, Martin = Thomson <martin.thomson@gmail.com> wrote:
On 10 May 2013 15:05, Eric Rescorla <ekr@rtfm.com> wrote:
> I'm sorry to be slow today, but can you point me to the specific M= UST NOT in
> RFC 5888.

I struggled to find it too. =A0It's in 9.2:

=A0 =A0SIP entities refuse media streams by setting the port to zero in the=
=A0 =A0corresponding "m" line. "a=3Dgroup" lines MUST N= OT contain
=A0 =A0identification-tags that correspond to "m" lines with the = port set to
=A0 =A0zero.

This feels like something we could relax for th= e offer.
--047d7b5d5a3e3dcbf604dc648c8c-- From pkyzivat@alum.mit.edu Fri May 10 15:21:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996B821F9012 for ; Fri, 10 May 2013 15:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THmNwxOliyTy for ; Fri, 10 May 2013 15:21:21 -0700 (PDT) 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 9F92921F89AF for ; Fri, 10 May 2013 15:21:20 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id aA6m1l00G0ldTLk53NMJtx; Fri, 10 May 2013 22:21:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id aNMH1l01U3ZTu2S3QNMJwA; Fri, 10 May 2013 22:21:18 +0000 Message-ID: <518D72DD.2070601@alum.mit.edu> Date: Fri, 10 May 2013 18:21:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C36B485@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=1368224478; bh=040dTx+bUlZKO3tP8cH2PHrS5BV6TBtDn89KuDqAZwE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZZVsqCRGt6xmpOr+/RQJcLxnX+ZLl1xwnOZLT+aUOgHALka5mOX9MfKuQO3iJ93V5 rme11Lo0KmJQQKsjyULNL4oLgVF79zJltyuwlANWNNwhzsWcV7PHR4PtoCRd/oeVbT Eqk9V3XJ5W1g6k7TazPtPH0uzQTZiTo1YKvtSzma1A49fan1FQFs5V/wETk7WNzQex jVWqnIjCtKCdFkzj3sPcMnyyZrlrJuO7EKyKlwzSv3ZXQs4kiboWbHo5Wy/VgG/9FN uE65W2iMIQ8zKGtlqbv11Bi/8fR2LCvKAftqJDMRGGsqA+ptDFNFlclnzM6HHJogmW MiXlqbayLlL2A== Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:21:35 -0000 On 5/10/13 6:05 PM, Eric Rescorla wrote: > > 2. SDP m- lines with a zero port value MUST NOT be put > inside a BUNDLE group (not in an offer, nor in an answer). There > will be a note indicating that, due to this, the number of m- lines > associated with a BUNDLE group may differ between the offer and the > associated answer. There will also be a note indicating that this is > due to RFC 5888, in case people later start to wonder where the > “MUST NOT” comes from. > > object to this. I think EKR's idea of doing this explicitly in an > offer to indicate that the line is only being offered in a bundle is > a good one. > > > I'm sorry to be slow today, but can you point me to the specific MUST > NOT in RFC 5888. Section 9.2: SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero. While this is stated in the context of answers, the statement itself seems unqualified. And it would be pretty silly if you could do it in the offer and not in the answer. Thanks, Paul From martin.thomson@gmail.com Fri May 10 15:24:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB08C21F93C6 for ; Fri, 10 May 2013 15:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeZRj7jAsygy for ; Fri, 10 May 2013 15:24:19 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DE03321F91A5 for ; Fri, 10 May 2013 15:24:18 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hm14so1096492wib.11 for ; Fri, 10 May 2013 15:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vq967PjdMYFzw40RP6L2iHt4AVdg2gDcN05+wHsMhkI=; b=x2V4Kc1E9hx2L6yDxsmVs8ut3VAoPeDYo0oMwVt81bapZ7XzKfRKGPstuBwoG38np4 zslfHOAncrLK2+QHlSm9Eyg9ixepEQrTXK3kD29vpxsuiTSwwlcVXGePEEiort3F/Zd/ 6ZvelTMXF5qLtbYr/R1diyDJpWAJa6gULLxihnfWRN+3lqxdnfT1h/sr2WRr8dxtjJT/ LUAlJSM+PttMxHCvfIVby3rjSvPMeQaFTuC2nMJfJu//xyOAozQo2dGB03q9Vydoe0Hy JTEwtBJGVkYGT6dn8IxvCvCWDYkYDFQ5yhnYLrI18VCnOHjqZ6JPpFLAn44m6PYi6w9m h3ng== MIME-Version: 1.0 X-Received: by 10.194.61.10 with SMTP id l10mr27351226wjr.32.1368224632672; Fri, 10 May 2013 15:23:52 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Fri, 10 May 2013 15:23:52 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> Date: Fri, 10 May 2013 15:23:52 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:24:53 -0000 X-List-Received-Date: Fri, 10 May 2013 22:24:53 -0000 On 10 May 2013 15:17, Eric Rescorla wrote: > On Fri, May 10, 2013 at 3:16 PM, Martin Thomson > wrote: >> >> On 10 May 2013 15:05, Eric Rescorla wrote: >> > I'm sorry to be slow today, but can you point me to the specific MUST >> > NOT in >> > RFC 5888. >> >> I struggled to find it too. It's in 9.2: >> >> SIP entities refuse media streams by setting the port to zero in the >> corresponding "m" line. "a=group" lines MUST NOT contain >> identification-tags that correspond to "m" lines with the port set to >> zero. > > This feels like something we could relax for the offer. Absolutely. It seems a little arbitrary. That said, I'd like to understand why the MUST NOT exists. Of the groupings I understand, I can't think of a reason not to allow negotiated-off lines, but I'm prepared to be surprised. From pkyzivat@alum.mit.edu Fri May 10 15:26:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E0621F85C3 for ; Fri, 10 May 2013 15:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.159 X-Spam-Level: X-Spam-Status: No, score=-0.159 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8IYEX6Bw33H for ; Fri, 10 May 2013 15:25:58 -0700 (PDT) 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 5F26221F852D for ; Fri, 10 May 2013 15:25:49 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id aANp1l00C0mv7h051NRhRH; Fri, 10 May 2013 22:25:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id aNRh1l00f3ZTu2S3XNRheu; Fri, 10 May 2013 22:25:41 +0000 Message-ID: <518D73E4.4090609@alum.mit.edu> Date: Fri, 10 May 2013 18:25:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C36B485@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=1368224741; bh=HC6wj0oZG0IH1InblAZlB1qkD2e5gdRxnfXPPaL7i8E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sVi5BLgy2WR3LyVZ3trKJMWAA6GKsqtJazvl/XD7CVWzvumLFggj/kp2nv+5WA39W ODmugMPfIDRJCmIolh37IUxvV+YgVCtNpEChq1IDy70pP2CHqn9pSlkGaZuhDchIh6 IR94kE7NgMtpxlc9Yi+zu/Z1k4sa97MEJ2rxC5A522IwPXLoX/AqWQOuTnkMVOuooo x0iirCr+F4vI9DeZh8sfLukMSe1GKqJXlfEWkH1/R92UWMujN1QiDomKSBcZYGOKwV GLaUJdjCBtmIyIzMN3mduMO08UedyaW6WHlm53GcI9pZklYzmuQOp+SXSSFYwdpWcC 11TbofUwNqwfw== Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:26:19 -0000 On 5/10/13 6:17 PM, Eric Rescorla wrote: > > > On Fri, May 10, 2013 at 3:16 PM, Martin Thomson > > wrote: > > On 10 May 2013 15:05, Eric Rescorla > wrote: > > I'm sorry to be slow today, but can you point me to the specific > MUST NOT in > > RFC 5888. > > I struggled to find it too. It's in 9.2: > > SIP entities refuse media streams by setting the port to zero in the > corresponding "m" line. "a=group" lines MUST NOT contain > identification-tags that correspond to "m" lines with the port > set to > zero. > > > This feels like something we could relax for the offer. We could relax it. The question is if the change will break any existing use. That is a hard question to answer. If we do relax it, then we should do for both offer and answer. Doing just for offer is stupid and bound to introduce further complications. Thanks, Paul From ekr@rtfm.com Fri May 10 15:27:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A717F21F93EC for ; Fri, 10 May 2013 15:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.063 X-Spam-Level: X-Spam-Status: No, score=-101.063 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj3jGYNSeSem for ; Fri, 10 May 2013 15:27:31 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A3D6321F9410 for ; Fri, 10 May 2013 15:27:09 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id s10so2534856qcv.12 for ; Fri, 10 May 2013 15:27:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=Q01KS3LS78WJnugHcHe9HKM9pWBFgTljZ91hxcRrNVE=; b=GK/leoTQSGqAdCiwAxW4b8UT3hvBudnB8bvOZ+pV8u/O/c93Ql+5byiKD7Hadd3wIL QDZ0SjFUa22TEnrk0xvM8dnSaSD9byVNJiYeILHn1RjRLpIrwqQhjI+x+jaDByzPD68O dXNIrab5f9qJ+96Yz5HOuuUBSr2ntN8mwsHjDwLwue16BJB+bAAvWF7LjAI4qPes06hD OK2+8ERezg7apm/kYWdo1noOeKdFRmA3/5LVjyMujhfksZa/4qjzPYRV8LDbXYatQXvA 6RH7uTh6X2rkl+23xCX3XdxbSv0JYsuzSX1t3/2k5wE/Jq+LrI6lJ2cQzr4yfXt271GR /oew== X-Received: by 10.224.30.76 with SMTP id t12mr13218606qac.24.1368224829137; Fri, 10 May 2013 15:27:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.96.169 with HTTP; Fri, 10 May 2013 15:26:28 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Fri, 10 May 2013 15:26:28 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bea37c2e9f0c004dc64aa62 X-Gm-Message-State: ALoCoQmgE/0qdXrXzkZ0Rh/5PsDTtbmoNXwfBeNoESGp5IJVUfykDexf9yXFdR3Z6HjAW3XE1i4a Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:27:36 -0000 --047d7bea37c2e9f0c004dc64aa62 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 10, 2013 at 3:23 PM, Martin Thomson wrote: > On 10 May 2013 15:17, Eric Rescorla wrote: > > On Fri, May 10, 2013 at 3:16 PM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > >> > >> On 10 May 2013 15:05, Eric Rescorla wrote: > >> > I'm sorry to be slow today, but can you point me to the specific MUST > >> > NOT in > >> > RFC 5888. > >> > >> I struggled to find it too. It's in 9.2: > >> > >> SIP entities refuse media streams by setting the port to zero in the > >> corresponding "m" line. "a=group" lines MUST NOT contain > >> identification-tags that correspond to "m" lines with the port set to > >> zero. > > > > This feels like something we could relax for the offer. > > Absolutely. It seems a little arbitrary. That said, I'd like to > understand why the MUST NOT exists. Of the groupings I understand, I > can't think of a reason not to allow negotiated-off lines, but I'm > prepared to be surprised. > Indeed. Of course, if it is a problem we can invent: a=group-without-5888-restrictions:.... -Ekr --047d7bea37c2e9f0c004dc64aa62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2013 at 3:23 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 10 May 2013 15:17, Eric Rescorla= <ekr@rtfm.com> wrote:
> On Fri, May 10, 2013 at 3:16 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 10 May 2013 15:05, Eric Rescorla <ekr@rtfm.com> wrote:
>> > I'm sorry to be slow today, but can you point me to the s= pecific MUST
>> > NOT in
>> > RFC 5888.
>>
>> I struggled to find it too. =A0It's in 9.2:
>>
>> =A0 =A0SIP entities refuse media streams by setting the port to ze= ro in the
>> =A0 =A0corresponding "m" line. "a=3Dgroup" lin= es MUST NOT contain
>> =A0 =A0identification-tags that correspond to "m" lines = with the port set to
>> =A0 =A0zero.
>
> This feels like something we could relax for the offer.

Absolutely. =A0It seems a little arbitrary. =A0That said, I'= ;d like to
understand why the MUST NOT exists. =A0Of the groupings I understand, I
can't think of a reason not to allow negotiated-off lines, but I'm<= br> prepared to be surprised.

Indeed.=A0

Of course, = if it is a problem we can invent:
a=3Dgroup-without-5888-restrict= ions:....

-Ekr

--047d7bea37c2e9f0c004dc64aa62-- From fluffy@cisco.com Fri May 10 15:35:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C30C21F9410 for ; Fri, 10 May 2013 15:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99DvlcCrpjYN for ; Fri, 10 May 2013 15:34:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CDC6221F940D for ; Fri, 10 May 2013 15:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1244; q=dns/txt; s=iport; t=1368225296; x=1369434896; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=C+xkaXQ8RRQHXfckSXuw7UkFbbDLA7nw7RphxGJGJe8=; b=TjdjHw361wZ599PSkT5AN4dThtYvrPVPhpUY7RIkKV3vrL8Jib9bY4tX oDo9HlGsPZe8IV3y3bWcYtanRE7gY18DS6Rx+omDxhJCu22FfbwzwkFwi SOGvK/Rd/hBOlKuCuOr9azfYDhUv5iKWrq2vJNvKuterYh77YFsqUgzgf M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAF1jVGtJV2b/2dsb2JhbABSgwfAV3sWdIIfAQEBAwF5BQsCAQgOCgokIRElAgQOBQiHcgMJBrUTDYgojFKCIwIxB4J0YQOVSI13hSKDD4In X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="208821005" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 10 May 2013 22:34:55 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4AMYtZo020354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 22:34:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 10 May 2013 17:34:55 -0500 From: "Cullen Jennings (fluffy)" To: Eric Rescorla Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: AQHOTcqqHcswwrWHOk25MsldfS1yY5j/UGeAgAAARACAAAGrAIAAALoAgAACaIA= Date: Fri, 10 May 2013 22:34:55 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C36B485@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: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:35:02 -0000 On May 10, 2013, at 4:26 PM, Eric Rescorla wrote: > On Fri, May 10, 2013 at 3:23 PM, Martin Thomson wrote: > On 10 May 2013 15:17, Eric Rescorla wrote: > > On Fri, May 10, 2013 at 3:16 PM, Martin Thomson > > wrote: > >> > >> On 10 May 2013 15:05, Eric Rescorla wrote: > >> > I'm sorry to be slow today, but can you point me to the specific MUS= T > >> > NOT in > >> > RFC 5888. > >> > >> I struggled to find it too. It's in 9.2: > >> > >> SIP entities refuse media streams by setting the port to zero in th= e > >> corresponding "m" line. "a=3Dgroup" lines MUST NOT contain > >> identification-tags that correspond to "m" lines with the port set = to > >> zero. > > > > This feels like something we could relax for the offer. >=20 > Absolutely. It seems a little arbitrary. That said, I'd like to > understand why the MUST NOT exists. Of the groupings I understand, I > can't think of a reason not to allow negotiated-off lines, but I'm > prepared to be surprised. >=20 > Indeed.=20 >=20 > Of course, if it is a problem we can invent: > a=3Dgroup-without-5888-restrictions:=85. +1=20 From jonathan@vidyo.com Fri May 10 15:45:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2AB21F9406 for ; Fri, 10 May 2013 15:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufc2D84S73Ya for ; Fri, 10 May 2013 15:44:59 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF4921F93D1 for ; Fri, 10 May 2013 15:44:52 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B79677A7D92; Fri, 10 May 2013 18:07:37 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 448897A7863; Fri, 10 May 2013 18:07:37 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Fri, 10 May 2013 18:44:24 -0400 From: Jonathan Lennox To: Paul Kyzivat Date: Fri, 10 May 2013 18:44:50 -0400 Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: Ac5Nz+sN9rodGvgvRyumQeQi5BNQHg== Message-ID: <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> In-Reply-To: <518D73E4.4090609@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:45:06 -0000 On May 10, 2013, at 6:25 PM, Paul Kyzivat wrote: > On 5/10/13 6:17 PM, Eric Rescorla wrote: >>=20 >>=20 >> On Fri, May 10, 2013 at 3:16 PM, Martin Thomson >> > wrote: >>=20 >> On 10 May 2013 15:05, Eric Rescorla > > wrote: >>> I'm sorry to be slow today, but can you point me to the specific >> MUST NOT in >>> RFC 5888. >>=20 >> I struggled to find it too. It's in 9.2: >>=20 >> SIP entities refuse media streams by setting the port to zero in = the >> corresponding "m" line. "a=3Dgroup" lines MUST NOT contain >> identification-tags that correspond to "m" lines with the port >> set to >> zero. >>=20 >>=20 >> This feels like something we could relax for the offer. >=20 > We could relax it. The question is if the change will break any existing= =20 > use. That is a hard question to answer. We could say that whether it's valid must be defined by the group semantic,= and for all existing group semantics it's not. -- Jonathan Lennox jonathan@vidyo.com From pkyzivat@alum.mit.edu Fri May 10 17:40:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E3E21F8FEB for ; Fri, 10 May 2013 17:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLZ15hK7UM+j for ; Fri, 10 May 2013 17:40:03 -0700 (PDT) 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 BEB8A21F9057 for ; Fri, 10 May 2013 17:40:02 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta15.westchester.pa.mail.comcast.net with comcast id aQRD1l0040QuhwU5FQg2fP; Sat, 11 May 2013 00:40:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id aQg11l00p3ZTu2S3NQg1EQ; Sat, 11 May 2013 00:40:02 +0000 Message-ID: <518D9361.7060301@alum.mit.edu> Date: Fri, 10 May 2013 20:40:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jonathan Lennox References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> In-Reply-To: <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.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=1368232802; bh=Gw1yrBgvix1bRuWstprAnmoqKAGR+kT2vHhnFusURjQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jP/E5OGihwo0wsW+SsSc0Rguk/0uje7N0Rw3zEOYTG6kbAiZ7w9Iwiieqfk5kxHYB /DR3F2a9GUr3g0S1HG4BNOr/+RHvy3l/2IDYG6r/88nOU4TNV1Rvd1FmjUg7RMqZSz Lmx6quN5VOW54I3ln57P+asz8e2sDKutdJbFv+5SeI0YjB4i3zDaGGN8CbZMHCGG/6 9UvBwgXxUvkdAwLBVHZa+Ud5bffnzp8BiUZsJ47FzSu2xWQiNIFi76Xg0VQnBI0QNi LzxzWzkQF9BkMzDExkrNUOaNkRiG6EClu58Ax68M2aMcRyFUDznDxS8aOxoL+6tgRb IRQuozqS6bNrA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 00:40:08 -0000 On 5/10/13 6:44 PM, Jonathan Lennox wrote: >>> I struggled to find it too. It's in 9.2: >>> >>> SIP entities refuse media streams by setting the port to zero in the >>> corresponding "m" line. "a=group" lines MUST NOT contain >>> identification-tags that correspond to "m" lines with the port >>> set to >>> zero. >>> >>> >>> This feels like something we could relax for the offer. >> >> We could relax it. The question is if the change will break any existing >> use. That is a hard question to answer. > > We could say that whether it's valid must be defined by the group semantic, and for all existing group semantics it's not. WFM From emil@sip-communicator.org Sat May 11 03:00:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2591821F8E75 for ; Sat, 11 May 2013 03:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Efkshgweu0x for ; Sat, 11 May 2013 03:00:02 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C06EC21F8E94 for ; Sat, 11 May 2013 03:00:01 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p57so4762602wes.20 for ; Sat, 11 May 2013 03:00:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=7RvR6+BDmt192bnMUWrPKX8G6vROB+6SMmBIrcBjeE8=; b=gZvuksMW8tLJav8dJQAJACf6npPG+NIDyHVy9oSMg8p5Srdp3LtuO70ExPAO9DArVK XiunRKr0f9VV8rSL3eqm8T7/lrafBB5z/hcC+cWYYiosQevwQZ/Oz85aaBmhYiSNqo0w BWDT4rSHTE9WnTESgYbCTv80FJAbaDkioDepuEpc36dBLzSJfQ9290/7j9WpwRVCNZzb f/XtDvKbCePldK3CzE6seisWjv4tTEFK8VHqUJy8i/Dqb7IOFo6BJ8VPJtcafV6NTKHH DfyBxtHMsAd/wNumhAXMkYSEGBBKr2h/l48joFA+Smne9Eabxg96+qrYUQ2hQScGWZE3 j++g== X-Received: by 10.180.206.172 with SMTP id lp12mr8448394wic.11.1368266400925; Sat, 11 May 2013 03:00:00 -0700 (PDT) Received: from camionet.local ([83.228.76.175]) by mx.google.com with ESMTPSA id ge7sm2991677wib.6.2013.05.11.02.59.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 May 2013 02:59:59 -0700 (PDT) Message-ID: <518E169E.4050006@jitsi.org> Date: Sat, 11 May 2013 12:59:58 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnQCDZdzxVJIb1crldcfKLNEnCXYX+Ie/3YWMR4/gi3BJIRbaIVE5/mGGCeKMrAUF3S1KDK Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 10:00:03 -0000 Hey Cullen, On 10.05.13, 23:53, Cullen Jennings (fluffy) wrote: > > I think the security section series underestimates the security > vulnerabilities this introduces. If you think we've missed any specific attacks we'd be happy to add them. > I'm very sad to see the IETF > publishing this at all with anything other than "This is not the > recommended way to solve this problem" and why. Well that's pretty much what we say: In no way does this document try to make a case for HNT or present it as a solution that is somehow better than alternatives such as ICE. The mechanisms described here, popular as they may be, are not necessarily considered best practice or recommended operation. The security considerations section also specifically outlines cases where DoS attacks can be performed even with the use of SRTP: For example, in cases where end-to-end encryption is used it would still be possible for an attacker to hijack a session despite the use of SRTP and perform a denial of service attack. The point was to show that in spite of all the threat mitigating techniques users of latching are still left vulnerable to those. I certainly don't understand IETF processes as well as you do, but it is my understanding that as an informational document the draft can only do so much and that making explicit recommendations for or against technologies was for Standards Track documents only. Am I wrong about this? My recollection of the Paris and Vancouver meetings (and a quick skim through the notes) is that this was also the direction chosen by the WG. Again, if you believe that additional text would make things clearer we are wide open to suggestions. Cheers, Emil > > > > > On May 7, 2013, at 12:29 PM, 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 : Latching: Hosted NAT Traversal (HNT) for Media in >> Real-Time Communication Author(s) : Emil Ivov Hadriel Kaplan >> Dan Wing Filename : draft-ietf-mmusic-latching-01.txt Pages >> : 14 Date : 2013-05-07 >> >> Abstract: This document describes behavior of signalling >> intermediaries in Real-Time Communication (RTC) deployments, >> sometimes referred to as Session Border Controllers (SBCs), when >> performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, >> such as media relaying and latching, that such intermediaries use >> to enable other RTC devices behind NATs to communicate with each >> other. This document is non-normative, and is only written to >> explain HNT in order to provide a reference to the IETF community, >> as well as an informative description to manufacturers, and users. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-mmusic-latching-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-01 >> >> >> 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 > -- https://jitsi.org From stefan.lk.hakansson@ericsson.com Sat May 11 04:50:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927E621F8E94; Sat, 11 May 2013 04:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPCg2FRjRApI; Sat, 11 May 2013 04:50:06 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2F3F21F8E8E; Sat, 11 May 2013 04:50:05 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-a4-518e306c3ccc Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9C.02.28165.C603E815; Sat, 11 May 2013 13:50:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Sat, 11 May 2013 13:50:04 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Paul Kyzivat Thread-Topic: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 Thread-Index: AQHOS2hQZBBwa2OZtEiOSK4AxzMZ0w== Date: Sat, 11 May 2013 11:50:03 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvrW6OQV+gwdpfuhZ7/i5it5i6/DGL xYoNB1gt1v5rZ3dg8fj7/gOTx5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CVseHhEvaCZUIV a360sDUwHuLrYuTkkBAwkTi25xgzhC0mceHeerYuRi4OIYHDjBK9R78wQjhLGCVmrVsGVsUm ECixdd8CoCoODhEBDYlJW9VATGaBXIkv0wJAKoQFvCW2bVgIVi0i4COx/uYhdghbT6Kldwsr iM0ioCpx7dU5MJtXwFfiw5/drBCrpjFJdE5ZxQaSYAQ66PupNUwgNrOAuMStJ/OZIA4VkFiy 5zzU0aISLx//Y4WwlSR+bLjEAlGvJ3Fj6hQ2CFtbYtnC18wQywQlTs58wjKBUXQWkrGzkLTM QtIyC0nLAkaWVYzsuYmZOenlhpsYgZFycMtv3R2Mp86JHGKU5mBREudN4moMFBJITyxJzU5N LUgtii8qzUktPsTIxMEp1cCoI/my++fviee+t79TOVnbeOPCcr6rHuf1WOyXav7NnL5CIDPt WMGpbab6kQVH37+vumKTtcz2lc9X/fuTbLSmuMnfrpsrxvqNjfuu/Fq1+FdxQvf8j02e8v9U 79dp5VeZio7sUBZIcrhzd1axd97+uW2blVPydKUvp2zKuZXy7u4aldu7z8fdUmIpzkg01GIu Kk4EAES/Z81iAgAA Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 11:50:12 -0000 On 5/10/13 11:20 PM, Paul Kyzivat wrote:=0A= > On 5/10/13 2:37 AM, Stefan H=E5kansson LK wrote:=0A= > ...=0A= >> But I can easily think of other situations that would lead to glare for= =0A= >> Plan A.=0A= >>=0A= >> Just as an example, think about a conference scenario with a centralized= =0A= >> node. Now, one of the participants wants to mute her/his audio, and as a= =0A= >> result the audio m-line would go from sendrecv to recvonly. At roughly= =0A= >> the same time the server wants to disable the high res video and enable= =0A= >> the low res video (because this user will be moved, based e.g. on the=0A= >> recent audio activity, from being displayed in the main video window to= =0A= >> be in a thumbnail on the screen of the other participants in the=0A= >> conference), so it wants to manipulate the direction attribute of other= =0A= >> m-lines.=0A= >>=0A= >> So there would be two offers sent at roughly the same time, which means= =0A= >> we would have glare.=0A= >=0A= > What do you mean by "roughly"?=0A= >=0A= > How long does it take to do an O/A exchange that doesn't require human=0A= > input? Presumably less than a second, maybe considerably less. (Or will= =0A= > it be more with RTCWEB and web servers in the path?)=0A= =0A= That sounds right to me.=0A= =0A= >=0A= > What is the probability that the other side, for independent reasons,=0A= > decides to make a change within that interval? (And it isn't really the= =0A= > whole interval - it is only the first part of it.)=0A= =0A= Given that in multiparty services the "main" video changes quite often, =0A= I'd not say this is extremely low. It will happen.=0A= =0A= But, given that there is a way to roll-back in a predictable way I think = =0A= glare resolution could be quick - nothing stops the web application from = =0A= including a random number in every offer, and resolve glare based on =0A= that (one of the offers "win").=0A= =0A= So I think glare will happen in practice (that is what I wanted to point = =0A= out), but it is not a show-stopper provided there is a way to roll back.=0A= =0A= >=0A= > There may indeed be realistic cases for glare, but they will probably be= =0A= > because both changes are keyed to a common event.=0A= >=0A= > Thanks,=0A= > Paul=0A= >=0A= >=0A= =0A= From pkyzivat@alum.mit.edu Sat May 11 09:24:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF9D21F9305 for ; Sat, 11 May 2013 09:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.026 X-Spam-Level: X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WflZJ4aVBuin for ; Sat, 11 May 2013 09:24:20 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id D2A5F21F92EC for ; Sat, 11 May 2013 09:24:11 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id agB01l0010EZKEL5CgQBnP; Sat, 11 May 2013 16:24:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id agQA1l00k3ZTu2S3MgQAyq; Sat, 11 May 2013 16:24:11 +0000 Message-ID: <518E70A9.7070007@alum.mit.edu> Date: Sat, 11 May 2013 12:24:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> 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=1368289451; bh=8UTa6ZJNZGmpimfK6oznzEHlDAk382YzHGooMGsU7bQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VD+4JxlepMZqzi9p57UZbgwphdKePSqMHTOL5+uZUvSjfrjESeJkk3lQV2FNx1+2D P3qX+lE1LcQHzTi1wccWQtuA2WMpy/srkr+AfEmoQo1xYpwnrfyWbT5aR56ATrZUA5 HWCZePkQqOM++G58/bQKls03BJzJ5mGwMYnp7giXoB7Nb2apwbhdOgQ6V5w578NV+C psj7MpRFZBhMMFD3TVRIY4zddoEmsFQT/fCzLFuZAbO4I5uBlsoeZHqSriPjNDC7n1 k94gQzEt9KyX+/vhkhS5fPvNKRHApqnGme8MCeJkdQeoeAexAzZ7DOYoU/xvmNEa5/ fobd8evHAITXg== Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 16:24:26 -0000 On 5/11/13 7:50 AM, Stefan Håkansson LK wrote: > On 5/10/13 11:20 PM, Paul Kyzivat wrote: >> What is the probability that the other side, for independent reasons, >> decides to make a change within that interval? (And it isn't really the >> whole interval - it is only the first part of it.) > > Given that in multiparty services the "main" video changes quite often, > I'd not say this is extremely low. It will happen. Are you thinking that there will be an SDP change every time the speaker changes??? Or do you mean changes when participants join and leave a conference? I would hope there will normally not be SDP changes for either of those events. > But, given that there is a way to roll-back in a predictable way I think > glare resolution could be quick - nothing stops the web application from > including a random number in every offer, and resolve glare based on > that (one of the offers "win"). > > So I think glare will happen in practice (that is what I wanted to point > out), but it is not a show-stopper provided there is a way to roll back. I'm sure it will happen. The question is whether it happens often enough to do more than count on the normal glare recovery procedures. Thanks, Paul From bernard_aboba@hotmail.com Sat May 11 20:17:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5A321F8976; Sat, 11 May 2013 20:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fVuT-+Wqy8K; Sat, 11 May 2013 20:17:41 -0700 (PDT) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF121F8956; Sat, 11 May 2013 20:17:40 -0700 (PDT) Received: from BLU403-EAS154 ([65.55.116.73]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 May 2013 20:17:40 -0700 X-EIP: [7m7o79jdo00ApckqYG1RqbAfzGj/7BIo] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <518D6482.2010008@alum.mit.edu> Date: Sat, 11 May 2013 20:17:35 -0700 To: Paul Kyzivat X-OriginalArrivalTime: 12 May 2013 03:17:40.0567 (UTC) FILETIME=[42BC2670:01CE4EBF] Cc: =?utf-8?Q?Stefan_H=C3=A5kansson_LK?= , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 03:17:46 -0000 PiBPbiA1LzEwLzEzIDI6MzcgQU0sIFN0ZWZhbiBIw6VrYW5zc29uIExLIHdyb3RlOg0KPj4gDQo+ PiANCj4+IEp1c3QgYXMgYW4gZXhhbXBsZSwgdGhpbmsgYWJvdXQgYSBjb25mZXJlbmNlIHNjZW5h cmlvIHdpdGggYSBjZW50cmFsaXplZA0KPj4gbm9kZS4gTm93LCBvbmUgb2YgdGhlIHBhcnRpY2lw YW50cyB3YW50cyB0byBtdXRlIGhlci9oaXMgYXVkaW8sIGFuZCBhcyBhDQo+PiByZXN1bHQgdGhl IGF1ZGlvIG0tbGluZSB3b3VsZCBnbyBmcm9tIHNlbmRyZWN2IHRvIHJlY3Zvbmx5LiBBdCByb3Vn aGx5DQo+PiB0aGUgc2FtZSB0aW1lIHRoZSBzZXJ2ZXIgd2FudHMgdG8gZGlzYWJsZSB0aGUgaGln aCByZXMgdmlkZW8gYW5kIGVuYWJsZQ0KPj4gdGhlIGxvdyByZXMgdmlkZW8gKGJlY2F1c2UgdGhp cyB1c2VyIHdpbGwgYmUgbW92ZWQsIGJhc2VkIGUuZy4gb24gdGhlDQo+PiByZWNlbnQgYXVkaW8g YWN0aXZpdHksIGZyb20gYmVpbmcgZGlzcGxheWVkIGluIHRoZSBtYWluIHZpZGVvIHdpbmRvdyB0 bw0KPj4gYmUgaW4gYSB0aHVtYm5haWwgb24gdGhlIHNjcmVlbiBvZiB0aGUgb3RoZXIgcGFydGlj aXBhbnRzIGluIHRoZQ0KPj4gY29uZmVyZW5jZSksIHNvIGl0IHdhbnRzIHRvIG1hbmlwdWxhdGUg dGhlIGRpcmVjdGlvbiBhdHRyaWJ1dGUgb2Ygb3RoZXINCj4+IG0tbGluZXMuDQo+PiANCj4+IFNv IHRoZXJlIHdvdWxkIGJlIHR3byBvZmZlcnMgc2VudCBhdCByb3VnaGx5IHRoZSBzYW1lIHRpbWUs IHdoaWNoIG1lYW5zDQo+PiB3ZSB3b3VsZCBoYXZlIGdsYXJlLg0KDQpUaGVyZSBhcmUgaW1wbGVt ZW50YXRpb25zIHdoZXJlIG5vIHNpZ25hbGxpbmcgaXMgcmVxdWlyZWQgZm9yIHRoZSBtaXhlciB0 byBnbyBmcm9tIGhpZ2ggcmVzIHRvIGxvd2VyIHJlcy4gRm9yIGV4YW1wbGUsIGlmIHRoZSByZWNl aXZlciBkZWNsYXJlcyB3aGF0IGl0IGNhbiByZWNlaXZlIGFuZCB0aGUgbWl4ZXIgc2VsZWN0cyB0 aGUgc2ltdWxjYXN0IHN0cmVhbSBmb3IgdGhhdCByZWNlaXZlciBiYXNlZCBvbiBjYXBhYmlsaXRp ZXMgYW5kIGNvbmRpdGlvbnMsIHdpdGggdGhlIHN0cmVhbSBwcm9wZXJ0aWVzIGRlY2xhcmVkIGlu IGJhbmQuICA= From stefan.lk.hakansson@ericsson.com Sun May 12 10:18:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E0521F89C3; Sun, 12 May 2013 10:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiPUjp1H-B3P; Sun, 12 May 2013 10:18:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6D09421F87B1; Sun, 12 May 2013 10:18:26 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-85-518fcee0e173 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A0.D6.01956.0EECF815; Sun, 12 May 2013 19:18:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Sun, 12 May 2013 19:18:23 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Paul Kyzivat Thread-Topic: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 Thread-Index: AQHOS2hQZBBwa2OZtEiOSK4AxzMZ0w== Date: Sun, 12 May 2013 17:18:23 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@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.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+Jvre7Dc/2BBpNusVns+buI3WLq8scs Fis2HGC1WPuvnd2BxePv+w9MHkuW/GTymLXzCUsAcxSXTUpqTmZZapG+XQJXxscDF1kK9ohX HL69n72B8YFQFyMnh4SAicSJvgZ2CFtM4sK99WxdjFwcQgKHGSXaV35lgXCWMErsur8GrIpN IFBi674FQFUcHCICGhKTtqqBmMwCuRJfpgWAVAgLeEts27CQGcQWEfCRWH/zEDuErSfR0ruF FcRmEVCVeDHlFwuIzSvgK9G75wkzxKo/TBJTV1wBSzACHfT91BomEJtZQFzi1pP5TBCHCkgs 2XOeGcIWlXj5+B8rhK0k0bjkCStEvZ7EjalT2CBsbYllC18zQywTlDg58wnLBEbRWUjGzkLS MgtJyywkLQsYWVYxsucmZuakl5tvYgRGysEtvw12MG66L3aIUZqDRUmcN5mrMVBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QD45ElIffzDFW9dpk9L163UCD8w9Mezgibit+RUZK7q358WvXm xKtzh1603bJimBlnUblbsjl48gGD3L/af+SvOzSul/3x7GpGrQOb+7dE0/r8vpdqpxcpz75b bFg1RSZt87lbySobTuQv5Qr+n/Q/P6Qw6HAE487g3c2FHOtY0qY0WlaIfpU9rMRSnJFoqMVc VJwIAJEdk61iAgAA Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 17:18:33 -0000 On 5/11/13 6:24 PM, Paul Kyzivat wrote:=0A= > On 5/11/13 7:50 AM, Stefan H=E5kansson LK wrote:=0A= >> On 5/10/13 11:20 PM, Paul Kyzivat wrote:=0A= >=0A= >>> What is the probability that the other side, for independent reasons,= =0A= >>> decides to make a change within that interval? (And it isn't really the= =0A= >>> whole interval - it is only the first part of it.)=0A= >>=0A= >> Given that in multiparty services the "main" video changes quite often,= =0A= >> I'd not say this is extremely low. It will happen.=0A= >=0A= > Are you thinking that there will be an SDP change every time the speaker= =0A= > changes???=0A= >=0A= > Or do you mean changes when participants join and leave a conference?=0A= =0A= I meant the former (at speaker change).=0A= =0A= I guess that different designs can be chosen for media from central node = =0A= to end-user clients, and some of them (as Bernard pointed out) would not = =0A= require any signaling. Still, there might be cases where signaling is =0A= needed.=0A= =0A= But leaving that aside, we still have the case of the media end-user =0A= client -> central node. If you're serious about not wasting bandwidth =0A= (and with my radio/mobile background I am sort of obsessed :-) ) all =0A= end-user clients which do not end up as main video anywhere should only =0A= transmit a low resolution video. So at every speaker change there would =0A= be at least one client that is asked to stop sending high resolution and = =0A= only transmit low resolution, and one client that is asked to start =0A= transmitting high resolution video.=0A= =0A= I think that this would best be done using some RTCP signaling scheme, =0A= but I also think there was an agreement a long time ago that SDP O/A =0A= should be used. In this case either to transmit a new imageattr value =0A= requesting another resolution, or to pause/resume - using recv on/off in = =0A= Plan B or the direction attribute in Plan A - the low and high =0A= resolution simulcast streams accordingly (or I assume to pause/resume =0A= the enhancement layers if a scalable codec is used).=0A= =0A= >=0A= > I would hope there will normally not be SDP changes for either of those= =0A= > events.=0A= =0A= I would like to avoid them too, but I'm not sure how.=0A= =0A= >=0A= >> But, given that there is a way to roll-back in a predictable way I think= =0A= >> glare resolution could be quick - nothing stops the web application from= =0A= >> including a random number in every offer, and resolve glare based on=0A= >> that (one of the offers "win").=0A= >>=0A= >> So I think glare will happen in practice (that is what I wanted to point= =0A= >> out), but it is not a show-stopper provided there is a way to roll back.= =0A= >=0A= > I'm sure it will happen. The question is whether it happens often enough= =0A= > to do more than count on the normal glare recovery procedures.=0A= >=0A= > Thanks,=0A= > Paul=0A= >=0A= >=0A= =0A= From emcho@sip-communicator.org Sun May 12 11:29:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23DB21F89AF for ; Sun, 12 May 2013 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPiNTTvgeaXK for ; Sun, 12 May 2013 11:29:11 -0700 (PDT) Received: from mail-da0-x232.google.com (mail-da0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD621F8916 for ; Sun, 12 May 2013 11:29:11 -0700 (PDT) Received: by mail-da0-f50.google.com with SMTP id i23so3145540dad.23 for ; Sun, 12 May 2013 11:29:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=7gkTSk+96Pf79o0bHvtoQjoAuejxtwvY7WTKpfeK5jo=; b=kir6MBTsABysV9swgfFofbtLn9Xfih56feNq2yXwD/FmX/qDbnI22oyn+6MNA9yzeE xbB1NvGYVrjo5OvW2UoCchXYFlwlqkt2M9qDBAas9DN1OkFRd6apwOR+39WVKg5S7v10 9LGIF3IUeC/10gFsyDGUFYYQNEp9rSit34ndbzyMn/3qHA1dUJEhwu/lr88ZWPmWAJgn E+wdtR00bWQPx21yyls8Wmh0vaHKAI+T3VhpGPisT7xb3c271jUXdG1wegJpQvzriKY6 mdh7Y9WQE4JqQAJ1NrEZvJsTrYh7+ppUZm1qkRzs1fCiVW/E1+vflycXIp8aK4v/PiLn lNjQ== X-Received: by 10.68.212.35 with SMTP id nh3mr26065043pbc.40.1368383351552; Sun, 12 May 2013 11:29:11 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [2607:f8b0:400e:c01::22d]) by mx.google.com with ESMTPSA id sq9sm11686214pab.5.2013.05.12.11.29.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 11:29:11 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so2001390pbc.4 for ; Sun, 12 May 2013 11:29:10 -0700 (PDT) X-Received: by 10.66.216.198 with SMTP id os6mr26211752pac.145.1368383350836; Sun, 12 May 2013 11:29:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.229.68 with HTTP; Sun, 12 May 2013 11:28:50 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> From: Emil Ivov Date: Sun, 12 May 2013 21:28:50 +0300 Message-ID: To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkcFfbUtPgja7iWeSDAq3gw68gknbHSA777KJI2h5olbILu5C6gTcbJgXXrDzkCKsdgjNOS Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 18:29:12 -0000 On Sun, May 12, 2013 at 8:18 PM, Stefan H=E5kansson LK wrote: > On 5/11/13 6:24 PM, Paul Kyzivat wrote: >> On 5/11/13 7:50 AM, Stefan H=E5kansson LK wrote: >>> On 5/10/13 11:20 PM, Paul Kyzivat wrote: >> >>>> What is the probability that the other side, for independent reasons, >>>> decides to make a change within that interval? (And it isn't really th= e >>>> whole interval - it is only the first part of it.) >>> >>> Given that in multiparty services the "main" video changes quite often, >>> I'd not say this is extremely low. It will happen. >> >> Are you thinking that there will be an SDP change every time the speaker >> changes??? >> >> Or do you mean changes when participants join and leave a conference? > > I meant the former (at speaker change). > > I guess that different designs can be chosen for media from central node > to end-user clients, and some of them (as Bernard pointed out) would not > require any signaling. Still, there might be cases where signaling is > needed. Right, however in cases where signalling is indeed needed, should it really be defined by RTCWEB rather than the application developer? > But leaving that aside, we still have the case of the media end-user > client -> central node. If you're serious about not wasting bandwidth > (and with my radio/mobile background I am sort of obsessed :-) ) all > end-user clients which do not end up as main video anywhere should only > transmit a low resolution video. So at every speaker change there would > be at least one client that is asked to stop sending high resolution and > only transmit low resolution, and one client that is asked to start > transmitting high resolution video. > > I think that this would best be done using some RTCP signaling scheme, RTCP is just one of the possibilities. This could also be implemented in a number of other ways that would all be more efficient for the specific application and all out-of-scope for rtcweb. > but I also think there was an agreement a long time ago that SDP O/A > should be used. Well the way I remember it SDP O/A was chosen for session negotiation and that other forms of signalling were explicitly left out of the charter. > In this case either to transmit a new imageattr value imageattr is great as a declarative parameter indicating capabilities: "I can't show more than 720p so there's no point to send me more than that". Using it as a way to switch between thumbnail and HQ videos is not entire impossible but is not particularly efficient either. > requesting another resolution, or to pause/resume - using recv on/off in > Plan B or the direction attribute in Plan A - the low and high > resolution simulcast streams accordingly (or I assume to pause/resume > the enhancement layers if a scalable codec is used). > >> >> I would hope there will normally not be SDP changes for either of those >> events. > > I would like to avoid them too, but I'm not sure how. Well we can either figure that out (and it seems that we can't quite agree on a solution) or make sure APIs have all it takes for the matter to be resolved by app-to-app signalling. Emil -- https://jitsi.org From gunnar.hellstrom@omnitor.se Sun May 12 14:20:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266321F8C9B for ; Sun, 12 May 2013 14:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMTGjf+6rF7d for ; Sun, 12 May 2013 14:20:08 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 49EE321F8C40 for ; Sun, 12 May 2013 14:20:05 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sun, 12 May 2013 23:19:53 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 5C6453A00B for ; Sun, 12 May 2013 23:19:53 +0200 (CEST) Message-ID: <5190077C.9010009@omnitor.se> Date: Sun, 12 May 2013 23:19:56 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <515063C3.3040700@alum.mit.edu> <5150A8CE.1030504@omnitor.se> In-Reply-To: <5150A8CE.1030504@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 21:20:13 -0000 Did we get to any workable conclusions on this? /Gunnar On 2013-03-25 20:43, Gunnar Hellstrom wrote: > On 2013-03-25 15:48, Paul Kyzivat wrote: >> I think you need to distinguish two cases here: >> >> - both ends understand and use the language negotiation mechanism, >> and there is a mismatch between what is desired and what is >> required. > Yes, > This could first lead to an effort to route the call to an endpoint > that has declared more suitable language and modality preferences and > capabilities. > > Secondly it can lead to addition of a relay service or translation > service if one of the parties has access to such services. It can be > added in a three-party call fashion, translating languages or > modalities as needed. >> >> - one end is using this language negotiation mechanism, and has >> expressed certain requirements, but the other end doesn't >> understand and isn't using the mechanism. > Yes, > this will sadly be a common case. > The one who use the mechanism need to make assumptions. > One obvious assumption is that audio media capability alone will mean > capability and preference for spoken language, > So if the other user prefers other media and modalities, there is a > need for relay services that need to be invoked. > Spoken language interpreting service need will be harder to detect. > > If the one who is not using the mechanism is declaring audio and text > media capabilities, it will be harder to select what to do. > If the one supporting the mechanism also support audio and text, a > direct connection could be tried, hoping that they can get along with > either speaking or typing or mixing these modalities as they wish. > > If the one who is not using the mechanism is declaring audio, video > and text media capabilities, and the one supporting the mechanism also > support these three media, it is also hard to select what to do. > The one supporting the mechanism may prefer to use sign language. > Having no indication why the other party declares video capability, it > may be risky to just connect them. > It might be best to include a sign relay service in the call. > But that might be not needed and just disturbing and resource > consuming if both parties know the same sign languages. > > So, yes, there are many use case variations that need to be captured > and best approach described. >> >> >> In the first case it may make sense to fail the call. In the other >> case it probably does not. >> >> Callerprefs has tried to deal with this, though the mechamism for >> doing so it rather obscure. If there is a desire to deal with this at >> the SDP level then it will take some work to do so. > Yes, it is tempting to try to reuse the callerprefs mechanism. > I had hoped that the implicit preference evaluation could have > included capabilities declared in SDP, but it is not. So, right now > there is no link between the callerpref methods and a new definition > is needed of how the language and modality capabilities and preference > expressions in SDP can be evaluated and acted on. > > > /Gunnar >> Thanks, >> Paul >> >> On 3/17/13 3:54 AM, Hadriel Kaplan wrote: >>> >>> On Mar 15, 2013, at 2:49 PM, Randall Gellens >>> wrote: >>> >>>> SDP or SIP: >>>> - Use SDP for actual negotiation, but use SIP header to provide a hint >>>> - Emergency services use case can use SDP for policy >>>> routing/handling decisions >>>> - Other use cases may or may not have ability/desire to use SDP for >>>> this and can use the SIP header hint >>> >>> Another reason not to only put it in SDP is the delayed-offer scenario. >>> >>> >>>> Directionality of SDP attributes: >>>> - Define two new SDP media-level attributes: 'send-lang' and >>>> 'recv-lang'. In an offer, send-lang is a list in preference order >>>> of the languages the offerer wishes to send and recv-lang is a list >>>> in preference order of the languages the offerer wishes to >>>> receive. In most cases these are expected to have the same value, >>>> because otherwise it is harder to match desired resources. In an >>>> answer, send-lang is the accepted language the answerer will send >>>> (which in most cases should be one of the languages in the offer's >>>> recv-lang) and recv-lang is the accepted language the answerer >>>> expects to receive (which in most cases should be one of the >>>> languages in the offer's send-lang). >>> >>> What's the use-case when the two directions are not identical? I.e., >>> when does it make sense to receive Latin but send Swahili for the >>> same media? >>> I ask because this separation complicates things quite a bit in >>> code/testing/error-handling, obviously. >>> >>> >>>> Advisory vs Required: >>>> - Does call fail if no common language? >>> >>> I haven't thought about this draft's scenarios much, but think we >>> need to think about this very carefully. Otherwise the outcome >>> would be SBCs would strip it from the INVITE, just to avoid failing >>> the call. I don't think anyone would actually want such calls to >>> truly fail for the end user - not just for Emergency calls, but for >>> any calls - people can always hang up if they don't like what they >>> hear/see. ISTM that there's a high likelihood of this language >>> value actually being *wrong* in either the sender or receiver or >>> both, so I think failing the call because of a mismatch would be >>> really bad. >>> >>> At first glance, I can see one and only one reason failing it would >>> make sense: for a serial-forking proxy/B2BUA/UA to be able to >>> recurse to alternate targets if the first one didn't support the >>> language(s). But it has a very negative drawback: if there are no >>> more targets it can recurse to, or if there were no such forking to >>> begin with, the call fails. Then we're back to square one above, >>> and the thing gets removed from all calls by middleboxes, just to >>> avoid such cases. >>> >>> -hadriel >>> p.s. was this presented in MMUSIC this past week? For some reason >>> this topic was neither on the MMUSIC agenda pages >>> (http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic), nor in >>> the meeting materials >>> (https://datatracker.ietf.org/meeting/86/materials.html), nor is the >>> draft on the MMUSIC tools page (http://tools.ietf.org/wg/mmusic/). >>> I only mention this because I was looking for the slides and draft >>> today and didn't find them. >>> >>> _______________________________________________ >>> 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 stefan.lk.hakansson@ericsson.com Mon May 13 00:21:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6925221F923C; Mon, 13 May 2013 00:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ybvIUaeVjnw; Mon, 13 May 2013 00:21:51 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DB2E621F9234; Mon, 13 May 2013 00:21:50 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-61-5190948a0093 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6D.09.01956.A8490915; Mon, 13 May 2013 09:21:46 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 13 May 2013 09:21:46 +0200 Message-ID: <5190948A.5070707@ericsson.com> Date: Mon, 13 May 2013 09:21:46 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+JvrW7XlAmBBp/n6Vms2TmBxWLq8scs Fis2HGC1WPuvnd2BxePv+w9MHkuW/GTy+P8mMIA5issmJTUnsyy1SN8ugStj4q6pzAV/lCve /T3F3MB4TqaLkZNDQsBEovfGFlYIW0ziwr31bCC2kMApRol/Jzy7GLmA7LVA9pp+RpAEr4C2 xJb7p5i6GDk4WARUJU4fFgIJswkESlz//4sJxBYViJL493Y3VLmgxMmZT1hAbBEBeYnutkVg NcwC5RKnL30Hs4UFvCW2bVjIDLH3O7NE9+EUEJsTaOb0m8+g6m0lLsy5zgJhy0s0b50NVa8r 8e71PdYJjIKzkKybhaRlFpKWBYzMqxjZcxMzc9LLzTcxAoP14JbfBjsYN90XO8QozcGiJM6b zNUYKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR+tp1373dbxw8AtyyHMu/Tzs2s6x1bnRr bZ3Q3xvrShSUdC4k19wLL1zkLLk39VB82pmjvnN/b/189omtTtyM8vkTFgR9LjjJO4vRKXHd m4Z/L7ntBVPtTA8ese9Vejtp+oHlxsc3aHs+l7pgs2jdSf3bO6ZPc3e+lpwesVltXdlaG7WE fhdhJZbijERDLeai4kQAFV5HUiQCAAA= Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 07:21:56 -0000 On 2013-05-12 20:28, Emil Ivov wrote: > On Sun, May 12, 2013 at 8:18 PM, Stefan Håkansson LK > wrote: >> On 5/11/13 6:24 PM, Paul Kyzivat wrote: >>> On 5/11/13 7:50 AM, Stefan Håkansson LK wrote: >>>> On 5/10/13 11:20 PM, Paul Kyzivat wrote: >>> >>>>> What is the probability that the other side, for independent reasons, >>>>> decides to make a change within that interval? (And it isn't really the >>>>> whole interval - it is only the first part of it.) >>>> >>>> Given that in multiparty services the "main" video changes quite often, >>>> I'd not say this is extremely low. It will happen. >>> >>> Are you thinking that there will be an SDP change every time the speaker >>> changes??? >>> >>> Or do you mean changes when participants join and leave a conference? >> >> I meant the former (at speaker change). >> >> I guess that different designs can be chosen for media from central node >> to end-user clients, and some of them (as Bernard pointed out) would not >> require any signaling. Still, there might be cases where signaling is >> needed. > > Right, however in cases where signalling is indeed needed, should it > really be defined by RTCWEB rather than the application developer? > >> But leaving that aside, we still have the case of the media end-user >> client -> central node. If you're serious about not wasting bandwidth >> (and with my radio/mobile background I am sort of obsessed :-) ) all >> end-user clients which do not end up as main video anywhere should only >> transmit a low resolution video. So at every speaker change there would >> be at least one client that is asked to stop sending high resolution and >> only transmit low resolution, and one client that is asked to start >> transmitting high resolution video. >> >> I think that this would best be done using some RTCP signaling scheme, > > RTCP is just one of the possibilities. This could also be implemented > in a number of other ways that would all be more efficient for the > specific application and all out-of-scope for rtcweb. > >> but I also think there was an agreement a long time ago that SDP O/A >> should be used. > > Well the way I remember it SDP O/A was chosen for session negotiation > and that other forms of signalling were explicitly left out of the > charter. I took the result of the discussion and poll at the IETF-84 (http://tools.ietf.org/wg/rtcweb/minutes?item=minutes-84-rtcweb.html) as an indication of that SDP O/A should be used for this kind of in-session changes as well. > >> In this case either to transmit a new imageattr value > > imageattr is great as a declarative parameter indicating capabilities: > "I can't show more than 720p so there's no point to send me more than > that". Using it as a way to switch between thumbnail and HQ videos is > not entire impossible but is not particularly efficient either. To me it looks like a solution that people might feel inclined towards using. But there are others that want to use simulcast, and then pause/resume sending of high and low resolution streams, and that problem is more or less the same when it comes to signaling. And even if we omitted the possibility for a receiver to indicate to the sender (via standardized signaling) that it should pause or resume sending, and instead left that up to an API (at sender side) and proprietary signaling, we still have to have some kind of signaling IMO: the sender can not just stop sending RTP packets, there need to be a signal to the receiver so it understands this (and does not think there are extreme packet losses or some other errors) and can indicate to the application at the receiving end (in WebRTC it should result in a "mute" event being fired on the PC-track in question). I think the current assumption is SDP O/A for that kind of signaling. > >> requesting another resolution, or to pause/resume - using recv on/off in >> Plan B or the direction attribute in Plan A - the low and high >> resolution simulcast streams accordingly (or I assume to pause/resume >> the enhancement layers if a scalable codec is used). >> >>> >>> I would hope there will normally not be SDP changes for either of those >>> events. >> >> I would like to avoid them too, but I'm not sure how. > > Well we can either figure that out (and it seems that we can't quite > agree on a solution) or make sure APIs have all it takes for the > matter to be resolved by app-to-app signalling. > > Emil > > -- > https://jitsi.org > From christer.holmberg@ericsson.com Mon May 13 00:27:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22D721F92F4 for ; Mon, 13 May 2013 00:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OKQHJYtr5OI for ; Mon, 13 May 2013 00:27:24 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EA48F21F92B2 for ; Mon, 13 May 2013 00:27:23 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-51-519095da21e5 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 95.A9.28165.AD590915; Mon, 13 May 2013 09:27:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Mon, 13 May 2013 09:27:22 +0200 From: Christer Holmberg To: Paul Kyzivat , Jonathan Lennox Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: Ac5H/Rv/zjNZSPPjTceQWRJyHaV9rQFtnnqAAAGLCAAAAGP9gAAACH4AAABFcQAAAKtdAAAEBdGAAHbqqsA= Date: Mon, 13 May 2013 07:27:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> In-Reply-To: <518D9361.7060301@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre6tqRMCDa7vM7LYv/g8s8XU5Y9Z LFZsOMDqwOzx9/0HJo8lS34yebQ9u8MewBzFZZOSmpNZllqkb5fAlXHrzT2mgm6uit875rM1 MH5h72Lk5JAQMJHYdmgiM4QtJnHh3no2EFtI4DCjxN2FGV2MXED2EkaJlS83M3YxcnCwCVhI dP/TBqkREfCT2PLuFxtImFlAXeLq4iCQsDBQxYdDi1lAwiIClhKr73tBVCdJzPg1HWwri4Cq xKTHXWAlvAK+EtPPJEIsusMs8XxfDyNIDaeAjsTnrt9glzECXfb91BomEJtZQFzi1pP5TBAX C0gs2XMe6npRiZeP/7FC2IoS7U8bGCHqdSQW7P7EBmFrSyxb+BqsnldAUOLkzCcsExjFZiEZ OwtJyywkLbOQtCxgZFnFyJ6bmJmTXm64iREYMQe3/NbdwXjqnMghRmkOFiVx3iSuxkAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjAzVU7otMoWDvafYmj0KLH1mW585We/hg2U3DT81hax3 yNexTRHy+eXVfGg+/6WwTxE+Cv7rXu3Iv6QR1ZKmleEiPaF42r7C6kwmz/O7n/GmTOvuX2p6 kSHDOk5038wFHx/bnGY3YPq9oLe8ZcWsY3nnaqTeMPDPmFed3u216nFMSbTKnqo3SizFGYmG WsxFxYkAhyosWGYCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 07:27:29 -0000 Hi, So, assuming we are going to update RFC 5888 (whatever the exact wording wo= uld be), would we do that within draft-bundle, or within a separate documen= t? Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: 11. toukokuuta 2013 3:40 To: Jonathan Lennox Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions On 5/10/13 6:44 PM, Jonathan Lennox wrote: >>> I struggled to find it too. It's in 9.2: >>> >>> SIP entities refuse media streams by setting the port to zero i= n the >>> corresponding "m" line. "a=3Dgroup" lines MUST NOT contain >>> identification-tags that correspond to "m" lines with the port >>> set to >>> zero. >>> >>> >>> This feels like something we could relax for the offer. >> >> We could relax it. The question is if the change will break any=20 >> existing use. That is a hard question to answer. > > We could say that whether it's valid must be defined by the group semanti= c, and for all existing group semantics it's not. WFM _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon May 13 00:44:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3E721F8F2C for ; Mon, 13 May 2013 00:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P0MFTPao+SU for ; Mon, 13 May 2013 00:44:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1812021F8FB3 for ; Mon, 13 May 2013 00:44:42 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-82-519099e9ad09 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F4.5D.01956.9E990915; Mon, 13 May 2013 09:44:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Mon, 13 May 2013 09:44:41 +0200 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE: Accept m- line, reject bundle Thread-Index: Ac5H/igNZNDXoaDWRAK0EIjSzLXMBAFsKRmAAAA/VAAAAloCAAAAb1CAAHyM8UA= Date: Mon, 13 May 2013 07:44:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36EC5C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> <518D6E48.5060700@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre6rmRMCDf51c1hcO/OP0WLq8scs Fis2HGB1YPb4+/4Dk8fOWXfZPZYs+ckUwBzFZZOSmpNZllqkb5fAlbHy7wbWgi1sFbM3pjUw zmbtYuTgkBAwkdj6SKGLkRPIFJO4cG89WxcjF4eQwGFGiT+fOtkhnCWMEh9WXGYDaWATsJDo /qcN0iAiECrRdnEfI0iYWUBd4uriIJCwsIC1xLx3B1kgSmwkbu4/zgxh+0m83fwBzGYRUJVY fXM1E4jNK+Arce7cEkaIVQeYJD4e7QEr4hQIlFi7YzEbiM0IdNz3U2vAGpgFxCVuPZnPBHG0 gMSSPeeZIWxRiZeP/7FC2IoS7U8bGCHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrNQjJ2 FpKWWUhaZiFpWcDIsoqRPTcxMye93HwTIzBmDm75bbCDcdN9sUOM0hwsSuK8yVyNgUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYlbe0W0xONjiR1r1pw6yU5yGLggOT/D9ud/pytOnkir8J Ap6J65/Kfd7ouveb13H+WxXi+d5/ZE2PBxclfL+1rV8oj7Hnm3dGSOCnq0d2sf9zZNE7zXvv wNMD+2cvrzicPLHltFeBfuRrxSxf3rN8+7b9yOZYW7flst/2vZmZH3aUrJMyVn22VImlOCPR UIu5qDgRALnAhAJnAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 07:44:54 -0000 Hi, Ok, so the outcome seems to be that we allow Alt 1 as long as the rejected = m- lines in the offer contains unique port numbers. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Martin Thomson Sent: 11. toukokuuta 2013 1:14 To: Paul Kyzivat Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle On 10 May 2013 15:01, Paul Kyzivat wrote: > Alt 1 is better in cases when you can use it. Alt 3 should work when=20 > Alt 1 won't. I envision no cases when Alt 2 is useful, but I see no=20 > reason to ban it. I agree. A good summary. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Mon May 13 01:03:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E6721F9195; Mon, 13 May 2013 01:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.784 X-Spam-Level: X-Spam-Status: No, score=-100.784 tagged_above=-999 required=5 tests=[AWL=5.466, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmp+bwnJXxYT; Mon, 13 May 2013 01:03:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA521F8D84; Mon, 13 May 2013 01:03:05 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-0d-51909e380163 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 52.76.32006.83E90915; Mon, 13 May 2013 10:03:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 13 May 2013 10:03:04 +0200 Message-ID: <51909E36.9050407@ericsson.com> Date: Mon, 13 May 2013 10:03:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> In-Reply-To: <201304261820.r3QIKq913501941@shell01.TheWorld.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvra7FvAmBBv2bxS2mLn/MYnHp4lkm i5cnyhyYPSbv/8rssWTJT6YApigum5TUnMyy1CJ9uwSujIuznrAVXJGp2L3hMUsD4zSxLkZO DgkBE4ntt16wQNhiEhfurWfrYuTiEBI4xShxdNdyZghnOaPE9507WbsYOTh4BbQlutcIgDSw CKhKXF81DayZTcBC4uaPRjaQElGBYImtrTEgYV4BQYmTM5+wgIRFBDQlOhbkgISZgTq/vn/I DhIWFvCV2PxVDiQsJPCZUeLNBwOQMKeAg8Tz7wEQh0lKbHnRzg7RqScx5WoLI4QtL9G8dTYz RKu2RENTB+sERqFZSPbOQtIyC0nLAkbmVYzsuYmZOenlRpsYgaF6cMtv1R2Md86JHGKU5mBR EudN5moMFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAYefgQw/uN3U7bnnnEi3W7XngsJTb5 zxKfJdYWW3fM//ku+Ynlrk0RgXz5ulOvVwTkCos6GgpMbnPpW9q051DkugDmE/wnb7C81Lqw 9vvN2qtxu3j2/jY2+b6SPztn37K8zwHfNjzL/jwh8P5H22039smU+D/8eLw1ucB51YJgIUOD J7vKi7/8UmIpzkg01GIuKk4EAD41rMMjAgAA Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 08:03:14 -0000 Dale, Ok, I think you have convinced me that there is a point in updating or at least clarifying the registry. However, I think it is important that one makes clear the difference between using RTP/RTCP MUX and not. The considerations for doing static allocations which was this registries original purpose and the the usage of dynamic PT assignments with and without RTP/RTCP MUX is quite different. >From my perspective I don't see major issues to use all 128 values of PT field if needed when doing dynamic allocation and not using RTP/RTCP MUX. Yes, I would use the one that collide with SR/RR RTCP packets last, but I still would use them. The thing that is getting screwed up are classifier filters, not the actual end-points. Clearly if using RTP/RTCP MUX you need to avoid the PT values corresponding to RTCP packets types in use. Especially if reduced size RTCP is used. I also think you should check with IANA if one can touch a closed registry at all, or if we are restricted to clarifying notes for the registry. Cheers Magnus On 2013-04-26 20:20, Dale R. Worley wrote: >> From: Magnus Westerlund >> >> Regarding the IANA, Mo you have correctly identified the registry as >> closed and Adam pointed to the relevant text. Is this level of >> indirection so problematic that this registry needs a Note to the effect? > > (cleaning up my proposal) > > I use the IANA registries as the reference for how the various number > spaces are managed. The current final rows of the Payload Types table > read: > > 35-71 Unassigned > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Unassigned > 96-127 dynamic [RFC3551] > > I find these to be problematic in several ways: > > 1) RFC 5761 is not mentioned at all, despite that it provides > important modifications of the governing text in RFC 3551. This is a > practical problem: Note that Adam quoted the text in RFC 3551, not > the text in RFC 5761, and the 3551 text is now incorrect. > > 2) The range that is reserved for RTCP avoidance is not specified > correctly. It's true that the rest of the RTCP avoidance range is > marked "Unassigned", but in the context of RFC 3551, that suggests > that they can be used as a secondary dynamic assignment area. > > 3) The range 35-71 should be marked more clearly as the secondary > dynamic assignment area. > > Because of this, I suggest the following changes to this registry: > > 1) The "Reference" section should be changed from "[RFC3551]" to > "[RFC5761][RFC3551]". > > 2) The final rows should be changed to > > 35-63 Unassigned/secondary dynamic area [RFC5761] > 64-71 Reserved for RTCP conflict avoidance [RFC5761] > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Reserved for RTCP conflict avoidance [RFC5761] > 96-127 Dynamic [RFC3551] > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Mon May 13 01:46:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CB621F92F4; Mon, 13 May 2013 01:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.567 X-Spam-Level: * X-Spam-Status: No, score=1.567 tagged_above=-999 required=5 tests=[AWL=4.166, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oilvrP2zspXG; Mon, 13 May 2013 01:46:48 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6979321F9347; Mon, 13 May 2013 01:46:47 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ey16so655943wid.5 for ; Mon, 13 May 2013 01:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=iXKwtxnTPiI2xxXBpSymcVg5qcSq7NWo+elt09Koacs=; b=QczqhHcknho4ql9YvyzBr6JMUn8ohLVtVg3JRnUEd4FWeEheILfcG9UEzCXGafSbWr 9Jt1i1+hh9WVznXmQBRhBv5V5BC65x9f25QffOw/wy808wNZMA9EgRrXDq2t6FmdStAC e8n+UM4GZdnQnFfUxxAUEZcV2fI34Thtog8K3hLy/O8W7gkG9exs6W3dPk5ibiKAMLvN uDXariX/Xr7bnnK4kZk6SjNTPMClEJ71m9nf8WJobCngyrkdxWoN5H1Ws6tUiuHb9izd on2Tlq4ZOpqSaUQGkTew6RGaPmlqOrwAAQKSehIgL73dNbvjfTY28IFafTrA7fci9VbV iDhQ== X-Received: by 10.180.90.70 with SMTP id bu6mr17072329wib.34.1368434806557; Mon, 13 May 2013 01:46:46 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id ay7sm6551238wib.9.2013.05.13.01.46.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 May 2013 01:46:45 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Dale R. Worley'" References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> In-Reply-To: <51909E36.9050407@ericsson.com> Date: Mon, 13 May 2013 11:45:51 +0300 Message-ID: <008d01ce4fb6$47860250$d69206f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHhSi4rMF59GtWVZLm6eUv/wmHmTAG3YjvyAXHa8loCRvWqfgHvq+67AYZd+3eYlaWWgA== Content-Language: en-us Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 08:46:48 -0000 Hi, I am also concerned about putting in the registries the different case = where RTCP mux is used or not. I think the best we can do is add a general = note in the registry point at RFC5761 saying that it provides clarification on = using the pt type numbers in different cases. Roni -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Magnus Westerlund Sent: 13 May, 2013 11:03 AM To: Dale R. Worley Cc: mmusic@ietf.org; payload@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? Dale, Ok, I think you have convinced me that there is a point in updating or = at least clarifying the registry. However, I think it is important that one makes clear the difference between using RTP/RTCP MUX and not. The considerations for doing static allocations which was this registries original purpose and the the usage of dynamic PT assignments with and without RTP/RTCP MUX is quite different. >From my perspective I don't see major issues to use all 128 values of PT field if needed when doing dynamic allocation and not using RTP/RTCP = MUX. Yes, I would use the one that collide with SR/RR RTCP packets last, but = I still would use them. The thing that is getting screwed up are = classifier filters, not the actual end-points. Clearly if using RTP/RTCP MUX you need to avoid the PT values = corresponding to RTCP packets types in use. Especially if reduced size RTCP is used. I also think you should check with IANA if one can touch a closed = registry at all, or if we are restricted to clarifying notes for the registry. Cheers Magnus On 2013-04-26 20:20, Dale R. Worley wrote: >> From: Magnus Westerlund >> >> Regarding the IANA, Mo you have correctly identified the registry as=20 >> closed and Adam pointed to the relevant text. Is this level of=20 >> indirection so problematic that this registry needs a Note to the = effect? >=20 > (cleaning up my proposal) >=20 > I use the IANA registries as the reference for how the various number=20 > spaces are managed. The current final rows of the Payload Types table > read: >=20 > 35-71 Unassigned > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Unassigned > 96-127 dynamic [RFC3551] >=20 > I find these to be problematic in several ways: >=20 > 1) RFC 5761 is not mentioned at all, despite that it provides=20 > important modifications of the governing text in RFC 3551. This is a=20 > practical problem: Note that Adam quoted the text in RFC 3551, not=20 > the text in RFC 5761, and the 3551 text is now incorrect. >=20 > 2) The range that is reserved for RTCP avoidance is not specified=20 > correctly. It's true that the rest of the RTCP avoidance range is=20 > marked "Unassigned", but in the context of RFC 3551, that suggests=20 > that they can be used as a secondary dynamic assignment area. >=20 > 3) The range 35-71 should be marked more clearly as the secondary=20 > dynamic assignment area. >=20 > Because of this, I suggest the following changes to this registry: >=20 > 1) The "Reference" section should be changed from "[RFC3551]" to=20 > "[RFC5761][RFC3551]". >=20 > 2) The final rows should be changed to >=20 > 35-63 Unassigned/secondary dynamic area [RFC5761] > 64-71 Reserved for RTCP conflict avoidance [RFC5761] > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Reserved for RTCP conflict avoidance [RFC5761] > 96-127 Dynamic [RFC3551] >=20 > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon May 13 04:48:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABBE21F9552 for ; Mon, 13 May 2013 04:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.95 X-Spam-Level: X-Spam-Status: No, score=-4.95 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9CJlY25SxCH for ; Mon, 13 May 2013 04:48:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 784E821F9540 for ; Mon, 13 May 2013 04:48:43 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-4f-5190d31a3d4f Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EB.DB.01956.A13D0915; Mon, 13 May 2013 13:48:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Mon, 13 May 2013 13:48:41 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , Jonathan Lennox Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: Ac5H/Rv/zjNZSPPjTceQWRJyHaV9rQFtnnqAAAGLCAAAAGP9gAAACH4AAABFcQAAAKtdAAAEBdGAAHbqqsAACNG68A== Date: Mon, 13 May 2013 11:48:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36F1EB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36EC03@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra7U5QmBBmd3y1rsX3ye2WLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPNqe3WEPYI7isklJzcksSy3St0vgyji/+hZbwXnBioW9T1ka GN/zdjFyckgImEh83/6bBcIWk7hwbz1bFyMXh5DAYUaJs+23WCGcJYwSfRfambsYOTjYBCwk uv9pgzSICLQwSryaaAoSZhZQl7i6OAgkLAxU8eHQYhaQsIiApcTq+14Q1VkSnzZuZAOxWQRU JeZPW8kOYvMK+EpMu7IOatMCFonrbycxgiQ4Bfwkphy9AWYzAt32/dQaJhCbWUBc4taT+UwQ NwtILNlznhnCFpV4+fgfK4StKNH+tIERol5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj2Cwk Y2chaZmFpGUWkpYFjCyrGNlzEzNz0svNNzECo+bglt8GOxg33Rc7xCjNwaIkzpvM1RgoJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgbHw9tXEF/GKx2fNW+Pwku/a1cuyVh7ecfNrbbcZfxAx qUv4tPXH76Ruc4aENx9yBdZNvfUpQEnqvt1PkW45ltYbuccZXoreOr8wcZnARsEX307t5VL+ wKF0X+OPkIKT3a+w2esafXzlr0xJmdfdKLAi+1TBW7ss41fLuj9WtjpFJruKCHI4KyqxFGck GmoxFxUnAgASxqUEaAIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 11:48:49 -0000 Hi, A few questions, assuming we allow port zero m- lines within a bundle. Q1: Is the decision tied to whether we move forward with Plan A or Plan B? Q2: Do we allow port zero only for "bundle-only" m- lines, or for m- lines in g= eneral? Q3: If we allow port zero only for "bundle-only" m- lines, is there a technical= need to allow it in SDP answers? Q4: We need to keep in mind that there is always a chance that the "top-most" m= - line within a bundle group is a port zero one.=20 Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 13. toukokuuta 2013 10:27 To: Paul Kyzivat; Jonathan Lennox Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions Hi, So, assuming we are going to update RFC 5888 (whatever the exact wording wo= uld be), would we do that within draft-bundle, or within a separate documen= t? Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: 11. toukokuuta 2013 3:40 To: Jonathan Lennox Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions On 5/10/13 6:44 PM, Jonathan Lennox wrote: >>> I struggled to find it too. It's in 9.2: >>> >>> SIP entities refuse media streams by setting the port to zero i= n the >>> corresponding "m" line. "a=3Dgroup" lines MUST NOT contain >>> identification-tags that correspond to "m" lines with the port >>> set to >>> zero. >>> >>> >>> This feels like something we could relax for the offer. >> >> We could relax it. The question is if the change will break any=20 >> existing use. That is a hard question to answer. > > We could say that whether it's valid must be defined by the group semanti= c, and for all existing group semantics it's not. WFM _______________________________________________ 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 Mon May 13 04:58:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0221F941D for ; Mon, 13 May 2013 04:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5Ah7-Y1+gAw for ; Mon, 13 May 2013 04:58:31 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EAFBB21F94C3 for ; Mon, 13 May 2013 04:58:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-f2-5190d56587e5 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 06.5A.28165.565D0915; Mon, 13 May 2013 13:58:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Mon, 13 May 2013 13:58:28 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Splitting a BUNDLE Thread-Index: Ac5P0CGN9NWS3FUwQ2O4qnaDoH5QzQ== Date: Mon, 13 May 2013 11:58:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36F22F@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C36F22FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvrW7q1QmBBje/K1pMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGd/6/jIW7FesmLBvDmsD402ZLkZODgkBE4lrB2eyQthiEhfu rWfrYuTiEBI4zCjxZmITE0hCSGAJo0TjjPAuRg4ONgELie5/2iBhEQF1ia97e5hBbGEBZYnf Da/ZIeIaEtvfb2eGsPUkWjZdAouzCKhKvHlwnh1kDK+Ar8S8Xh+QMCPQ2u+n1oBtYhYQl7j1 ZD4TxDkCEkv2nGeGsEUlXj7+B3WmokT70wZGiPp8ic+HH7OB2LwCghInZz5hmcAoNAvJqFlI ymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGNlzEzNz0ssNNzECQ/7glt+6OxhP nRM5xCjNwaIkzpvE1RgoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZGtcVmO3t3fN/XaF182 2rVdQ66FQTdScc++9zGtZ/SWih7Q+hPmlXo6ZnVsYckbkzwX0bAnOetO/2YN1XmzRLj5o/rK Z5oshvsnX7rfHcnVv+qG75Imz7v+ybtfLbvm6R+zu02Dl8VVWjFwTUjz2lOxeXdWexXeXda8 4Eng1E02p7f3LF1YJqzEUpyRaKjFXFScCAAQqLHqRwIAAA== Subject: [MMUSIC] BUNDLE: Splitting a BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 11:58:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C36F22FESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We seem to have an agreement that, when an SDP offer contains an m- line as= sociated with a bundle group, it is ok to leave that m- line outside the bu= ndle group in the SDP Answer. Now, there has been some discussions about "splitting" a BUNDLE, meaning th= at an m- line in an SDP Answer is added to a DIFFERENT bundle group than in= the SDP Offer. Based on the discussions, it seems like people would be ok to NOT allow tha= t. If the SDP Answerer wants to put an m- line in another bundle group, it = needs to first reply to the SDP Offer, and then send a new SDP Offer itself= , putting the m- line in the bundle group it wants. In short, is basically means: in an SDP Answer, an m- line must only be bun= dle grouped with the same m- lines (or, a subset of those) as in the associ= ated SDP Offer. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C36F22FESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We seem to have an agreement that, when an SDP offer= contains an m- line associated with a bundle group, it is ok to leave that= m- line outside the bundle group in the SDP Answer.

 

Now, there has been some discussions about “sp= litting” a BUNDLE, meaning that an m- line in an SDP Answer is added = to a DIFFERENT bundle group than in the SDP Offer.

 

Based on the discussions, it seems like people would= be ok to NOT allow that. If the SDP Answerer wants to put an m- line in an= other bundle group, it needs to first reply to the SDP Offer, and then send= a new SDP Offer itself, putting the m- line in the bundle group it wants.

 

In short, is basically means: in an SDP Answer, an m= - line must only be bundle grouped with the same m- lines (or, a subset of = those) as in the associated SDP Offer.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C36F22FESESSMB209erics_-- From emil@sip-communicator.org Mon May 13 07:33:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0621F8F4D for ; Mon, 13 May 2013 07:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkFQ2ADjWZYu for ; Mon, 13 May 2013 07:33:15 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id DCCF521F9409 for ; Mon, 13 May 2013 07:33:13 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id mz1so300327bkb.39 for ; Mon, 13 May 2013 07:33:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=O+H+EnDlhjUOxj75ZXxXaXvVaUNvPaq91A4bL0Mv7eA=; b=kUjHOSQuX7cek8jw9hGJkojju/frK7A8FNswSwQYV2uREaNjrWsyss67emw7iLjnkg KwuOcTvkooNY38Svwmq8Z8+S32djaViXC526StEGRlpq4K3SJY0PmXTYTUT5JtlQ7jbd mc3h7l/9S6KRZZR/67oW+pfXCyGu7GX9A5t96YQ2AsAq0wdT3OfMm/s9GKq2AitwuIVk 5IxQevCESerSGYLcBdvqjzrxr31d6uXLuVWutJgPH3NuU5EzrOopVRkrZ7yyw8asGsmK Gs3BGJ+dHmu3piZ11kNtI3vUI/dBfF0npmMyEjsrUwAzkFA3Pwz0V6BP5R7//DbvVqOB lFHg== X-Received: by 10.205.38.195 with SMTP id tj3mr5590960bkb.67.1368455592347; Mon, 13 May 2013 07:33:12 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id j8sm2298660bky.17.2013.05.13.07.33.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 07:33:11 -0700 (PDT) Message-ID: <5190F9A6.4000904@jitsi.org> Date: Mon, 13 May 2013 17:33:10 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5190948A.5070707@ericsson.com> In-Reply-To: <5190948A.5070707@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkJdHDVBgz20JOwJyQiKhT07/0k04iU8UTegJRYwPRdBrEgqaSHRpVCfxyju/whU4DFHwHF Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 14:33:16 -0000 Hey Stefan, On 13.05.13, 10:21, Stefan H=E5kansson LK wrote: >> Well the way I remember it SDP O/A was chosen for session negotiation >> and that other forms of signalling were explicitly left out of the >> charter. >=20 > I took the result of the discussion and poll at the IETF-84=20 > (http://tools.ietf.org/wg/rtcweb/minutes?item=3Dminutes-84-rtcweb.html)= as=20 > an indication of that SDP O/A should be used for this kind of in-sessio= n=20 > changes as well. True, I am not sure we all realized the number of use cases this would end up encompassing and how we would end up implementing signalling features into SDP. >>> In this case either to transmit a new imageattr value >> >> imageattr is great as a declarative parameter indicating capabilities:= >> "I can't show more than 720p so there's no point to send me more than >> that". Using it as a way to switch between thumbnail and HQ videos is >> not entire impossible but is not particularly efficient either. >=20 > To me it looks like a solution that people might feel inclined towards = > using. >=20 > But there are others that want to use simulcast, and then pause/resume = > sending of high and low resolution streams, and that problem is more or= =20 > less the same when it comes to signaling. >=20 > And even if we omitted the possibility for a receiver to indicate to th= e=20 > sender (via standardized signaling) that it should pause or resume=20 > sending, and instead left that up to an API (at sender side) and=20 > proprietary signaling, we still have to have some kind of signaling IMO= :=20 > the sender can not just stop sending RTP packets, there need to be a=20 > signal to the receiver so it understands this=20 I never implied there should be no signalling. Just that implementing it all over SDP O/A leads to unforeseen complexities. RTCP BYE and/or SSRC expiration would be one option here. Custom signalling another. Cheers, Emil --=20 https://jitsi.org From pkyzivat@alum.mit.edu Mon May 13 07:44:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE6721F869C for ; Mon, 13 May 2013 07:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJVcpAsUbBzH for ; Mon, 13 May 2013 07:44:20 -0700 (PDT) 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 7D53F21F86CE for ; Mon, 13 May 2013 07:44:20 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id bQHD1l0020ldTLk54SkK4z; Mon, 13 May 2013 14:44:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id bSkK1l00w3ZTu2S3QSkK2w; Mon, 13 May 2013 14:44:19 +0000 Message-ID: <5190FC42.10108@alum.mit.edu> Date: Mon, 13 May 2013 10:44:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5190948A.5070707@ericsson.com> <5190F9A6.4000904@jitsi.org> In-Reply-To: <5190F9A6.4000904@jitsi.org> 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=1368456260; bh=cbpM5QaklGOgGcoNbFjVC3Vbc1/oG38IWOpPgwn9vfE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LFr2zSEwSRJVIjDQ3Fni80XXykmJdI1Tvqm8WSf9ozSTG+rNZB3so6bc9g66ng5MA Qzx85EbVHkVsdjXichJ0TkEGAxKRurRKoyj7W/ffDglIXn1Bz28tMUkvK4jdvSf8X9 5usXRph8ZObURZEjJIWh0/OdrTnWn57i0qsgLnPxteo4pXXM9o8Eniq3pGs42voHyT g4VJfbfgt0+gtFTIE47u8rVpu9W8OzUJg/1ZqWfjKG/WaMogGuZJB+cXQnLA6+Ch3B 3RagZdGtp0+kur+yA0rzG50S4OS4KZzZ2DpuksNKSe4QMFTQJ9p6wDpFgkTArILCVf VB5+5TwHBqsLA== Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 14:44:25 -0000 I'm not going to comment further on the specifics here, since they have been well flogged already. But the point of this particular discussion was about the likelihood of glare. Stefan's assertion was that O/As initiated by one end due to rapid changes in which streams it wants to receive will drive up the possibility of glare when the other end wants to do an O/A. I'll just say that if the number of O/As has gone up that much, then that was a bad choice of mechanism. Thanks, Paul On 5/13/13 10:33 AM, Emil Ivov wrote: > Hey Stefan, > > On 13.05.13, 10:21, Stefan Håkansson LK wrote: >>> Well the way I remember it SDP O/A was chosen for session negotiation >>> and that other forms of signalling were explicitly left out of the >>> charter. >> >> I took the result of the discussion and poll at the IETF-84 >> (http://tools.ietf.org/wg/rtcweb/minutes?item=minutes-84-rtcweb.html) as >> an indication of that SDP O/A should be used for this kind of in-session >> changes as well. > > True, I am not sure we all realized the number of use cases this would > end up encompassing and how we would end up implementing signalling > features into SDP. > >>>> In this case either to transmit a new imageattr value >>> >>> imageattr is great as a declarative parameter indicating capabilities: >>> "I can't show more than 720p so there's no point to send me more than >>> that". Using it as a way to switch between thumbnail and HQ videos is >>> not entire impossible but is not particularly efficient either. >> >> To me it looks like a solution that people might feel inclined towards >> using. >> >> But there are others that want to use simulcast, and then pause/resume >> sending of high and low resolution streams, and that problem is more or >> less the same when it comes to signaling. >> >> And even if we omitted the possibility for a receiver to indicate to the >> sender (via standardized signaling) that it should pause or resume >> sending, and instead left that up to an API (at sender side) and >> proprietary signaling, we still have to have some kind of signaling IMO: >> the sender can not just stop sending RTP packets, there need to be a >> signal to the receiver so it understands this > > I never implied there should be no signalling. Just that implementing it > all over SDP O/A leads to unforeseen complexities. > > RTCP BYE and/or SSRC expiration would be one option here. Custom > signalling another. > > Cheers, > Emil > From pkyzivat@alum.mit.edu Mon May 13 08:01:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC1821F90F1 for ; Mon, 13 May 2013 08:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYwkHxd8eLJu for ; Mon, 13 May 2013 08:01:03 -0700 (PDT) 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 5E8B821F90DF for ; Mon, 13 May 2013 08:01:03 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id bPGM1l0061ei1Bg54T12yL; Mon, 13 May 2013 15:01:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id bT121l0113ZTu2S3kT12tb; Mon, 13 May 2013 15:01:02 +0000 Message-ID: <5191002D.2000007@alum.mit.edu> Date: Mon, 13 May 2013 11:01:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368457262; bh=SEGb1ucQLS81JSkRr1GNDBiYDytkLbWZnYGPLDxJw40=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=g97Cgjgosa8sHmwLCX2KcK7lHFzo/SYwaCxLhlDZ1Px8RIpZFT6yypl1R5RtzOJeG XdXV2blZZhPhXnB9tCF0d08giO+bIczUIT8qx2xov3n2mqwXsADqV1/lPRLbyhWeDA 8pIubdY5ahRC+P7L4aOUasiiqgucN+Y/tmAmNam0cWpOOFrnMvNcztaYjqpvJvNOnL Nub2q41S1CQ/JYckyIDc53S0WM6D54LVbXnn12ASAkjxBEIh3tBkjo1PRkM/xOKeZL wC0uGDJgLVhbU2yDlK1lm+NQ8AQHEm7DZJ1pnUkC5euIwvp0up73dwR/qeAxm/etbY SzvhrY1cPKhsg== Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:01:08 -0000 On 5/13/13 3:27 AM, Christer Holmberg wrote: > Hi, > > So, assuming we are going to update RFC 5888 (whatever the exact wording would be), would we do that within draft-bundle, or within a separate document? That question always comes up, doesn't it? IMO this could probably be handled in the bundle draft, since it is a small change and by the same wg. But it isn't my call. This question should be addressed by the chairs and the ADs. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 11. toukokuuta 2013 3:40 > To: Jonathan Lennox > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions > > On 5/10/13 6:44 PM, Jonathan Lennox wrote: > >>>> I struggled to find it too. It's in 9.2: >>>> >>>> SIP entities refuse media streams by setting the port to zero in the >>>> corresponding "m" line. "a=group" lines MUST NOT contain >>>> identification-tags that correspond to "m" lines with the port >>>> set to >>>> zero. >>>> >>>> >>>> This feels like something we could relax for the offer. >>> >>> We could relax it. The question is if the change will break any >>> existing use. That is a hard question to answer. >> >> We could say that whether it's valid must be defined by the group semantic, and for all existing group semantics it's not. > > WFM > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Mon May 13 08:14:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6374921F941D for ; Mon, 13 May 2013 08:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsNEM7LqRUwg for ; Mon, 13 May 2013 08:14:07 -0700 (PDT) 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 9132321F8E98 for ; Mon, 13 May 2013 08:14:07 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id bNnK1l0021HzFnQ54TE707; Mon, 13 May 2013 15:14:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id bTE61l00l3ZTu2S3aTE6nJ; Mon, 13 May 2013 15:14:07 +0000 Message-ID: <5191033D.4040605@alum.mit.edu> Date: Mon, 13 May 2013 11:14:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36F1EB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36F1EB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368458047; bh=wGov5ljOe7XmPkWzSG3y1P6n7Oz6on1rUIGMsyHkMJ4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ta2oHk4IzaSqdwZdGCf7aAkOjdSSTkiCUHpm6hQgwEAJQeBiBzsXoAfqXojIkt42G +GZuCLwldOALkigIDv39kNPjihAGhUtg0qievkYqs/roIoSZzq5HsKJt/CJhIQUA6o eCZBjfy7ljP3MVHuGwF13bPqZuTGxjDE2z66MTmtevFtpGdmvwh2G64gDAUOAM194D EvXrYKoX4+oHogHM4dDtRB5Uy3yidKOxiNuSbQFuWt3FQphMc991fqWFT0Z33Rn6hF g5Q10DQv4rw1O7pvm8p16kgWjwyzWBqITmyDzX9uv/8eJ+lzFtvSfI6gYgoQLGLAJG vkfGf2o6CBZuw== Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:14:12 -0000 On 5/13/13 7:48 AM, Christer Holmberg wrote: > Hi, > > A few questions, assuming we allow port zero m- lines within a bundle. IMO we should try to keep mechanisms as flexible and independent of one another as possible. Answers below are based on that. > Q1: > > Is the decision tied to whether we move forward with Plan A or Plan B? No. Why should it be? > Q2: > > Do we allow port zero only for "bundle-only" m- lines, or for m- lines in general? Any m-lines. I can't see any reason to be restrictive. > Q3: > > If we allow port zero only for "bundle-only" m- lines, is there a technical need to allow it in SDP answers? Again, keep things separate and clear. If I'm offered a bundled m-line with non-zero port, and want to reject it, I should be able to do so by setting the port to zero, just as if it was not bundled. Independently, if I'm offered a bundled m-line I may need to exclude it from the bundle, and I should be able to make that decision while either accepting or rejecting the m-line. > Q4: > > We need to keep in mind that there is always a chance that the "top-most" m- line within a bundle group is a port zero one. What is the question? Thanks, Paul > Regards, > > Christer > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 13. toukokuuta 2013 10:27 > To: Paul Kyzivat; Jonathan Lennox > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions > > Hi, > > So, assuming we are going to update RFC 5888 (whatever the exact wording would be), would we do that within draft-bundle, or within a separate document? > > Regards, > > Christer > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 11. toukokuuta 2013 3:40 > To: Jonathan Lennox > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions > > On 5/10/13 6:44 PM, Jonathan Lennox wrote: > >>>> I struggled to find it too. It's in 9.2: >>>> >>>> SIP entities refuse media streams by setting the port to zero in the >>>> corresponding "m" line. "a=group" lines MUST NOT contain >>>> identification-tags that correspond to "m" lines with the port >>>> set to >>>> zero. >>>> >>>> >>>> This feels like something we could relax for the offer. >>> >>> We could relax it. The question is if the change will break any >>> existing use. That is a hard question to answer. >> >> We could say that whether it's valid must be defined by the group semantic, and for all existing group semantics it's not. > > WFM > > _______________________________________________ > 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 pkyzivat@alum.mit.edu Mon May 13 08:16:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1300021F872E for ; Mon, 13 May 2013 08:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjZuVpB0qRVK for ; Mon, 13 May 2013 08:16:51 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id E5D8321F944C for ; Mon, 13 May 2013 08:16:50 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta12.westchester.pa.mail.comcast.net with comcast id bPHQ1l00117dt5G5CTGq4f; Mon, 13 May 2013 15:16:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id bTGp1l01F3ZTu2S3ZTGqqS; Mon, 13 May 2013 15:16:50 +0000 Message-ID: <519103E1.8030200@alum.mit.edu> Date: Mon, 13 May 2013 11:16:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C36F22F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36F22F@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=1368458210; bh=uhXwwpLZeTmRWcl/jKES+Nuw2/8KFlIXvsQqEWYO8j8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SKqfJCyBOOdBt8X9O4dE8ryh/dxS2kXLza763t8Z5/VMXurVEyRiXCiWJ2lZegHxm Zrcw/+NdL9FFbogFAd3hG8REqgUeLITbwCMPYg7mTWebk92j81Z9aLsbWBiZ7GVYoL ee9GY1GQXjwE0td1JtOe1fXOGHzvWcNksNHnsbITRr173FPmX5W4LrosAzux5QVm2I BhcZUA869FPH07Kn7o6V2CTMS6i6+mraL0fAi8cCPqsnQ3Ok4uXEXMgYH/BbRGy7g5 1BSFd9bFAFT1YiGvY1820IVmMn0b9WNk2fX/Gid4r6Ukmn2UD65CDfh87bALDNJ9ax HGQRRzKrE17cQ== Subject: Re: [MMUSIC] BUNDLE: Splitting a BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:16:57 -0000 On 5/13/13 7:58 AM, Christer Holmberg wrote: > Hi, > > We seem to have an agreement that, when an SDP offer contains an m- line > associated with a bundle group, it is ok to leave that m- line outside > the bundle group in the SDP Answer. > > Now, there has been some discussions about “splitting” a BUNDLE, meaning > that an m- line in an SDP Answer is added to a DIFFERENT bundle group > than in the SDP Offer. > > Based on the discussions, it seems like people would be ok to NOT allow > that. If the SDP Answerer wants to put an m- line in another bundle > group, it needs to first reply to the SDP Offer, and then send a new SDP > Offer itself, putting the m- line in the bundle group it wants. > > In short, is basically means: in an SDP Answer, an m- line must only be > bundle grouped with the same m- lines (or, a subset of those) as in the > associated SDP Offer. Yes, this is the conclusion I reached. I wish it weren't true. But I think there must be a mechanism for the new bundle to be rejected, and if it is first proposed in the answer then that isn't possible. IMO this is a rare enough case that suffering another O/A is acceptable. Thanks, Paul From bernard_aboba@hotmail.com Mon May 13 08:37:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F3D21F955A for ; Mon, 13 May 2013 08:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcwiRMLHROMu for ; Mon, 13 May 2013 08:37:07 -0700 (PDT) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by ietfa.amsl.com (Postfix) with ESMTP id B1BE121F94A6 for ; Mon, 13 May 2013 08:37:06 -0700 (PDT) Received: from BLU404-EAS319 ([65.55.111.73]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 08:37:06 -0700 X-EIP: [sYznRP0f7yaWUEUZXVZ9+llQSB6fOSZu] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5190948A.5070707@ericsson.com> <5190F9A6.4000904@jitsi.org> <5190FC42.10108@alum.mit.edu> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <5190FC42.10108@alum.mit.edu> Date: Mon, 13 May 2013 08:37:05 -0700 To: Paul Kyzivat X-OriginalArrivalTime: 13 May 2013 15:37:06.0502 (UTC) FILETIME=[B94E5660:01CE4FEF] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:37:12 -0000 I think you are right on target - but if we do not have a clear articulation= of the line between RTCP and O/A, then it is going to be hard to prevent go= ing off Into the weeds. On May 13, 2013, at 7:44, "Paul Kyzivat" wrote: > I'm not going to comment further on the specifics here, since they have be= en well flogged already. But the point of this particular discussion was abo= ut the likelihood of glare. Stefan's assertion was that O/As initiated by on= e end due to rapid changes in which streams it wants to receive will drive u= p the possibility of glare when the other end wants to do an O/A. >=20 > I'll just say that if the number of O/As has gone up that much, then that w= as a bad choice of mechanism. >=20 > Thanks, > Paul >=20 >=20 From fluffy@cisco.com Mon May 13 10:28:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8879F21F93EE for ; Mon, 13 May 2013 10:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9Z128IR8v2K for ; Mon, 13 May 2013 10:28:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 857D821F92BC for ; Mon, 13 May 2013 10:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1520; q=dns/txt; s=iport; t=1368466120; x=1369675720; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hdRqS7AyKI77zhAwBOB3mCT51Jq/jl4LgcdLPZRlW9U=; b=CnL4fBh2/UxvvSQwLP9Hc5kSTEamAavHAPP9AMlbKAuPyijotutsZWJB dXIH75i6q77eu3pOADTcwRp0Dg8Hp+wrDctRAan7ub8vcbT52WUGt8Q3r DaNKVcBjgjO7PWUrBC//5bMlp2ZL9sf8cnO/485mWX9oIoKxweZRbv0Kk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAH8hkVGtJXG9/2dsb2JhbABagwc3rgeSI4EIFnSCHwEBAQMBAQEBNzQLBQsCAQgYChQQJwslAgQOBQiHcgMJBgy7awSMUoIjAjEHgnRhA5VJjXaFIoMPgic X-IronPort-AV: E=Sophos;i="4.87,663,1363132800"; d="scan'208";a="209932067" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 13 May 2013 17:28:35 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4DHSZ9f010903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 May 2013 17:28:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 13 May 2013 12:28:35 -0500 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 Thread-Index: AQHOT/9LbzKDaxiWAE2p0RYRHh9BIA== Date: Mon, 13 May 2013 17:28:35 +0000 Message-ID: References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5190948A.5070707@ericsson.com> <5190F9A6.4000904@jitsi.org> <5190FC42.10108@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: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:28:45 -0000 We already have RTCP to pause / un pause things and it seems like we should= have RTCP to change resolution, frame rate, bandwidth inside of the parame= ters set in the SDP envelope (some people think we have that ). I agree tha= t needs to all be clearly specifies how one does all of that with RTCP and = how an endpoint signals in in SDP that it is capable of such negotiations. = It seems fairly easy to specify whatever parts of that are missing.=20 On May 13, 2013, at 9:37 AM, Bernard Aboba wrot= e: > I think you are right on target - but if we do not have a clear articulat= ion of the line between RTCP and O/A, then it is going to be hard to preven= t going off Into the weeds. >=20 > On May 13, 2013, at 7:44, "Paul Kyzivat" wrote: >=20 >> I'm not going to comment further on the specifics here, since they have = been well flogged already. But the point of this particular discussion was = about the likelihood of glare. Stefan's assertion was that O/As initiated b= y one end due to rapid changes in which streams it wants to receive will dr= ive up the possibility of glare when the other end wants to do an O/A. >>=20 >> I'll just say that if the number of O/As has gone up that much, then tha= t was a bad choice of mechanism. >>=20 >> Thanks, >> Paul >>=20 >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From bernard_aboba@hotmail.com Mon May 13 10:59:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B9A21F9377; Mon, 13 May 2013 10:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6a6f3MrIcJO; Mon, 13 May 2013 10:58:59 -0700 (PDT) Received: from blu0-omc3-s22.blu0.hotmail.com (blu0-omc3-s22.blu0.hotmail.com [65.55.116.97]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7921F923C; Mon, 13 May 2013 10:58:49 -0700 (PDT) Received: from BLU405-EAS289 ([65.55.116.74]) by blu0-omc3-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 10:58:49 -0700 X-EIP: [C1ZSRuta2/no7ZqncPt4qV90Wo440ztx] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> Date: Mon, 13 May 2013 10:58:49 -0700 To: =?utf-8?Q?Stefan_H=C3=A5kansson_LK?= X-OriginalArrivalTime: 13 May 2013 17:58:49.0273 (UTC) FILETIME=[855A3A90:01CE5003] Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:59:07 -0000 DQoNCk9uIE1heSAxMiwgMjAxMywgYXQgMTA6MTgsICJTdGVmYW4gSMOla2Fuc3NvbiBMSyIgPHN0 ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPj4gSSB3b3VsZCBob3Bl IHRoZXJlIHdpbGwgbm9ybWFsbHkgbm90IGJlIFNEUCBjaGFuZ2VzIGZvciBlaXRoZXIgb2YgdGhv c2UNCj4+IGV2ZW50cy4NCj4gDQo+IEkgd291bGQgbGlrZSB0byBhdm9pZCB0aGVtIHRvbywgYnV0 IEknbSBub3Qgc3VyZSBob3cuDQoNCltCQV0gSXQgaXMgcHJvYmFibHkgbm90IHBvc3NpYmxlIHRv IGF2b2lkIHRoZW0gaW4gYWxsIGNhc2VzLCBidXQgd2UgY2FuIGRlZmluZSBSVENQIGZ1bmN0aW9u YWxpdHkgd2hpY2ggYWxvbmcgd2l0aCBzb21lIHNldCBvZiBmdW5jdGlvbmFsaXR5IChlLmcuIFNp bXVsY2FzdCwgbGF5ZXJlZCBjb2RpbmcpIHdpbGwgbWluaW1pemUgdGhlbS4gVGhpcyBpcyB3b3J0 aCBkb2luZyAoYW5kIHNvb24pLg== From bernard_aboba@hotmail.com Mon May 13 11:01:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4C021F93F0 for ; Mon, 13 May 2013 11:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.731 X-Spam-Level: X-Spam-Status: No, score=-101.731 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dtzm86HJ4cH for ; Mon, 13 May 2013 11:01:07 -0700 (PDT) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfa.amsl.com (Postfix) with ESMTP id D4C3521F913E for ; Mon, 13 May 2013 11:01:06 -0700 (PDT) Received: from BLU405-EAS319 ([65.55.111.72]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 11:01:05 -0700 X-EIP: [2FelAzCNspurtoE8qRYfvcP1H2Su+h2v] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5190948A.5070707@ericsson.com> <5190F9A6.4000904@jitsi.org> <5190FC42.10108@alum.mit.edu> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Mon, 13 May 2013 11:01:06 -0700 To: "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 13 May 2013 18:01:05.0952 (UTC) FILETIME=[D6D1CA00:01CE5003] Cc: "avtcore@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:01:11 -0000 I agree with this, and think the overall experience will be better if we can= do this. It should have been defined years ago.=20 On May 13, 2013, at 10:28, "Cullen Jennings (fluffy)" wro= te: >=20 > We already have RTCP to pause / un pause things and it seems like we shoul= d have RTCP to change resolution, frame rate, bandwidth inside of the parame= ters set in the SDP envelope (some people think we have that ). I agree that= needs to all be clearly specifies how one does all of that with RTCP and ho= w an endpoint signals in in SDP that it is capable of such negotiations. It s= eems fairly easy to specify whatever parts of that are missing.=20 >=20 >=20 > On May 13, 2013, at 9:37 AM, Bernard Aboba wro= te: >=20 >> I think you are right on target - but if we do not have a clear articulat= ion of the line between RTCP and O/A, then it is going to be hard to prevent= going off Into the weeds. >>=20 >> On May 13, 2013, at 7:44, "Paul Kyzivat" wrote: >>=20 >>> I'm not going to comment further on the specifics here, since they have b= een well flogged already. But the point of this particular discussion was ab= out the likelihood of glare. Stefan's assertion was that O/As initiated by o= ne end due to rapid changes in which streams it wants to receive will drive u= p the possibility of glare when the other end wants to do an O/A. >>>=20 >>> I'll just say that if the number of O/As has gone up that much, then tha= t was a bad choice of mechanism. >>>=20 >>> Thanks, >>> Paul >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 From christer.holmberg@ericsson.com Mon May 13 11:26:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8268221F9227 for ; Mon, 13 May 2013 11:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9t7CJSty-FB for ; Mon, 13 May 2013 11:26:43 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E116421F901B for ; Mon, 13 May 2013 11:26:42 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-7a-519130618955 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3D.A7.28165.16031915; Mon, 13 May 2013 20:26:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Mon, 13 May 2013 20:26:40 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: Ac5H/Rv/zjNZSPPjTceQWRJyHaV9rQFtnnqAAAGLCAAAAGP9gAAACH4AAABFcQAAAKtdAAAEBdGAAHbqqsAACNG68AADX5WAAArHL9A= Date: Mon, 13 May 2013 18:26:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36F59E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36F1EB@ESESSMB209.ericsson.se> <5191033D.4040605@alum.mit.edu> In-Reply-To: <5191033D.4040605@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI 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+NgFrrMLMWRmVeSWpSXmKPExsUyM+JvrW6iwcRAg///FC32Lz7PbDF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHm3P7rAHMEdx2aSk5mSWpRbp2yVwZWy/eoa14KtUxePe/SwN jD2iXYycHBICJhLHDr9khbDFJC7cW8/WxcjFISRwmFHi/7kTjBDOEkaJiWs3MnUxcnCwCVhI dP/TBjFFBDQkJm1VA+llFvCV+HXtOjtIWBio4suuWogKS4nV971AKkQEyiT65n5mAwmzCKhK rPopDhLmBWrc82YB1J42VomXi2axgyQ4BXQkpjfdBLMZgS77fmoNE8QmcYkPB68zQ1wsILFk z3koW1Ti5eN/UJ8oSfzYcIkFol5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj2CwkY2chaZmF pGUWkpYFjCyrGNlzEzNz0ssNNzECI+bglt+6OxhPnRM5xCjNwaIkzpvE1RgoJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgbFbi69LZeVBwYI7J4uOmipvathWuGDek/ZWzWznHavepH+6pX2q 6qjh5vr0tq+OTM/vmmgfrBFRY7Dk9/jtOcXP6Pe1JK748Klxek1C73U+ytyq+/jaXidn7wrj VFbPjsNrajaez85Lc5/SZ+R3b4/Yrc3fdXlrv54I2jl9x6x9X+a+lymqY1diKc5INNRiLipO BADIwjf1ZgIAAA== Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:26:48 -0000 Hi, >>> A few questions, assuming we allow port zero m- lines within a bundle. >> >> IMO we should try to keep mechanisms as flexible and independent of one = another as possible. Answers below are based on that. >> >> Q1: >> >> Is the decision tied to whether we move forward with Plan A or Plan B? > >No. Why should it be? > >> Q2: >> >> Do we allow port zero only for "bundle-only" m- lines, or for m- lines i= n general? > > Any m-lines. I can't see any reason to be restrictive. > >> Q3: >> >> If we allow port zero only for "bundle-only" m- lines, is there a techni= cal need to allow it in SDP answers? > > Again, keep things separate and clear. If I'm offered a bundled m-line wi= th non-zero port, and want to reject it, I should be able to do > so by setting the port to zero, just as if it was not bundled. Independen= tly, if I'm offered a bundled m-line I may need to exclude it from=20 > the bundle, and I should be able to make that decision while either accep= ting or rejecting the m-line. > >> Q4: >> >> We need to keep in mind that there is always a chance that the "top-most= " m- line within a bundle group is a port zero one. > > What is the question? Well, there are basically two "warm-up" questions: Q4_1: When the first offer, with DIFFERENT port numbers is sent, and the re= ceiver accepts bundle, is the receiver expected to be able to send media/da= ta according to that? Q4_2: IF Q4_1 THEN which m- line does the receiver use to send media/data (= when the second offer comes, with identical port numbers, it is no longer a= n issue). Regards, Christer =20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Christer Holmberg > Sent: 13. toukokuuta 2013 10:27 > To: Paul Kyzivat; Jonathan Lennox > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions > > Hi, > > So, assuming we are going to update RFC 5888 (whatever the exact wording = would be), would we do that within draft-bundle, or within a separate docum= ent? > > Regards, > > Christer > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 11. toukokuuta 2013 3:40 > To: Jonathan Lennox > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions > > On 5/10/13 6:44 PM, Jonathan Lennox wrote: > >>>> I struggled to find it too. It's in 9.2: >>>> >>>> SIP entities refuse media streams by setting the port to zero= in the >>>> corresponding "m" line. "a=3Dgroup" lines MUST NOT contain >>>> identification-tags that correspond to "m" lines with the por= t >>>> set to >>>> zero. >>>> >>>> >>>> This feels like something we could relax for the offer. >>> >>> We could relax it. The question is if the change will break any=20 >>> existing use. That is a hard question to answer. >> >> We could say that whether it's valid must be defined by the group semant= ic, and for all existing group semantics it's not. > > WFM > > _______________________________________________ > 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 martin.thomson@gmail.com Mon May 13 11:42:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0120721F93FF for ; Mon, 13 May 2013 11:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qzRxBIv572d for ; Mon, 13 May 2013 11:42:33 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 50F5521F93FB for ; Mon, 13 May 2013 11:42:33 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q57so6335602wes.23 for ; Mon, 13 May 2013 11:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=byZlYpTnZk/aehVqoNOGl4o181qj8q7kSCuQo8/OgYE=; b=TwQYZPg+d/EKlxGcitgq4c2NgNmxIn20GnReV5/i3BuZjw4yDhFwK7LKDj0sBtEnjA T+/lHAFMN6DvniKXTmfnajlswa9A961zLNeDyNT4LZBXxFRgxeVtnSwWV/elIaixyV5g 7wUBYk02uqe2nwEm7++stOHbMacCoFJ2GHA5Cpv042Cu4a1rvDGxJ0nm2WPf+fUnOz8p ziKOwCn/IClSbGsoickt3TQzCYLy5o94xx5ms326304ZBnKVydHpgTB+Bh+/xTXgLxwg Y9tPu6NpOuW6Gz55ZbVvtzSngL7F+HOgUnmA5C1qoZdMeiDo9RqOtInj/vk2gTYZPxR+ pD0Q== MIME-Version: 1.0 X-Received: by 10.180.74.207 with SMTP id w15mr6913635wiv.19.1368470552304; Mon, 13 May 2013 11:42:32 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Mon, 13 May 2013 11:42:32 -0700 (PDT) Date: Mon, 13 May 2013 11:42:32 -0700 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:42:34 -0000 We've had a great deal of discussion about plan A and B and the various interactions of these proposals with bundling. But I still don't get a good sense that there is a working consensus on what an m-line actually represents. I think that we've each reached our own conclusions, but they definitely are not consistent. We need a well-understood semantic for m-lines if we have any chance of resolving these issues; Plan A/B being only the first RTCWEB problem to address. RFC 4566 is helpfully devoid of detail, so we are free to come up with any interpretation we choose. Here are the ones that I have seen: 1. an m-line represents a single RTP session (or at least the part of the session that touches the client) This appears to be consistent with the Plan B approach 2. an m-line represents the set of RTP streams that decode into a single rendering, including layers, simulcast and FEC 3. an m-line represents a single RTP stream; multiple m-lines might be required to obtain a single rendering if it uses layers, simulcast, FEC or FID groupings This appears to be consistent with the Plan A approach In the first instance, an m-line can be multiple "things". In the latter two cases, an m-line is consistently one "thing" (or part thereof). The first interpretation has a natural advantage in terms of signaling economy and natural bundling. The latter interpretations seem to have advantages in dealing with call transfer and SSRC renumbering. So, which is correct? From pkyzivat@alum.mit.edu Mon May 13 11:46:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C6021F8EBD for ; Mon, 13 May 2013 11:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpsnRzjTeFwj for ; Mon, 13 May 2013 11:46:25 -0700 (PDT) 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 12FF221F8EA5 for ; Mon, 13 May 2013 11:46:24 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta05.westchester.pa.mail.comcast.net with comcast id bPqh1l00717dt5G55WmQ02; Mon, 13 May 2013 18:46:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id bWmQ1l00D3ZTu2S3ZWmQDU; Mon, 13 May 2013 18:46:24 +0000 Message-ID: <519134FF.5010405@alum.mit.edu> Date: Mon, 13 May 2013 14:46:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36F1EB@ESESSMB209.ericsson.se> <5191033D.4040605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36F59E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36F59E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368470784; bh=2T1ySvfP2ISbS9XSr6BkKZqHbab20TaSYFExw8dF9+k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=o8t6vbQCIzvzEyXj5KBSvNsO8bWV4mJiHXmr3Tj/E0pq6MPOI9SBFX/7fvOuRKccU zovEmQuhdlczmyZytL/Iyag0yqw1V4dU2epAsVGr7FE/vPyuX9lbDuwZAinetKZcxd 9IKbUI1itUi4wx1dMUMCZA8WMbn/KPuKDkzPQs3sM0w7zp+1FOx3znitB46lr25kwj 2xh3V0V4IHlroIXiaAbklYt1fzafCfdDA0T1rv9lz146T+qiFqknPPxOBbviK99Pdq g1dGgLAeH3+NuQnGCGFySjQlMWMVV0sjmnwPAijeJYHSwjUlKETc2GF56PPheslXO4 n8erXw8ra6MQA== Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:46:31 -0000 On 5/13/13 2:26 PM, Christer Holmberg wrote: >>> Q4: >>> >>> We need to keep in mind that there is always a chance that the "top-most" m- line within a bundle group is a port zero one. >> >> What is the question? > > Well, there are basically two "warm-up" questions: > > Q4_1: When the first offer, with DIFFERENT port numbers is sent, and the receiver accepts bundle, is the receiver expected to be able to send media/data according to that? I hope so. > Q4_2: IF Q4_1 THEN which m- line does the receiver use to send media/data (when the second offer comes, with identical port numbers, it is no longer an issue). Surely the bundle draft must specify this. My first thought is that the address/port of the *first* m-line in the bundle with a non-zero port will be used for the entire bundle. (This means that when you initially offer a bundle with a bunch of separate ports, you not only must be prepared to use each of those for an unbundled m-line, you must be prepared to use any of them for the complete bundle.) Thanks, Paul From pkyzivat@alum.mit.edu Mon May 13 12:02:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CFD21F9488 for ; Mon, 13 May 2013 12:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.746 X-Spam-Level: X-Spam-Status: No, score=0.746 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MANGLED_FORM=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqQs5JNVJZKb for ; Mon, 13 May 2013 12:02:37 -0700 (PDT) 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 8AEE221F947C for ; Mon, 13 May 2013 12:02:36 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta06.westchester.pa.mail.comcast.net with comcast id bUVQ1l0050QuhwU56X2coL; Mon, 13 May 2013 19:02:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id bX2c1l00F3ZTu2S3NX2c4N; Mon, 13 May 2013 19:02:36 +0000 Message-ID: <519138CB.5020202@alum.mit.edu> Date: Mon, 13 May 2013 15:02:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: 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=1368471756; bh=6wtk+HKgWX+J97YCyqnUQJ4CDkkrWnz2t8tc1cpGS1w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NzaY7q7gblKP6+1bMK91tClOQ7as50VUrISSSQiyfWkwdg1VRDGs5HGX6pA+Ka5Jj SBEzgGYj+wdn96f9SRI8+PcaohHnfJ7C5RN2y31xaJTj5IqbLh73+91K7KzXAou1MB Gazd2X1OcsA0xAK5fpybtIsk/MDX5N55LMQAt7+Mw/NIcWuvLbiw/ICehbn5SFc8aT wvZJZ2X3II6gTVMWwxtg3XYQGpw7CVSKQvpJQoed4qYn0/ExyjQapuNr1+INxJGaeM EI2zBao4jVU2xf+S0Yzme096HreL4UunUq02NmJTCU+Jmzq8ENQnjuPtznKwyIMyiv NQ1Z2RFEf2JlA== Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:02:48 -0000 On 5/13/13 2:42 PM, Martin Thomson wrote: > We've had a great deal of discussion about plan A and B and the > various interactions of these proposals with bundling. But I still > don't get a good sense that there is a working consensus on what an > m-line actually represents. > > I think that we've each reached our own conclusions, but they > definitely are not consistent. We need a well-understood semantic for > m-lines if we have any chance of resolving these issues; Plan A/B > being only the first RTCWEB problem to address. > > RFC 4566 is helpfully devoid of detail, so we are free to come up with > any interpretation we choose. Here are the ones that I have seen: > > 1. an m-line represents a single RTP session > (or at least the part of the session that touches the client) > This appears to be consistent with the Plan B approach Well, it was my impression that Plan B still intends to allow bundling in order to combine audio and video into a single RTP session. So in that case neither of the m-lines represents a single RTP session in full. > 2. an m-line represents the set of RTP streams that decode into a > single rendering, including layers, simulcast and FEC Hmm. I was thinking *this* was what Cullen intended by Plan A. But now that you bring it up, I thing there is some existing SDP syntax for simulcast/FEC/FID that might only work with (3). (But I don't have the details of that stuff in my head.) > 3. an m-line represents a single RTP stream; multiple m-lines might > be required to obtain a single rendering if it uses layers, simulcast, > FEC or FID groupings > This appears to be consistent with the Plan A approach I offer another try: 4. an m-line represents one or more (zero or more?) sources/flows/tracks/captures (pick the name that suits you) that share a single RTP session and that all are consistent with the media description accompanying the m-line. IIUC this is what Plan B is trying to achieve. Thanks, Paul > In the first instance, an m-line can be multiple "things". In the > latter two cases, an m-line is consistently one "thing" (or part > thereof). > > The first interpretation has a natural advantage in terms of signaling > economy and natural bundling. The latter interpretations seem to have > advantages in dealing with call transfer and SSRC renumbering. > > So, which is correct? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From bernard_aboba@hotmail.com Mon May 13 12:14:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2F121F9476 for ; Mon, 13 May 2013 12:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiWD9AS4mWZT for ; Mon, 13 May 2013 12:14:50 -0700 (PDT) Received: from blu0-omc4-s23.blu0.hotmail.com (blu0-omc4-s23.blu0.hotmail.com [65.55.111.162]) by ietfa.amsl.com (Postfix) with ESMTP id ABAFF21F8721 for ; Mon, 13 May 2013 12:14:50 -0700 (PDT) Received: from BLU169-W78 ([65.55.111.136]) by blu0-omc4-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 12:14:49 -0700 X-EIP: [21bLp088o56j2EVuYL4NZrOGjCr1ZmT5zlv/KlIG674=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_e2658fd3-23b8-4fc4-af63-96a87429405f_" From: Bernard Aboba To: Martin Thomson , "mmusic@ietf.org" Date: Mon, 13 May 2013 12:14:48 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2013 19:14:49.0249 (UTC) FILETIME=[234F5910:01CE500E] Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:14:56 -0000 --_e2658fd3-23b8-4fc4-af63-96a87429405f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin said=3B=20 > 1. an m-line represents a single RTP session > (or at least the part of the session that touches the client) > This appears to be consistent with the Plan B approach >=20 > 2. an m-line represents the set of RTP streams that decode into a > single rendering=2C including layers=2C simulcast and FEC >=20 > 3. an m-line represents a single RTP stream=3B multiple m-lines might > be required to obtain a single rendering if it uses layers=2C simulcast= =2C > FEC or FID groupings. This appears to be consistent with the Plan A appro= ach >=20 > In the first instance=2C an m-line can be multiple "things". In the > latter two cases=2C an m-line is consistently one "thing" (or part > thereof). >=20 > The first interpretation has a natural advantage in terms of signaling > economy and natural bundling. The latter interpretations seem to have > advantages in dealing with call transfer and SSRC renumbering. >=20 > So=2C which is correct? [BA] With respect to video=2C I believe that #1 is closer to what we see in= existing implementations of simulcast and layered coding. For that scenar= io=2C approach #3 could generate too many m lines. Approach #1 is also co= nsistent with the multicast scenarios envisaged in the early days of SDP=2C= where multiple SSRCs could send to the same multicast address and port. = Where the mixer only puts out a single SSRC (e.g. audio or composited vide= o)=2C approach #2 is a degenerate case of #3. = --_e2658fd3-23b8-4fc4-af63-96a87429405f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Martin said=3B =3B

<= div>
>=3B 1. an m-line represents a single RTP session
>=3B = (or at least the part of the session that touches the client)
>=3B = This appears to be consistent with the Plan B approach
>=3B
>= =3B 2. an m-line represents the set of RTP streams that decode into a
&= gt=3B single rendering=2C including layers=2C simulcast and FEC
>=3B <= br>>=3B 3. an m-line represents a single RTP stream=3B multiple m-lines = might
>=3B be required to obtain a single rendering if it uses layers= =2C simulcast=2C
>=3B FEC or FID groupings. =3BThis appears to be = consistent with the Plan A approach
>=3B
>=3B In the first insta= nce=2C an m-line can be multiple "things". In the
>=3B latter two cas= es=2C an m-line is consistently one "thing" (or part
>=3B thereof).>=3B
>=3B The first interpretation has a natural advantage in term= s of signaling
>=3B economy and natural bundling. The latter interpre= tations seem to have
>=3B advantages in dealing with call transfer and= SSRC renumbering.
>=3B
>=3B So=2C which is correct?

[BA] With respect to video=2C I believe that #1 is closer to w= hat we see in existing implementations of simulcast and layered coding. &nb= sp=3BFor that scenario=2C approach #3 could generate too many m lines. &nbs= p=3B Approach #1 is also consistent with the multicast scenarios envisaged = in the early days of SDP=2C where multiple SSRCs could send to the same mul= ticast address and port.  =3B  =3BWhere the mixer only puts out a s= ingle SSRC (e.g. audio or composited video)=2C approach #2 is a degenerate = case of #3. =3B
= --_e2658fd3-23b8-4fc4-af63-96a87429405f_-- From jonathan@vidyo.com Mon May 13 12:25:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1737B21F93FC for ; Mon, 13 May 2013 12:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBc4V5f4JiU4 for ; Mon, 13 May 2013 12:24:54 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id BF58621F93EA for ; Mon, 13 May 2013 12:24:54 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 42B3955628A; Mon, 13 May 2013 15:24:49 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7D777556057; Mon, 13 May 2013 15:24:48 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Mon, 13 May 2013 15:24:20 -0400 From: Jonathan Lennox To: Paul Kyzivat Date: Mon, 13 May 2013 15:24:48 -0400 Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: Ac5QD3hQUkNe6OTvSAu+p4CH0kyx2Q== Message-ID: <789CDEFF-5266-4F0B-8EE3-65D879840616@vidyo.com> References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36F1EB@ESESSMB209.ericsson.se> <5191033D.4040605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36F59E@ESESSMB209.ericsson.se> <519134FF.5010405@alum.mit.edu> In-Reply-To: <519134FF.5010405@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:25:00 -0000 On May 13, 2013, at 2:46 PM, Paul Kyzivat wrote: > Surely the bundle draft must specify this. >=20 > My first thought is that the address/port of the *first* m-line in the=20 > bundle with a non-zero port will be used for the entire bundle. >=20 > (This means that when you initially offer a bundle with a bunch of=20 > separate ports, you not only must be prepared to use each of those for=20 > an unbundled m-line, you must be prepared to use any of them for the=20 > complete bundle.) An offerer sends an initial offer with a bundle of two m-lines: one with po= rt 20000, one with 30000. The answerer answers, rejecting the first m-line (with port zero) but accep= ting the bundle. Should the answerer send traffic to port 20000 or port 30000? -- Jonathan Lennox jonathan@vidyo.com From christer.holmberg@ericsson.com Mon May 13 12:31:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933A21F8E74 for ; Mon, 13 May 2013 12:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZAgwjei7uWW for ; Mon, 13 May 2013 12:31:29 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B392E21F885A for ; Mon, 13 May 2013 12:31:22 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-a3-51913f88807b Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 03.C1.32006.88F31915; Mon, 13 May 2013 21:31:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Mon, 13 May 2013 21:31:20 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: VS: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: Ac5H/Rv/zjNZSPPjTceQWRJyHaV9rQFtnnqAAAGLCAAAAGP9gAAACH4AAABFcQAAAKtdAAAEBdGAAHbqqsAACNG68AADX5WAAArHL9D//+UXgP//1Tbw Date: Mon, 13 May 2013 19:31:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36F639@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36F1EB@ESESSMB209.ericsson.se> <5191033D.4040605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36F59E@ESESSMB209.ericsson.se> <519134FF.5010405@alum.mit.edu> In-Reply-To: <519134FF.5010405@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI 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+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvrW6n/cRAgz1FFvsXn2e2mLr8MYvF ig0HWB2YPf6+/8DksWTJTyaPtmd32AOYo7hsUlJzMstSi/TtErgy/q7cx1Iwm79i7sm/zA2M r7m7GDk5JARMJPrXNzFB2GISF+6tZ+ti5OIQEjjMKHFqQRc7SEJIYAmjxPX9hl2MHBxsAhYS 3f+0QUwRAQ2JSVvVQCqYBXwlfl27DlYtLGAjMX3CS0YQW0TAVmJBwwMmkJEiAk2MEjMmX2IG SbAIqEqsm3UAzOYFav50qJcJYu8bVombPVvBujkFdCR+v7/DAmIzAh33/dQaJoht4hIfDl5n hjhaQGLJnvNQtqjEy8f/WCFsJYkfGy6xQNTrSCzY/YkNwtaWWLbwNdRiQYmTM5+wTGAUm4Vk 7CwkLbOQtMxC0rKAkWUVI3tuYmZOernRJkZg1Bzc8lt1B+OdcyKHGKU5WJTEeZO5GgOFBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MNZnxgk9e76r5f/2c51ub7Uc8/7WzPA5GP9potOxWCun hzeYHbe+smxJL1RpW7FoaUC2UPp55poMg4Onlredn/PkaqvmnC33bX7ySW0WkJrZGPMkIV3L dtbGgvOTb8o6bQvR7p7oGtm+WnBHZcpEQ//VVQddF0YYdDd6ZUq/y+2qrEn3bZO4qsRSnJFo qMVcVJwIABLN7v5oAgAA Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:31:35 -0000 Hi, >>>> Q4: >>>> >>>> We need to keep in mind that there is always a chance that the "top-mo= st" m- line within a bundle group is a port zero one. >>> >>> What is the question? >> >> Well, there are basically two "warm-up" questions: >> >> Q4_1: When the first offer, with DIFFERENT port numbers is sent, and the= receiver accepts bundle, is the receiver expected to be able to send media= /data according to that? > > I hope so. Ok, so let's stick to that assumption for now. >> Q4_2: IF Q4_1 THEN which m- line does the receiver use to send media/dat= a (when the second offer comes, with identical port numbers, it is no longe= r an issue). > > Surely the bundle draft must specify this. > > My first thought is that the address/port of the *first* m-line in the bu= ndle with a non-zero port will be used for the entire bundle. > > (This means that when you initially offer a bundle with a bunch of separa= te ports, you not only must be prepared to use each of those for an unbundl= ed m-line, you must be prepared to use any of them for the complete bundle.= ) Yes, that is what I have been thinking also: until the second offer has bee= n sent and accepted, the offerer has to be able to receive media on any of = the offered ports. Because, the offerer cannot assume that media will come on the *first* non-= zero m-line in the offer, because the answerer could reject it.=20 OR, the answerer could accept the m- line but exclude it from a bundle, in = which case it will only send media associated to that m- line to the offere= d port - and the bundled media will be sent to some other port of the offer= ed bundle group. These are issues that I've had from the beginning with offering different p= orts in a bundle group, so I would really like the people (Cullen, Richard = E etc) that pushed for this to explain me how they intended to solve it :) Regards, Christer From christer.holmberg@ericsson.com Mon May 13 12:33:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA23421F93FC for ; Mon, 13 May 2013 12:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l46BMqFv+xzY for ; Mon, 13 May 2013 12:33:43 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 89C7921F8A7B for ; Mon, 13 May 2013 12:33:42 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-4c-51914015a338 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E4.D1.32006.51041915; Mon, 13 May 2013 21:33:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Mon, 13 May 2013 21:33:40 +0200 From: Christer Holmberg To: Jonathan Lennox , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: AQHOUA+KJ03b0bLKtEyP+xBXZ/VYR5kDgNOQ Date: Mon, 13 May 2013 19:33:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36F64D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36F1EB@ESESSMB209.ericsson.se> <5191033D.4040605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36F59E@ESESSMB209.ericsson.se> <519134FF.5010405@alum.mit.edu> <789CDEFF-5266-4F0B-8EE3-65D879840616@vidyo.com> In-Reply-To: <789CDEFF-5266-4F0B-8EE3-65D879840616@vidyo.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvra6ow8RAg1WTDCz2Lz7PbDF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHm3P7rAHMEdx2aSk5mSWpRbp2yVwZWw49Ye54AB7xaeepAbG j6xdjJwcEgImEh8OvWeCsMUkLtxbz9bFyMUhJHCYUWLBmweMEM4SRon/v7YCORwcbAIWEt3/ tEEaRAT8JF72f2MCCTMLqEtcXRwEYgoDVXzZVQtiighYSqy+7wVRbCSx//tcsE0sAqoSk58s ZAGxeQV8JRZd62WFWDSfTWLVjHcsIL2cArYS619qgdQwAl32/dQasF5mAXGJDwevM0NcLCCx ZM95KFtU4uXjf1BfKUn82HCJBaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo9gsJGNnIWmZ haRlFpKWBYwsqxjZcxMzc9LLjTYxAuPl4JbfqjsY75wTOcQozcGiJM6bzNUYKCSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoExrPArF5N5t4RavJZ0geCuio6CvUprDpsY77utZ5ohJmWZ32xx +/7qA8KLrrrqsO4vzDT96L50X/5/q2h7u4ZNxX+9H9dfTpW12mzseOprsLKXqN7Hc6EnKm4W bql4p9r/WPB0347XOV9exGv79vOsTOn47sFfKuISci5vSYe8/sV/TeE3UpVYijMSDbWYi4oT AchCBE1lAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:33:49 -0000 Hi, >> Surely the bundle draft must specify this. >>=20 >> My first thought is that the address/port of the *first* m-line in the=20 >> bundle with a non-zero port will be used for the entire bundle. >>=20 >> (This means that when you initially offer a bundle with a bunch of=20 >> separate ports, you not only must be prepared to use each of those for=20 >> an unbundled m-line, you must be prepared to use any of them for the=20 >> complete bundle.) > > An offerer sends an initial offer with a bundle of two m-lines: one with = port 20000, one with 30000. > > The answerer answers, rejecting the first m-line (with port zero) but acc= epting the bundle. Or, the answerer accepts the first m- line, but excludes it from the bundle= . Maybe we need to re-think whether it should be allowed to exclude an m- l= ine from a bundle in the answer... > Should the answerer send traffic to port 20000 or port 30000? Regards, Christer From pkyzivat@alum.mit.edu Mon May 13 12:34:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC21721F8A7B for ; Mon, 13 May 2013 12:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.292 X-Spam-Level: X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfeAwfPW23Hh for ; Mon, 13 May 2013 12:34:10 -0700 (PDT) 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 EEB9421F955A for ; Mon, 13 May 2013 12:34:09 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA11.westchester.pa.mail.comcast.net with comcast id bWX81l0050mv7h05BXa9XR; Mon, 13 May 2013 19:34:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id bXa91l00Q3ZTu2S3XXa9p1; Mon, 13 May 2013 19:34:09 +0000 Message-ID: <51914030.8070603@alum.mit.edu> Date: Mon, 13 May 2013 15:34:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jonathan Lennox References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <518D73E4.4090609@alum.mit.edu> <9D12C4E8-F7C1-4D32-A8AC-570AC86ACA23@vidyo.com> <518D9361.7060301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC03@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36F1EB@ESESSMB209.ericsson.se> <5191033D.4040605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36F59E@ESESSMB209.ericsson.se> <519134FF.5010405@alum.mit.edu> <789CDEFF-5266-4F0B-8EE3-65D879840616@vidyo.com> In-Reply-To: <789CDEFF-5266-4F0B-8EE3-65D879840616@vidyo.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=1368473649; bh=FAAi7VX573lirSYU21aKxpDWK9NAMbD9b5c/LOdkIp0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KfTluyDp3NV+UjEtBptDa62wrX+YWMytsjUAbdG19sWjBfOXIRFzZb8/qyWL3W8OQ j3RiM/6PEgXqXfYmkVJ8Zwmo97WDh+PA6W8NL6x1asrlTIPYigU3nR+B8ImbfDGeHr jmKF1OnfJzTf2PB/UjcLAuKCS+8B6j1HXyYjEF72JBw68IYdHq8Vt451hbN29afPxs yr2FfcuBIWHwAzC9KYGOYEH4kwNATBm8O8EWBj1MuiQHNqxaH83Oln+9r+h3ya/uP9 KKa5450tjZm5I8bgetZZxByoAGI71H5Y058YEQ13YCiDJ3P40CyGAP2cveHIomglc3 B+2c6OmVEc72Q== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:34:16 -0000 On 5/13/13 3:24 PM, Jonathan Lennox wrote: > > On May 13, 2013, at 2:46 PM, Paul Kyzivat wrote: > >> Surely the bundle draft must specify this. >> >> My first thought is that the address/port of the *first* m-line in the >> bundle with a non-zero port will be used for the entire bundle. >> >> (This means that when you initially offer a bundle with a bunch of >> separate ports, you not only must be prepared to use each of those for >> an unbundled m-line, you must be prepared to use any of them for the >> complete bundle.) > > An offerer sends an initial offer with a bundle of two m-lines: one with port 20000, one with 30000. > > The answerer answers, rejecting the first m-line (with port zero) but accepting the bundle. > > Should the answerer send traffic to port 20000 or port 30000? Well, I hadn't considered that possibility, but it is one. It seems a little weird, but it might have have some benefits for implementation. I guess I don't have a strong opinion, other than the spec must clearly say which way it will be. Thanks, Paul From jonathan@vidyo.com Mon May 13 12:38:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129F421F9408 for ; Mon, 13 May 2013 12:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux-I4y9MTIlF for ; Mon, 13 May 2013 12:38:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id EC33621F93FC for ; Mon, 13 May 2013 12:38:52 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6C9A45530C0; Mon, 13 May 2013 15:38:52 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E42BB552FD5; Mon, 13 May 2013 15:38:51 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 13 May 2013 15:37:30 -0400 From: Jonathan Lennox To: Paul Kyzivat Date: Mon, 13 May 2013 15:38:51 -0400 Thread-Topic: [MMUSIC] What is an m-line? Thread-Index: Ac5QEW67zgVkCn0cTTKTQGWs0xdEYA== Message-ID: <79FFE18A-D38C-4CEE-9113-EE2FC1E8D0FE@vidyo.com> References: <519138CB.5020202@alum.mit.edu> In-Reply-To: <519138CB.5020202@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:38:58 -0000 On May 13, 2013, at 3:02 PM, Paul Kyzivat wrote: >> RFC 4566 is helpfully devoid of detail, so we are free to come up with >> any interpretation we choose. Here are the ones that I have seen: >>=20 >> 1. an m-line represents a single RTP session >> (or at least the part of the session that touches the client) >> This appears to be consistent with the Plan B approach >=20 > Well, it was my impression that Plan B still intends to allow bundling=20 > in order to combine audio and video into a single RTP session. So in=20 > that case neither of the m-lines represents a single RTP session in full. Yes, the idea behind MMT was to preserve this interpretation of an m-line, = even as we added a/v mux, rather than forcing descriptions of RTP sessions = to be spread across multiple parts of the SDP. The WG prefers BUNDLE to MMT, though, so I guess we're going to have to cop= e with description spreading, regardless of which of the current plans on t= hat're on the table are accepted. -- Jonathan Lennox jonathan@vidyo.com From martin.thomson@gmail.com Mon May 13 13:45:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D62D21F8F87 for ; Mon, 13 May 2013 13:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoAOw5ptLe58 for ; Mon, 13 May 2013 13:45:26 -0700 (PDT) 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 A552321F8FB6 for ; Mon, 13 May 2013 13:45:25 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w60so6824989wes.17 for ; Mon, 13 May 2013 13:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=F5edP+WEByIaXwhtpwnS47BphPgTxRYJ/g1kFWBsyzA=; b=TXkV/lNsJ6ZVukpBrQ/e9iJXbMpLMSsbnuW+U4G0kbbq+EOG10RYdQZsqnUR8RsP4x EitJb/vqSeob1/6R8Kdd5zjQNbOcg6pvdD8O1q9x486LsVtL01mxIx/eD0IhnV+RcUkZ h/57qT7kkzehNTaT1o7nCoYpxkG39Eq15qY21glQ96RG2gCs6G9W6YP5XERfpFlNJbLz 9h/fYAW7RqkX9/eLwKj9iNAEXb5L9dJgSvXYuFoUQXZyJfY9giEhjcV5NOXDkFUeJwiC YOgNc0VW00MWXKVV4cs0CMFwZLjFzkeAUtjC6pkLqaWPv3DVKWb4L9w3AJ6lF/klI2VX It9g== MIME-Version: 1.0 X-Received: by 10.180.74.207 with SMTP id w15mr7875145wiv.19.1368477924807; Mon, 13 May 2013 13:45:24 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Mon, 13 May 2013 13:45:24 -0700 (PDT) In-Reply-To: <519138CB.5020202@alum.mit.edu> References: <519138CB.5020202@alum.mit.edu> Date: Mon, 13 May 2013 13:45:24 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 20:45:26 -0000 On 13 May 2013 12:02, Paul Kyzivat wrote: > On 5/13/13 2:42 PM, Martin Thomson wrote: >> 1. an m-line represents a single RTP session >> (or at least the part of the session that touches the client) >> This appears to be consistent with the Plan B approach > > Well, it was my impression that Plan B still intends to allow bundling in > order to combine audio and video into a single RTP session. So in that case > neither of the m-lines represents a single RTP session in full. "In full" ain't gonna happen, ever :) With RTP you are always the blind man with his tiny piece of the elephant. Hence, I think that your (4) is a clearer description of what I intended to say. > I offer another try: > > 4. an m-line represents one or more (zero or more?) > sources/flows/tracks/captures (pick the name that suits you) that share a > single RTP session and that all are consistent with the media description > accompanying the m-line. >> 2. an m-line represents the set of RTP streams that decode into a >> single rendering, including layers, simulcast and FEC > > Hmm. I was thinking *this* was what Cullen intended by Plan A. > But now that you bring it up, I thing there is some existing SDP syntax for > simulcast/FEC/FID that might only work with (3). (But I don't have the > details of that stuff in my head.) That existing stuff is what nudged this into a (3). a=depend and a few other things make it hard to get all the streams onto the one line. From martin.thomson@gmail.com Mon May 13 13:47:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD70B21F944F for ; Mon, 13 May 2013 13:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhVhhopSSeGJ for ; Mon, 13 May 2013 13:47:15 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0A17F21F9003 for ; Mon, 13 May 2013 13:47:14 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so6562021wgh.13 for ; Mon, 13 May 2013 13:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=02tptXlxdya6E6x+fzJ5QkTr9kCcGPe/xairS8wj08w=; b=XyBYKNXvD+2kh4OgrmtB2A6aZpK3OWyaZsk5sYiGhpQcGSMFdh+s4chocioWaZ/Z2g 7H0Is6bYdD+l6jxDgoCqth0sR08hnlY9xCy4bTI/cfDlsNHbdjEjiU65IETlEYgADcb0 MPxxT9o2Gyf35R15uy/tUuZGll/2/LwGwrTEf8ZFDCyN/bcqh5PSvqRimY0WD5m/m8z/ tvw6AfUdYmjyekpD0HOT2FWt3hxiL64s3OYzpPK5koOqsb+15lbEY6AWUpfbItfhsScC /Pj7oxHAymwgLZqj4fpt7FB0XHwQYdgDd7+S019to7XY7uKsQ1JIfiq7yQm++HBa4vPV ioSg== MIME-Version: 1.0 X-Received: by 10.180.198.49 with SMTP id iz17mr22314934wic.19.1368478034182; Mon, 13 May 2013 13:47:14 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Mon, 13 May 2013 13:47:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 May 2013 13:47:14 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 20:47:15 -0000 On 13 May 2013 12:14, Bernard Aboba wrote: > [...] Approach #1 is also > consistent with the multicast scenarios envisaged in the early days of SDP, > where multiple SSRCs could send to the same multicast address and port. Oops, I meant to try to head this line of reasoning off. Let's talk about offer/answer only. I'd rather not boil two oceans. From bernard_aboba@hotmail.com Mon May 13 14:09:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25EA21F8EB1 for ; Mon, 13 May 2013 14:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDxFUZFOJzYZ for ; Mon, 13 May 2013 14:09:36 -0700 (PDT) Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by ietfa.amsl.com (Postfix) with ESMTP id BCCD121F8EA4 for ; Mon, 13 May 2013 14:09:35 -0700 (PDT) Received: from BLU169-W46 ([65.55.116.73]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 14:09:29 -0700 X-EIP: [nEh+6yKqkQTrrXxT2GAbQ68OcNHa4LMeJPP3kU3D0ns=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_6737340a-f5db-486e-9dc7-e284a4fac5f8_" From: Bernard Aboba To: Gunnar Hellstrom , "mmusic@ietf.org" Date: Mon, 13 May 2013 14:09:28 -0700 Importance: Normal In-Reply-To: <5150A8CE.1030504@omnitor.se> References: , , <515063C3.3040700@alum.mit.edu>, <5150A8CE.1030504@omnitor.se> MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2013 21:09:29.0011 (UTC) FILETIME=[27F7B830:01CE501E] Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 21:09:42 -0000 --_6737340a-f5db-486e-9dc7-e284a4fac5f8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gunnar said:=20 > This could first lead to an effort to route the call to an endpoint that= =20 > has declared more suitable language and modality preferences and=20 > capabilities. [BA] The call routing aspect is probably best handled via SIP headers=2C ju= st as in RFC 6442 we define the Geolocation and Geolocation-Routing Headers= . =20 > Secondly it can lead to addition of a relay service or translation=20 > service if one of the parties has access to such services. It can be=20 > added in a three-party call fashion=2C translating languages or modalitie= s=20 > as needed. [BA] The SIP headers might lead to the call being routed to an endpoint tha= t supports the desired servicesnatively=2C or it might not. The O/A exchan= ge will disclose whether the desired services are available=2C or not. It c= ould be that an entity indicating a language capability in its Answer might= have them available on site=2C ormight have to call out to obtain them=2C = but that doesn't matter to the Offerer as long as they can be deliveredby t= he Answerer. On the other hand=2C if the Answerer doesn't have the require= d services=2C the Offerer mightdecide to add them on its own=2C by making a= nother call to a relay or translation service=2C possibly joining thatcall = to the initial one.=20 > If the one who is not using the mechanism is declaring audio and text=20 > media capabilities=2C it will be harder to select what to do. > The one supporting the mechanism may prefer to use sign language. Having= =20 > no indication why the other party declares video capability=2C it may be= =20 > risky to just connect them. [BA] I agree. Just because a party declares capabilities doesn't necessaril= y mean that they are able to use them in the manner that is needed. Just f= rom an indication of the supported media (e.g. video=2C text=2C audio) you = won't know if the Answerer supports ASL interpretation=2C or whether they'r= e trained and willing to transcribe audio to text and back. So it's probabl= y best if support for these services is made explicit.=20 > So=2C yes=2C there are many use case variations that need to be captur= ed=20 > and best approach described. [BA] It seems to me that what is needed is a set of tools that can be combi= ned in different ways to address the different use cases. The tools can in= clude SIP headers=2C SDP negotiation=2C and call control functionality. On= ce you have the tools=2C you can describe how different use cases can be ad= dressed using them. = --_6737340a-f5db-486e-9dc7-e284a4fac5f8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Gunnar said: =3B

>=3B This could first lead to an effort to route the call to an endpoin= t that
>=3B has declared more suitable language and modality preferen= ces and
>=3B capabilities.

[BA] The call rou= ting aspect is probably best handled via SIP headers=2C just as in RFC 6442= we define the Geolocation and =3BGe= olocation-Routing Headers.  = =3B =3B

>=3B Secondly it can lead to addition of= a relay service or translation
>=3B service if one of the parties ha= s access to such services. It can be
>=3B added in a three-party call= fashion=2C translating languages or modalities
>=3B as needed.
=

[BA] The SIP headers might lead to the call being route= d to an endpoint that supports the desired services
natively=2C o= r it might not.  =3BThe O/A exchange will disclose whether the desired = services are available=2C or not. =3B
It could be that an ent= ity indicating a language capability in its Answer might have them availabl= e on site=2C or
might have to call out to obtain them=2C but that= doesn't matter to the Offerer as long as they can be delivered
b= y the Answerer.  =3BOn the other hand=2C if the Answerer doesn't have t= he required services=2C the Offerer might
decide to add them on i= ts own=2C by making another call to a relay or translation service=2C possi= bly joining that
call to the initial one. =3B

<= /div>
>=3B If the one who is not using the mechanism is declaring aud= io and text
>=3B media capabilities=2C it will be harder to select wh= at to do.

>=3B The one supporting the mechanism = may prefer to use sign language. Having
>=3B no indication why the ot= her party declares video capability=2C it may be
>=3B risky to just c= onnect them.

[BA] I agree. Just because a party de= clares capabilities doesn't necessarily mean that they are able to use them= in the manner that is needed.  =3BJust from an indication of the suppo= rted media (e.g. video=2C text=2C audio) you won't know if the Answerer sup= ports ASL interpretation=2C or whether they're trained and willing to trans= cribe audio to text and back. So it's probably best if support for these se= rvices is made explicit. =3B

>=3B So=2C y= es=2C there are many use case variations that need to be captured
>= =3B and best approach described.

[BA] It seems to m= e that what is needed is a set of tools that can be combined in different w= ays to address the different use cases.  =3BThe tools can include SIP h= eaders=2C SDP negotiation=2C and call control functionality.  =3BOnce y= ou have the tools=2C you can describe how different use cases can be addres= sed using them.  =3B
= --_6737340a-f5db-486e-9dc7-e284a4fac5f8_-- From worley@shell01.TheWorld.com Mon May 13 16:53:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C392B21F957D for ; Mon, 13 May 2013 16:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HVbtGWoDaGj for ; Mon, 13 May 2013 16:53:39 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5FE21F958A for ; Mon, 13 May 2013 16:53:38 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4DNrUIc025298; Mon, 13 May 2013 19:53:32 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4DNrUDd4710087; Mon, 13 May 2013 19:53:30 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4DNrTrr4646686; Mon, 13 May 2013 19:53:29 -0400 (EDT) Date: Mon, 13 May 2013 19:53:29 -0400 (EDT) Message-Id: <201305132353.r4DNrTrr4646686@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <519103E1.8030200@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B1C36F22F@ESESSMB209.ericsson.se> <519103E1.8030200@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: Splitting a BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 23:53:44 -0000 > From: Paul Kyzivat > > On 5/13/13 7:58 AM, Christer Holmberg wrote: > > > > We seem to have an agreement that, when an SDP offer contains an m- line > > associated with a bundle group, it is ok to leave that m- line outside > > the bundle group in the SDP Answer. > > > > Now, there has been some discussions about b> > Yes, this is the conclusion I reached. I wish it weren't true. But I > think there must be a mechanism for the new bundle to be rejected, and > if it is first proposed in the answer then that isn't possible. > > IMO this is a rare enough case that suffering another O/A is acceptable. I agree with Paul here. Allowing a new group (bundle) to be created in an answer is a much larger deviation from RFC 5888 than allowing an m= line with a zero port to be in a group, and the accept/reject problem can't be solved. Dale From wwwrun@rfc-editor.org Mon May 13 21:21:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C57F11E80F1 for ; Mon, 13 May 2013 21:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOwX+fTKbn2b for ; Mon, 13 May 2013 21:21:10 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A3AA811E80E8 for ; Mon, 13 May 2013 21:21:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BFAE062106; Mon, 13 May 2013 21:21:07 -0700 (PDT) To: jdrosen@jdrosen.net, rlb@ipv.sx, gonzalo.camarillo@ericsson.com, fandreas@cisco.com, ari.keranen@ericsson.com From: RFC Errata System Message-Id: <20130514042107.BFAE062106@rfc-editor.org> Date: Mon, 13 May 2013 21:21:07 -0700 (PDT) Cc: akundu@us.ibm.com, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] [Technical Errata Reported] RFC5245 (3619) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 04:21:11 -0000 The following errata report has been submitted for RFC5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3619 -------------------------------------- Type: Technical Reported by: Ashish Kundu Section: Section 4, 5 Original Text ------------- Missed candidate pair in ICE standard Corrected Text -------------- Scenario: X is caller, Z is callee. X is behind a non-full-cone (such as symmetric) NAT, Z is behind a full-cone NAT. ICE standard: Section 2.1 of RFC5245 describes the addresses that are collected as candidate addresses: (local address, server-reflexive address, TURN relay address). For X: (X:x, X1:x1, Yx:yx), and for Z: (Z:z, Z1:z1, Yz:yz). Missed candidate pair in ICE standard: 1. X:x sends a connection check message to the Z1:z1 (as part of the process in Section 2.2 of the standard) 2. Since X is behind a non-full cone NAT such a symmetric one, NAT of X maps X:x to X2:x2, sends the message to Z1:z1 3. Z is behind a full-cone NAT, so packets received at Z1:z1 address is forwarded to Z:z by the NAT Since X is behind a non-full cone NAT such a symmetric one and Z is behind a full-cone NAT, connection from X:x to Z1:z1 would be via a server-reflexive address X2:x2 of X, which is not a candidate address for X as specified by ICE. X2:x2 should be a candidate address of X, which however can only be determine when X sends a message to Z. The pair (X2:x2, Z1:z1) provides a direct connection option between X and Y. Conditions on which X2:x2 is a valid candidate address: 1. One of the peers (Z) is behind a full-cone NAT, else step 3 above does not succeed. 2. X2:x2 is unique, i.e., different from X1:x1 (already covered by Section 2.1) if and only if one of the peers is behind a non-full-cone NAT. So I think there should be two stages in the candidate collection process: A: Section 2.1 -- candidate addresses independent of the other clients B: collection of the candidate pairs with respect to the peer, such as X2:x2 and Z2:z2, if any. B consists of the following steps including 1, 2, and 3: 4. Z:z determines if X2:x2 from which it received the message is a different address than in the candidate set of X. 5. If 4 is true, then send an OK message to X2:x2 that it received the message with X2:x2 XOR-encoded. 6. X:x receives the OK message in 4, then X:x determines X2:x2 as its new candidate address. If X:x decides to establish the connection via X2:x2, it sends ACK message to Z2:z2. Notes ----- This feedback for improvement of ICE candidate gathering and decision process was sent to Dr. Rosenberg on Nov 09, 2012. However, since I have not received any response from him over my next two followups and this e-mail, I thought it should be reported via this method. This is not an error mesage, but a method to improve the candidate gathering and decision process of ICE. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5245 (draft-ietf-mmusic-ice-19) -------------------------------------- Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Publication Date : April 2010 Author(s) : J. Rosenberg Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From stefan.lk.hakansson@ericsson.com Tue May 14 01:24:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EB121F8F7A; Tue, 14 May 2013 01:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU1giYeyIDB0; Tue, 14 May 2013 01:24:27 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3521F853A; Tue, 14 May 2013 01:24:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-ea-5191f4b8aeeb Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 45.18.28165.8B4F1915; Tue, 14 May 2013 10:24:25 +0200 (CEST) Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 14 May 2013 10:24:24 +0200 Message-ID: <5191F4B8.2020602@ericsson.com> Date: Tue, 14 May 2013 10:24:24 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Bernard Aboba References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGfG3Vnfnl4mBBmdesVrsX3KZ2WLq8scs Fmv/tbM7MHs87jnD5rFkyU+mAKYoLpuU1JzMstQifbsEroy//dcYC3axVBx/f4mxgXEfcxcj B4eEgInEvcUyXYycQKaYxIV769m6GLk4hAROMUosOP8BylnLKNHQO48VpIpXQFvi5+mbjCA2 i4CqxIqT3UwgNptAsMT+5SDdnByiAlES/97uZoSoF5Q4OfMJC8gyEQFdib9dRiBhZgF/iXNX 9oOVCAt4S2zbsJAZYtdjZokrs1+xgyQ4BWwlfuztYoJosJBY/OYgO4QtL9G8dTYziC0ENPPd 63usExgFZyFZNwtJyywkLQsYmVcxsucmZuaklxtuYgQG58Etv3V3MJ46J3KIUZqDRUmcN4mr MVBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY1vFIc/Yx91qr89cN5Qzc0g9IVe17vTyGUeC Iz72PMvcdkk5ctm86fx3F2s5XVwxMajDstmk3LnoZla3jazi5tTo3a1K737OEnp/ye57d8pO pimX+hd/ic2V1vk91di7JD45RTCKYcaFpOv7k1Z/DueKL90reYEtoSzoZQffcpvKQ8fycjP7 lViKMxINtZiLihMBk+7HTxwCAAA= Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 08:24:33 -0000 On 2013-05-13 19:58, Bernard Aboba wrote: > > > On May 12, 2013, at 10:18, "Stefan HÃ¥kansson LK" > wrote: > >>> I would hope there will normally not be SDP changes for either of >>> those events. >> >> I would like to avoid them too, but I'm not sure how. > > [BA] It is probably not possible to avoid them in all cases, but we > can define RTCP functionality which along with some set of > functionality (e.g. Simulcast, layered coding) will minimize them. > This is worth doing (and soon). I agree to this! > From emil@sip-communicator.org Tue May 14 02:17:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EA721F8FF2 for ; Tue, 14 May 2013 02:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mP-WLTN1O5O for ; Tue, 14 May 2013 02:17:17 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AE4BE21F8FFC for ; Tue, 14 May 2013 02:17:16 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id na1so161644bkb.1 for ; Tue, 14 May 2013 02:17:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=pWZoClTW+zwDJlOSioReaJv9gTI/+j4j8rp8e7VLXcI=; b=JJPLqPICHuO0ZfAyYFSxbnPqvh2xR8TS9wNy3UaNWTlIb3QBiLCfZ7Dwdb9ybsq59N 6qDD29nlayrju1pD192Smv70lKMBeSb2PO6zXTRMcJr2jp3jf8p4OeSbumWIE01nTMvI 41xDsBFNq5xWcDZJeC1V5XNy1H4p7PH6W+WVqlb4Xc4wZ/LvkuM/aaum2YuvIz9OmkHc Ya8L33A19P8WLv0O9uDz+lSGQ1Q3zG6Dsia9A4fd9LJ6Vrs0LawItBacr+Mj3RNuX9Nk 8LMeSUcWRk70sSXt9oVTIzsCtn9jhOrFx4lqLZWPrv/HRrf0WF8Ef54uS7wiCExYdjxS g0GQ== X-Received: by 10.205.46.193 with SMTP id up1mr7222053bkb.65.1368523035503; Tue, 14 May 2013 02:17:15 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id tl1sm3292819bkb.7.2013.05.14.02.17.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 May 2013 02:17:14 -0700 (PDT) Message-ID: <5192011A.8030903@jitsi.org> Date: Tue, 14 May 2013 12:17:14 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <5191F4B8.2020602@ericsson.com> In-Reply-To: <5191F4B8.2020602@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl6Vq4DwTJU0zmflOXbfJvCviApsmGXK4Fx4xsJbn0CypqQ+hAcTErF9VpsChn01XWMamCB Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 09:17:17 -0000 On 14.05.13, 11:24, Stefan H=C3=A5kansson LK wrote: > On 2013-05-13 19:58, Bernard Aboba wrote: >> >> >> On May 12, 2013, at 10:18, "Stefan H=C3=A5kansson LK" >> wrote: >> >>>> I would hope there will normally not be SDP changes for either of >>>> those events. >>> >>> I would like to avoid them too, but I'm not sure how. >> >> [BA] It is probably not possible to avoid them in all cases, but we >> can define RTCP functionality which along with some set of >> functionality (e.g. Simulcast, layered coding) will minimize them. >> This is worth doing (and soon). >=20 > I agree to this! RTCP `certainly sounds a lot better than SDP O/A Emil --=20 https://jitsi.org From christer.holmberg@ericsson.com Tue May 14 05:01:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E55221F8EED for ; Tue, 14 May 2013 05:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diPHGsBfBZGZ for ; Tue, 14 May 2013 05:01:07 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3D821F8E99 for ; Tue, 14 May 2013 05:01:06 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-eb-519227812242 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5A.56.32006.18722915; Tue, 14 May 2013 14:01:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Tue, 14 May 2013 14:01:05 +0200 From: Christer Holmberg To: "Dale R. Worley" , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE: Splitting a BUNDLE Thread-Index: AQHOUDUR9NWS3FUwQ2O4qnaDoH5QzZkEk5gA Date: Tue, 14 May 2013 12:01:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3700A9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36F22F@ESESSMB209.ericsson.se> <519103E1.8030200@alum.mit.edu> <201305132353.r4DNrTrr4646686@shell01.TheWorld.com> In-Reply-To: <201305132353.r4DNrTrr4646686@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvrW6j+qRAg3k3TCymLn/MYrFiwwFW i5cnyhyYPf6+/8DkMXn/V2aPJUt+MgUwR3HZpKTmZJalFunbJXBltDTNZSnYxVmxd9Vq5gbG hexdjJwcEgImEvffLGKCsMUkLtxbzwZiCwkcZpTYO7myi5ELyF7CKPF/3UHmLkYODjYBC4nu f9ogNSICgRLbuk6zgoSZBdQlri4OAgkLCxhItDUvYIUoMZR49+sVI4RtJNH0fDpYnEVAVWLp 2l4WEJtXwFfiy+sWdohVSxkl7n75AHYPp4CDxLr1M5hBbEag276fWgMWZxYQl7j1ZD7UzQIS S/acZ4awRSVePv7HCmErSrQ/bWCEqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlI WmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAmDm45bfqDsY750QOMUpzsCiJ8yZzNQYKCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYJTtvRvZHNzAciKxqfTyK/NO7jcXyr0Prij/IvR3rWqs/ynd G+K7/wpUmt6Is5x1VM1KvX77rhLTdUXX9u2++IhlbsaFJZ3ti1jfrWOY2XrTtnreBfbTicUV SkY8SRPF3R53tt01X9w6hc1B3NAmbKKp1qep3ZHbV1W+ENC4Hfxgs45M1A6NYiWW4oxEQy3m ouJEANj/7mhnAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Splitting a BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 12:01:13 -0000 Hi, >>> We seem to have an agreement that, when an SDP offer contains an m-=20 >>> line associated with a bundle group, it is ok to leave that m- line=20 >>> outside the bundle group in the SDP Answer. >>> >> Now, there has been some discussions about b> >> Yes, this is the conclusion I reached. I wish it weren't true. But I=20 >> think there must be a mechanism for the new bundle to be rejected, and=20 >> if it is first proposed in the answer then that isn't possible. >>=20 >> IMO this is a rare enough case that suffering another O/A is acceptable. > > I agree with Paul here. Me too :) > Allowing a new group (bundle) to be created in an answer is a much larger= deviation from RFC 5888 than allowing an m=3D line with a zero port to be = in a group, and the accept/reject problem can't be solved. Note that there are two cases: 1) A new bundle is created in the answer 2) An m- line is moved from bundle_x in the offer to bundle_y in the answer= . bundle_y was also present in the offer, so it is not created by the answe= rer. In my opinion 2) should not be allowed either, as the m- line was not prese= nt in bundle_y in the offer. Regards, Christer From ari.keranen@ericsson.com Tue May 14 05:21:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90E621F901F for ; Tue, 14 May 2013 05:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o66zEasnQLpN for ; Tue, 14 May 2013 05:21:50 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5E56121F8F7B for ; Tue, 14 May 2013 05:21:47 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-c5-51922c5b8c07 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A3.4A.01956.B5C22915; Tue, 14 May 2013 14:21:47 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Tue, 14 May 2013 14:21:46 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8C1ED24C4; Tue, 14 May 2013 15:21:46 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 89E7F54E38; Tue, 14 May 2013 15:21:45 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CDF6454E36; Tue, 14 May 2013 15:21:44 +0300 (EEST) Message-ID: <51922C59.5080309@ericsson.com> Date: Tue, 14 May 2013 15:21:45 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: akundu@us.ibm.com References: <20130514042107.BFAE062106@rfc-editor.org> In-Reply-To: <20130514042107.BFAE062106@rfc-editor.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvrW60zqRAg7WTBC0OPvnMbPH+gq5F 8/Nl7BZTlz9msWja/5XNYmqfrQObx5TfG1k9liz5yeQxeeMsFo/W9TMZPRrajrF6nLvWxxzA FsVlk5Kak1mWWqRvl8CV8eCyU8EdxYpj7/YzNTA+k+pi5OSQEDCR+HzmGBOELSZx4d56ti5G Lg4hgVOMEg293UwQzgZGiRvrNkE5uxklNvT/YIRw1jFK9Fxaxg7SLySwglFi2gpJEJtXQFvi 1PGTzCA2i4CqxOmDvxhBbDYBe4mbE66D1YsKJEss3bmUDaJeUOLkzCcsILaIgKjEl7n7wBYw C8xllLi/eiFQEQeHsIC5xONVjhC7zCSeXpsM1ssJFH767jVYL7OArcSFOdehbHmJ7W/nMEP8 piZx9dwmZoheVYmr/14xTmAUnYVk9Swk7bOQtC9gZF7FyJ6bmJmTXm6+iREYQwe3/DbYwbjp vtghRmkOFiVx3mSuxkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjK5/w7YGnnZWX/tNeDV/ RFvDs/SDK6P/lFyw38HFfrZv5pXF3pKT/3bdt1STbdm9OizL9979vIusB2a8/yMrpPqtLyq2 7ExZvPKLsx3s1R1BE7mL2ywMCnuXWPy/8euR0eGZCyKyH5f84tTrlPedy/2ulks4ceHSe8aS fkmr1LhDdhuIZ9duUGIpzkg01GIuKk4EAB2X1lVvAgAA Cc: mmusic@ietf.org, jdrosen@jdrosen.net, gonzalo.camarillo@ericsson.com, fandreas@cisco.com, RFC Errata System Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5245 (3619) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 12:21:56 -0000 Hi Ashish, Peer Reflexive candidate discovery (see, e.g., Sections 7.1.3.2.1 and 7.2.1.3. of RFC 5245) should take care of that case. Cheers, Ari On 5/14/13 7:21 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC5245, > "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3619 > > -------------------------------------- > Type: Technical > Reported by: Ashish Kundu > > Section: Section 4, 5 > > Original Text > ------------- > Missed candidate pair in ICE standard > > Corrected Text > -------------- > Scenario: X is caller, Z is callee. X is behind a non-full-cone (such as symmetric) NAT, Z is behind a full-cone NAT. > > ICE standard: Section 2.1 of RFC5245 describes the addresses that are collected as candidate addresses: (local address, server-reflexive address, TURN relay address). For X: (X:x, X1:x1, Yx:yx), and for Z: (Z:z, Z1:z1, Yz:yz). > > Missed candidate pair in ICE standard: > 1. X:x sends a connection check message to the Z1:z1 (as part of the process in Section 2.2 of the standard) > 2. Since X is behind a non-full cone NAT such a symmetric one, NAT of X maps X:x to X2:x2, sends the message to Z1:z1 > 3. Z is behind a full-cone NAT, so packets received at Z1:z1 address is forwarded to Z:z by the NAT > > Since X is behind a non-full cone NAT such a symmetric one and Z is behind a full-cone NAT, connection from X:x to Z1:z1 would be via a server-reflexive address X2:x2 of X, which is not a candidate address for X as specified by ICE. X2:x2 should be a candidate address of X, which however can only be determine when X sends a message to Z. The pair (X2:x2, Z1:z1) provides a direct connection option between X and Y. > > Conditions on which X2:x2 is a valid candidate address: > 1. One of the peers (Z) is behind a full-cone NAT, else step 3 above does not succeed. > 2. X2:x2 is unique, i.e., different from X1:x1 (already covered by Section 2.1) if and only if one of the peers is behind a non-full-cone NAT. > > So I think there should be two stages in the candidate collection process: > A: Section 2.1 -- candidate addresses independent of the other clients > B: collection of the candidate pairs with respect to the peer, such as X2:x2 and Z2:z2, if any. > > B consists of the following steps including 1, 2, and 3: > 4. Z:z determines if X2:x2 from which it received the message is a different address than in the candidate set of X. > 5. If 4 is true, then send an OK message to X2:x2 that it received the message with X2:x2 XOR-encoded. > 6. X:x receives the OK message in 4, then X:x determines X2:x2 as its new candidate address. > > If X:x decides to establish the connection via X2:x2, it sends ACK message to Z2:z2. > > Notes > ----- > This feedback for improvement of ICE candidate gathering and decision process was sent to Dr. Rosenberg on Nov 09, 2012. However, since I have not received any response from him over my next two followups and this e-mail, I thought it should be reported via this method. > > This is not an error mesage, but a method to improve the candidate gathering and decision process of ICE. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5245 (draft-ietf-mmusic-ice-19) > -------------------------------------- > Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols > Publication Date : April 2010 > Author(s) : J. Rosenberg > Category : PROPOSED STANDARD > Source : Multiparty Multimedia Session Control > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > From fluffy@cisco.com Tue May 14 06:58:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB5F21F90CC for ; Tue, 14 May 2013 06:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.299 X-Spam-Level: X-Spam-Status: No, score=-108.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QshPEOkcmMAe for ; Tue, 14 May 2013 06:58:50 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AEED921F9051 for ; Tue, 14 May 2013 06:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2547; q=dns/txt; s=iport; t=1368539930; x=1369749530; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Qhld5fOLfLme2uWi7tdb5CbMb8mxLKJ5lhxTRaGVwho=; b=hu6PEO8W0WSW4zJrJc4LquWdH15MPU4Z9T78AjU/5vvdT11NDazFUtGN H7Q44D3zZtNDslW0B+2WffDr/l5ZxgCfuaRxQStWLbzJl9VT4yBqzOY4Y VASO9bcrYZj4r/8rtvzdPA4ktD//bKVm+ZaPXQkNNRRodpb/gjiVIqP9x 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFANhBklGtJV2Z/2dsb2JhbABagwc3wCt+FnSCHwEBAQMBAQEBNzQLBQsCAQgiFBAhBgslAgQKBAUIh3IDCQYMrkOGWA2IRASMSIIjAjEHgnRhA5VPjX+FI4MPgic X-IronPort-AV: E=Sophos;i="4.87,670,1363132800"; d="scan'208";a="210294564" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 14 May 2013 13:58:50 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4EDwnSm023117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 May 2013 13:58:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 14 May 2013 08:58:48 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [MMUSIC] What is an m-line? Thread-Index: AQHOUKsoppu4JUq1bUKGzbti4BOcIQ== Date: Tue, 14 May 2013 13:58:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <26CC9D6A2116D24483341B0DFF32ABDD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 13:58:55 -0000 People often want to look at this from the point of view of what they wish = they can change SDP to mean, but unless we are doing SDPng, we need to look= at it from the practical point of view of what has deployed and what SDP w= as defined as when that equipment deployed. We need to find a way that prov= ided backwards interoperabiliyt while still allowing us to negotiate the th= ings we want now. You can easily define an extension to SDP that means that= RTP received on a single m line was meant to be rendered in differnt windo= ws, but the fact of the matter remains that is not how lots of SIP equipmen= t worked so you can't pretend SDP always meant that because it did not. =20 On May 13, 2013, at 12:42 PM, Martin Thomson wro= te: > We've had a great deal of discussion about plan A and B and the > various interactions of these proposals with bundling. But I still > don't get a good sense that there is a working consensus on what an > m-line actually represents. >=20 > I think that we've each reached our own conclusions, but they > definitely are not consistent. We need a well-understood semantic for > m-lines if we have any chance of resolving these issues; Plan A/B > being only the first RTCWEB problem to address. >=20 > RFC 4566 is helpfully devoid of detail, so we are free to come up with > any interpretation we choose. Here are the ones that I have seen: >=20 > 1. an m-line represents a single RTP session > (or at least the part of the session that touches the client) > This appears to be consistent with the Plan B approach >=20 > 2. an m-line represents the set of RTP streams that decode into a > single rendering, including layers, simulcast and FEC >=20 > 3. an m-line represents a single RTP stream; multiple m-lines might > be required to obtain a single rendering if it uses layers, simulcast, > FEC or FID groupings > This appears to be consistent with the Plan A approach >=20 > In the first instance, an m-line can be multiple "things". In the > latter two cases, an m-line is consistently one "thing" (or part > thereof). >=20 > The first interpretation has a natural advantage in terms of signaling > economy and natural bundling. The latter interpretations seem to have > advantages in dealing with call transfer and SSRC renumbering. >=20 > So, which is correct? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Tue May 14 11:44:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3306E21F8FEC for ; Tue, 14 May 2013 11:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uQa5cEtwYVl for ; Tue, 14 May 2013 11:44:34 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 025DD11E80FA for ; Tue, 14 May 2013 11:44:32 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hq7so822624wib.0 for ; Tue, 14 May 2013 11:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8WTu8t/yrw9lac/r1nWipqLUIZO4iTXVVjfpimJlnUw=; b=iPi4wmcun/9WyGN7bVtRzwkdBL7J0e56A7o4GxH/wX+30HPweno9huJcbpR/5CL/aT 8fRxjsA9bKDm3fhoyv0M6G/oq8cwu+cICZHBK8e01rC4+DPQ+lImqSi/suec/+XlZ6Tl x7MivmOSHWQWbjDeUWgGj13hkF1NMSpM32tktN9brmMSwAsf1YPoXPHovzaw03+StpqF ZAAYKvMVxKdko39Xyu8bDpnHwgYTQJ/7h4tbbyMJGW+WhQf7oEgQss2AdGk3taNOLTal Bu1337TClL4RVp414qlPFML3KnRgrFlSyyzO8VmICiL1Sy6E6SBipKlummXFcgbnQVvE +cTw== MIME-Version: 1.0 X-Received: by 10.180.88.231 with SMTP id bj7mr9260702wib.5.1368557072043; Tue, 14 May 2013 11:44:32 -0700 (PDT) Received: by 10.194.20.135 with HTTP; Tue, 14 May 2013 11:44:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 May 2013 11:44:31 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 18:44:35 -0000 On 14 May 2013 06:58, Cullen Jennings (fluffy) wrote: > People often want to look at this from the point of view of what they wish they can change SDP to mean, That's the point of the question: what *is* an m-line? Not: what do you want an m-line to be? I suspect that the reality is an unstable superposition of states and we will need to pick a winner. --Martin From worley@shell01.TheWorld.com Tue May 14 13:37:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88A721F8F0F for ; Tue, 14 May 2013 13:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MShb-xlwGbbm for ; Tue, 14 May 2013 13:37:14 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id B143C21F81FF for ; Tue, 14 May 2013 13:37:14 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4EKapr4017182; Tue, 14 May 2013 16:36:53 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4EKaoh34758676; Tue, 14 May 2013 16:36:50 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4EKaope4759734; Tue, 14 May 2013 16:36:50 -0400 (EDT) Date: Tue, 14 May 2013 16:36:50 -0400 (EDT) Message-Id: <201305142036.r4EKaope4759734@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C3700A9@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1C36F22F@ESESSMB209.ericsson.se> <519103E1.8030200@alum.mit.edu> <201305132353.r4DNrTrr4646686@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C3700A9@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org, pkyzivat@alum.mit.edu Subject: Re: [MMUSIC] BUNDLE: Splitting a BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 20:37:20 -0000 > From: Christer Holmberg > > Note that there are two cases: > > 1) A new bundle is created in the answer > > 2) An m- line is moved from bundle_x in the offer to bundle_y in the > answer. bundle_y was also present in the offer, so it is not created > by the answerer. > > In my opinion 2) should not be allowed either, as the m- line was > not present in bundle_y in the offer. Ugh, yes. Especially since the offerer probably does not want, and cannot support, the presence of that m= line in bundle_y. Dale From wwwrun@rfc-editor.org Tue May 14 20:56:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8DC21F8AF4 for ; Tue, 14 May 2013 20:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.211 X-Spam-Level: X-Spam-Status: No, score=-102.211 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icu7D0W0RNez for ; Tue, 14 May 2013 20:56:11 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1171521F8AE2 for ; Tue, 14 May 2013 20:56:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D8DE872E14E; Tue, 14 May 2013 20:56:04 -0700 (PDT) To: ingemar.s.johansson@ericsson.com, kyunghun.jung@samsung.com, rlb@ipv.sx, gonzalo.camarillo@ericsson.com, fandreas@cisco.com, ari.keranen@ericsson.com From: RFC Errata System Message-Id: <20130515035604.D8DE872E14E@rfc-editor.org> Date: Tue, 14 May 2013 20:56:04 -0700 (PDT) Cc: liangxwa@cisco.com, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] [Editorial Errata Reported] RFC6236 (3620) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 03:56:11 -0000 The following errata report has been submitted for RFC6236, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6236&eid=3620 -------------------------------------- Type: Editorial Reported by: Liangxing Wang Section: 4.2.4 Original Text ------------- send [x=400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] Corrected Text -------------- send [x=[400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] Notes ----- Mismatching [] in original text. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6236 (draft-ietf-mmusic-image-attributes-11) -------------------------------------- Title : Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) Publication Date : May 2011 Author(s) : I. Johansson, K. Jung Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From kyunghun.jung@samsung.com Tue May 14 22:14:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA74121F8E56 for ; Tue, 14 May 2013 22:14:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgohBDb8SZ6P for ; Tue, 14 May 2013 22:13:55 -0700 (PDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by ietfa.amsl.com (Postfix) with ESMTP id 843D221F8A53 for ; Tue, 14 May 2013 22:13:55 -0700 (PDT) Received: from epcpsbgr5.samsung.com (u145.gpu120.samsung.co.kr [203.254.230.145]) by mailout1.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MMT00AX7QIEQWL0@mailout1.samsung.com> for mmusic@ietf.org; Wed, 15 May 2013 14:13:50 +0900 (KST) Received: from epcpsbgx2.samsung.com ( [172.20.52.114]) by epcpsbgr5.samsung.com (EPCPMTA) with SMTP id 52.B5.11618.E8913915; Wed, 15 May 2013 14:13:50 +0900 (KST) X-AuditID: cbfee691-b7fef6d000002d62-f8-5193198e4960 Received: from epextmailer02 ( [203.254.219.152]) by epcpsbgx2.samsung.com (EPCPMTA) with SMTP id E3.74.15503.CC813915; Wed, 15 May 2013 14:10:36 +0900 (KST) Message-id: Date: Wed, 15 May 2013 05:10:36 +0000 (GMT) From: =?euc-kr?B?waSw5sjG?= To: RFC Errata System , "ingemar.s.johansson@ericsson.com" , "rlb@ipv.sx" , "gonzalo.camarillo@ericsson.com" , "fandreas@cisco.com" , "ari.keranen@ericsson.com" MIME-version: 1.0 X-MTR: 20130515045329820@kyunghun.jung Msgkey: 20130515045329820@kyunghun.jung X-EPLocale: ko_KR.euc-kr X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-EPTrCode: X-EPTrName: X-MLAttribute: X-RootMTR: 20130515045329820@kyunghun.jung X-ParentMTR: X-ArchiveUser: EV X-CPGSPASS: N MIME-version: 1.0 Content-type: text/html; charset=euc-kr Content-transfer-encoding: base64 X-Generator: Namo ActiveSquare 7 7.0.0.44 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGJsWRmVeSWpSXmKPExsWyRsSkSLdPcnKgQfdNI4upyx+zODB6LFny kymAMaqB0SaxKDkjsyxVITUvOT8lMy/dVik0xE3XQkkhI7+4xFYp2sjAWM/I1ETPyMRcz9Ig 1srIVEkhLzE31VapQheqV0mhKLkAqDa3shhoQE6qHlRcrzg1L8UhK78U5BS94sTc4tK8dL3k /FwlhbLEnFKgEUr6CVMZM17N38tasE6z4uCdiywNjAs0uhg5OYQENCQal01kBrElBEwkevdO Z4SwxSQu3FvP1sXIBVSzlFHi5rkOVpiiuR/XMkIk5jNKPL3Rzg6S4BWwkLhyfw7YJBYBVYlj u3eBTWIDivfcXARWIyxgLnHoxUKwqSICR5gkJm3dwAaSYBY4xyhx9VgMxEnKEq2TrrFCDBWU ODnzCQvEZjWJPWsXs0HE1SUeHlkGdZGExKzpF6BsXokZ7U+h6uUkpn1dA/WatMT5WRvgXlv8 /TFUnF/i2O0dTF2MHGC9T+4Hw4zZvfkLG4QtIDH1zEGoVm2Jc5MvQY3nk1iz8C2ULShx+lo3 M0zv/S1zmdCdzwzU2/rmIxOErSgxpfsh+wRGlVlIytDZMC2zkLQsYGRZxSiaWpBcUJyUXmSK HN2bGIHJ8PS/ZxN3MN4/YH2IcT8jMCImMkuJJucD02leSbyhsZmRhamJqbGRuaUZhcImphYW JkZUEVYS51VvsQ4UEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwDj9t9SdgnOFVr5Pr1zt6Zsr pX/lshaf/XUtt4nbexwdXAyktZe9W/Dhy8V9r39Kb/n8u5x5wvkfYTIqM+5PNrRQOnnUn/3b TkmReZYmFxQj/lT6B7z4dTq36ZaF1QyG2dzsW3ULd8RUf3b7rvU4o+3DIrOp0vFam9u4DRS7 s54wcf7vP6p06a8SS3FGoqEWc1FxIgAOObjh+QMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpik+LIzCtJLcpLzFFi42I5/e/2DN0zEpMDDR5uVreYuvwxiwOjx5Il P5kCGKPSbDJSE1NSixRS85LzUzLz0m2VvIPjneNNzQwMdQ0tLcyVFPISc1NtlVx8AnTdMnOA pioplCXmlAKFAhKLi5X07WyK8ktLUhUy8otLbJWiDc2N9IwM9EyN9AyNY60MDQyMTIFqEtIy Xs3fy1qwTrPi4J2LLA2MCzS6GDk5hAQ0JBqXTWQGsSUETCTmflzLCGGLSVy4t56ti5ELqGY+ o8TTG+3sIAkWAVWJY7t3gRWxCVhI9NxcBBYXFjCXOPRiIViDiMARJolJWzewgSSYBc4xSlw9 FgOxTVmiddI1VhCbV0BQ4uTMJywQ29Qk9qxdzAYRV5d4eGQZK0RcQmLW9AtQNq/EjPanUPVy EtO+roG6Wlri/KwNcFcv/v4YKs4vcez2DqYuRg6w3if3g2HG7N78hQ3CFpCYeuYgVKu2xLnJ l6DG80msWfgWyhaUOH2tmxmm9/6WuUzozmcG6m1985EJwlaUmNL9kB2iXlPi9eHHLBMY5WYh aUFnw7TPQtK+gJFlFaNoakFyQXFSeoWRXnFibnFpXrpecn7uJkZwinq2aAfjv/PWhxgFOBiV eHgLAicFCrEmlhVX5h5ilOBgVhLhNbwGFOJNSaysSi3Kjy8qzUktPsSYDIzBicxSosn5wPSZ VxJvaGxsYmZiamliYWBqTpqwkjjvs1brQCGB9MSS1OzU1ILUIpgtTBycUg2MXvfyOopuFhSb bw5MD5275o66cl7j0U17l7UkfgjdtDxIcva/06sizt8LyDPaVjYvw1szweWhocSz5uj3jLXn 75fnhNuvlj8mKnh583apiS/da8W2fLgd8NVqZe6NLa/P3LlRLOzFJc9weE2rm6jcZv01EpI9 TrMC9+fsPKbVK87kvMddeuYTJZbijERDLeai4kQAzK/7hJUDAAA= DLP-Filter: Pass X-CFilter-Loop: Reflected Cc: "liangxwa@cisco.com" , "mmusic@ietf.org" , =?euc-kr?Q?=C3=D6=C1=BE=BC=F6?= , =?euc-kr?Q?=C0=CC=C1=D6=C8=A3?= Subject: Re: [MMUSIC] [Editorial Errata Reported] RFC6236 (3620) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: kyunghun.jung@samsung.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 05:14:01 -0000 PEhUTUw+PEhFQUQ+PFRJVExFPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L1RJ VExFPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciIgaHR0cC1lcXVp dj1Db250ZW50LVR5cGU+DQo8U1RZTEUgaWQ9bXlzaW5nbGVfc3R5bGU+UCB7DQoJTUFSR0lOLVRP UDogNXB4OyBGT05ULUZBTUlMWTogsby4ssO8LCBhcmlhbDsgTUFSR0lOLUJPVFRPTTogNXB4OyBG T05ULVNJWkU6IDlwdA0KfQ0KVEQgew0KCU1BUkdJTi1UT1A6IDVweDsgRk9OVC1GQU1JTFk6ILG8 uLLDvCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NCkxJIHsN CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBNQVJHSU4tQk9U VE9NOiA1cHg7IEZPTlQtU0laRTogOXB0DQp9DQpCT0RZIHsNCglMSU5FLUhFSUdIVDogMS40OyBN QVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBGT05ULVNJWkU6IDlwdA0K fQ0KPC9TVFlMRT4NCg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVudD1BY3RpdmVTcXVhcmU+ PC9IRUFEPg0KPEJPRFk+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PUFjdGl2ZVNxdWFy ZT4NCjxQPkRlYXIgTXIuIExpYW5neGluZyBXYW5nIGFuZCBNTVVTSUMgZXhwZXJ0czo8L1A+DQo8 UD4mbmJzcDs8L1A+DQo8UD5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciBwb2ludGluZyBvdXQgdGhl IHVuZm9ydHVuYXRlIHR5cG8uPC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+V2UgY291bGQgbm90IGxv Y2F0ZSB0aGUgdHlwbyBhcyB3ZSBoYXZlIGJlZW4gZm9jdXNpbmcgYSBiYXNpYzwvUD4NCjxQPnVz YWdlIG9mIHRoaXMgU0RQIGF0dHJpYnV0ZSBvdXRsaW5lZCBpbiA0LjIuMSwgdG8gYmUgdXNlZCZu YnNwO2luPC9QPg0KPFA+Vm9pY2Ugb3ZlciBMVEUgKFZvTFRFKSBzZXJ2aWNlcyBzb29uLjwvUD4N CjxQPiZuYnNwOzwvUD4NCjxQPlRoZSB0ZXh0IGluIHNlY3Rpb24gNC4yLjQsIGkuZS4sIHRoZSBh YnNlbmNlIG9mIGEgbGVmdCBicmFja2V0LDwvUD4NCjxQPnNob3VsZCBiZSBjb3JyZWN0ZWQgYXMg c3VnZ2VzdGVkLjwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPjxMSUFOR1hXQUBDSVNDTy5DT00+VGhh bmsgeW91IGFnYWluIGZvciB0aGUgY29uc2lkZXJhdGlvbi48L1A+DQo8UD4mbmJzcDs8L1A+DQo8 UD5CZXN0IHJlZ2FyZHMsPC9QPg0KPFA+S3l1bmdodW4gSnVuZzwvUD4NCjxQPlNhbXN1bmcgRWxl Y3Ryb25pY3MgQ28uLCBMVGQuPC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+LS0tLS0tLSA8Qj5Pcmln aW5hbCBNZXNzYWdlPC9CPiAtLS0tLS0tPC9QPg0KPFA+PEI+U2VuZGVyPC9CPiA6IFJGQyBFcnJh dGEgU3lzdGVtJmx0O3JmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcmZ3Q7PC9QPg0KPFA+PEI+RGF0 ZTwvQj4gOiAyMDEzLTA1LTE1IDEyOjU2IChHTVQrMDk6MDApPC9QPg0KPFA+PEI+VGl0bGU8L0I+ IDogW0VkaXRvcmlhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzYyMzYgKDM2MjApPC9QPg0KPFA+Jm5i c3A7PC9QPlRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9y IFJGQzYyMzYsPEJSPiJOZWdvdGlhdGlvbiBvZiBHZW5lcmljIEltYWdlIEF0dHJpYnV0ZXMgaW4g dGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkiLjxCUj48QlI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+WW91IG1heSByZXZpZXcgdGhlIHJlcG9y dCBiZWxvdyBhbmQgYXQ6PEJSPmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJj aC5waHA/cmZjPTYyMzYmYW1wO2VpZD0zNjIwPEJSPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxCUj5UeXBlOiBFZGl0b3JpYWw8QlI+UmVwb3J0ZWQgYnk6IExpYW5n eGluZyBXYW5nIDxMSUFOR1hXQUBDSVNDTy5DT00+PEJSPjxCUj5TZWN0aW9uOiA0LjIuNDxCUj48 QlI+T3JpZ2luYWwgVGV4dDxCUj4tLS0tLS0tLS0tLS0tPEJSPnNlbmQgW3g9NDAwOjE2OjgwMF0s eT1bMzIwOjE2OjY0MF0sc2FyPVsxLjAtMS4zXSxwYXI9WzEuMi0xLjNdXSA8QlI+PEJSPkNvcnJl Y3RlZCBUZXh0PEJSPi0tLS0tLS0tLS0tLS0tPEJSPnNlbmQgW3g9WzQwMDoxNjo4MDBdLHk9WzMy MDoxNjo2NDBdLHNhcj1bMS4wLTEuM10scGFyPVsxLjItMS4zXV0gPEJSPjxCUj5Ob3RlczxCUj4t LS0tLTxCUj5NaXNtYXRjaGluZyBbXSBpbiBvcmlnaW5hbCB0ZXh0LjxCUj48QlI+SW5zdHJ1Y3Rp b25zOjxCUj4tLS0tLS0tLS0tLS0tPEJSPlRoaXMgZXJyYXRhIGlzIGN1cnJlbnRseSBwb3N0ZWQg YXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2U8QlI+dXNlICJSZXBseSBBbGwiIHRv IGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVyaWZpZWQgb3I8QlI+cmVqZWN0ZWQuIFdo ZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5IChJRVNHKTxCUj5j YW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5l Y2Vzc2FyeS4gPEJSPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxC Uj5SRkM2MjM2IChkcmFmdC1pZXRmLW1tdXNpYy1pbWFnZS1hdHRyaWJ1dGVzLTExKTxCUj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5UaXRsZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA6IE5lZ290aWF0aW9uIG9mIEdlbmVyaWMgSW1hZ2UgQXR0cmlidXRlcyBp biB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKTxCUj5QdWJsaWNhdGlvbiBE YXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBNYXkgMjAxMTxCUj5BdXRob3IocykmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBJ LiBKb2hhbnNzb24sIEsuIEp1bmc8QlI+Q2F0ZWdvcnkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IFBST1BPU0VE IFNUQU5EQVJEPEJSPlNvdXJjZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogTXVsdGlwYXJ0 eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJvbDxCUj5BcmVhJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBSZWFsLXRpbWUgQXBwbGljYXRpb25zIGFuZCBJbmZyYXN0cnVj dHVyZTxCUj5TdHJlYW0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IElFVEY8QlI+VmVyaWZ5 aW5nIFBhcnR5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSUVTRzxCUj4NCjxQPiZuYnNwOzwv UD48L0JPRFk+PC9IVE1MPjxpbWcgc3JjPSdodHRwOi8vZXh0LnNhbXN1bmcubmV0L21haWxjaGVj ay9TZWVuVGltZUNoZWNrZXI/ZG89ZDYwNjVlOGQ1NGMxOTg5Y2ZlZTI1ZmEwYjliMjk0MDFiYTMx NmE4OWI4MjRkYjllYWJhODllYWVmNjAzYzgxODc4ZDdjNTBhZTk3NzNiNTUyYTVhNmI3ZDQyNmQw MWUzMWIyMDkwOWEwNGVmZDRkMjc0OGNmZTFkNGU4NDc0MTljZjg3OGY5YTI2Y2UxNWEwJyBib3Jk ZXI9MCB3aWR0aD0wIGhlaWdodD0wIHN0eWxlPSdkaXNwbGF5Om5vbmUnPg== From liangxwa@cisco.com Tue May 14 23:36:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9439321F8ADF for ; Tue, 14 May 2013 23:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKzqH55ZiHyO for ; Tue, 14 May 2013 23:36:37 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8379521F8696 for ; Tue, 14 May 2013 23:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13690; q=dns/txt; s=iport; t=1368599797; x=1369809397; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RErGay3GWaysaYht8eOgoxMWqMQGbGEbuliPUY0QFds=; b=FLbhHaztDY7w1UezcIof8fznZxyQ1tLKckps+ZjR1FIke6MnbIrlTNeP tCkE3lpSyGVuVKetnPSLr4JY8eXK+38F6FjAE/OuW+x9RWBGSlI4n0jw6 FtKHvJn8ApBN57ScU04OxikK+EnKaLaskfnWYI4j+PTvaXt7MUwyy8FcX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAHUsk1GtJXHA/2dsb2JhbABAGoJDRDfAPw1xFnSCHwEBAQQtPg4MBAIBBgIRBAEBCx0HAjAUCQgCBAENBQiIBAwzj12sZ45tFhsGAQaCbmEDqHGDD3qBLQ X-IronPort-AV: E=Sophos;i="4.87,675,1363132800"; d="scan'208,217";a="210628846" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 15 May 2013 06:36:37 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4F6aauI021181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 06:36:36 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.229]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 15 May 2013 01:36:36 -0500 From: "Liangxing Wang (liangxwa)" To: "kyunghun.jung@samsung.com" , RFC Errata System , "ingemar.s.johansson@ericsson.com" , "rlb@ipv.sx" , "gonzalo.camarillo@ericsson.com" , "Flemming Andreasen (fandreas)" , "ari.keranen@ericsson.com" Thread-Topic: [Editorial Errata Reported] RFC6236 (3620) Thread-Index: AQHOUSqIfUCGKMLPO0CxoPQl//uMRpkFxnNA Date: Wed, 15 May 2013 06:36:35 +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: [72.163.254.91] Content-Type: multipart/alternative; boundary="_000_B91B8E5C6DA89643BAC13EA69C7ABA8A1A9AB8xmbalnx07ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 15 May 2013 01:05:13 -0700 Cc: "mmusic@ietf.org" , =?ks_c_5601-1987?B?w9bBvrz2?= , =?ks_c_5601-1987?B?wMzB1sij?= Subject: Re: [MMUSIC] [Editorial Errata Reported] RFC6236 (3620) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 06:39:14 -0000 --_000_B91B8E5C6DA89643BAC13EA69C7ABA8A1A9AB8xmbalnx07ciscocom_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBLeXVuZ2h1biwNCg0KDQpUaGFua3MgZm9yIHlvdXIgcHJvbXB0IHJlc3BvbnNlLg0KDQpS ZWdhcmRzLA0KTGlhbmd4aW5nDQpDaXNjbyBTeXN0ZW1zLCBJbmMuDQpGcm9tOiDBpLDmyMYgW21h aWx0bzpreXVuZ2h1bi5qdW5nQHNhbXN1bmcuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMTUs IDIwMTMgMToxMSBQTQ0KVG86IFJGQyBFcnJhdGEgU3lzdGVtOyBpbmdlbWFyLnMuam9oYW5zc29u QGVyaWNzc29uLmNvbTsgcmxiQGlwdi5zeDsgZ29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29t OyBGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKTsgYXJpLmtlcmFuZW5AZXJpY3Nzb24uY29t DQpDYzogTGlhbmd4aW5nIFdhbmcgKGxpYW5neHdhKTsgbW11c2ljQGlldGYub3JnOyDD1sG+vPY7 IMDMwdbIow0KU3ViamVjdDogUmU6IFtFZGl0b3JpYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2MjM2 ICgzNjIwKQ0KDQpEZWFyIE1yLiBMaWFuZ3hpbmcgV2FuZyBhbmQgTU1VU0lDIGV4cGVydHM6DQoN ClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHBvaW50aW5nIG91dCB0aGUgdW5mb3J0dW5hdGUgdHlw by4NCg0KV2UgY291bGQgbm90IGxvY2F0ZSB0aGUgdHlwbyBhcyB3ZSBoYXZlIGJlZW4gZm9jdXNp bmcgYSBiYXNpYw0KdXNhZ2Ugb2YgdGhpcyBTRFAgYXR0cmlidXRlIG91dGxpbmVkIGluIDQuMi4x LCB0byBiZSB1c2VkIGluDQpWb2ljZSBvdmVyIExURSAoVm9MVEUpIHNlcnZpY2VzIHNvb24uDQoN ClRoZSB0ZXh0IGluIHNlY3Rpb24gNC4yLjQsIGkuZS4sIHRoZSBhYnNlbmNlIG9mIGEgbGVmdCBi cmFja2V0LA0Kc2hvdWxkIGJlIGNvcnJlY3RlZCBhcyBzdWdnZXN0ZWQuDQoNClRoYW5rIHlvdSBh Z2FpbiBmb3IgdGhlIGNvbnNpZGVyYXRpb24uDQoNCkJlc3QgcmVnYXJkcywNCkt5dW5naHVuIEp1 bmcNClNhbXN1bmcgRWxlY3Ryb25pY3MgQ28uLCBMVGQuDQoNCi0tLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLS0tDQpTZW5kZXIgOiBSRkMgRXJyYXRhIFN5c3RlbTxyZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPj4NCkRhdGUgOiAyMDEz LTA1LTE1IDEyOjU2IChHTVQrMDk6MDApDQpUaXRsZSA6IFtFZGl0b3JpYWwgRXJyYXRhIFJlcG9y dGVkXSBSRkM2MjM2ICgzNjIwKQ0KDQpUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJl ZW4gc3VibWl0dGVkIGZvciBSRkM2MjM2LA0KIk5lZ290aWF0aW9uIG9mIEdlbmVyaWMgSW1hZ2Ug QXR0cmlidXRlcyBpbiB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSIuDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0 aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRh X3NlYXJjaC5waHA/cmZjPTYyMzYmZWlkPTM2MjANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClR5cGU6IEVkaXRvcmlhbA0KUmVwb3J0ZWQgYnk6IExpYW5neGluZyBX YW5nDQoNClNlY3Rpb246IDQuMi40DQoNCk9yaWdpbmFsIFRleHQNCi0tLS0tLS0tLS0tLS0NCnNl bmQgW3g9NDAwOjE2OjgwMF0seT1bMzIwOjE2OjY0MF0sc2FyPVsxLjAtMS4zXSxwYXI9WzEuMi0x LjNdXQ0KDQpDb3JyZWN0ZWQgVGV4dA0KLS0tLS0tLS0tLS0tLS0NCnNlbmQgW3g9WzQwMDoxNjo4 MDBdLHk9WzMyMDoxNjo2NDBdLHNhcj1bMS4wLTEuM10scGFyPVsxLjItMS4zXV0NCg0KTm90ZXMN Ci0tLS0tDQpNaXNtYXRjaGluZyBbXSBpbiBvcmlnaW5hbCB0ZXh0Lg0KDQpJbnN0cnVjdGlvbnM6 DQotLS0tLS0tLS0tLS0tDQpUaGlzIGVycmF0YSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBv cnRlZCIuIElmIG5lY2Vzc2FyeSwgcGxlYXNlDQp1c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3 aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lv biBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5IChJRVNHKQ0KY2FuIGxvZyBpbiB0byBj aGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSRkM2MjM2IChkcmFmdC1pZXRm LW1tdXNpYy1pbWFnZS1hdHRyaWJ1dGVzLTExKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClRpdGxlICAgICAgICAgICAgICAgOiBOZWdvdGlhdGlvbiBvZiBHZW5lcmlj IEltYWdlIEF0dHJpYnV0ZXMgaW4gdGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNE UCkNClB1YmxpY2F0aW9uIERhdGUgICAgOiBNYXkgMjAxMQ0KQXV0aG9yKHMpICAgICAgICAgICA6 IEkuIEpvaGFuc3NvbiwgSy4gSnVuZw0KQ2F0ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNU QU5EQVJEDQpTb3VyY2UgICAgICAgICAgICAgIDogTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Np b24gQ29udHJvbA0KQXJlYSAgICAgICAgICAgICAgICA6IFJlYWwtdGltZSBBcHBsaWNhdGlvbnMg YW5kIEluZnJhc3RydWN0dXJlDQpTdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KVmVyaWZ5aW5n IFBhcnR5ICAgICA6IElFU0cNCg0KW2h0dHA6Ly9leHQuc2Ftc3VuZy5uZXQvbWFpbGNoZWNrL1Nl ZW5UaW1lQ2hlY2tlcj9kbz1kNjA2NWU4ZDU0YzE5ODljZmVlMjVmYTBiOWIyOTQwMWJhMzE2YTg5 YjgyNGRiOWVhYmE4OWVhZWY2MDNjODE4ODZkNjZmZjZkYjJhZmI5ZWZkOWY5MTI0ZDg4ZTJhYzY1 Mjk2OTcwMjUzMzMyYjM3MDc4MDU0NDdhMTU0YTQ2ZmNmODc4ZjlhMjZjZTE1YTBdDQoNCg== --_000_B91B8E5C6DA89643BAC13EA69C7ABA8A1A9AB8xmbalnx07ciscocom_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
= Dear Kyunghun,
= &n= bsp;
Thanks for your prom= pt response.
 
Regards,
Liangxing
Cisco Systems, Inc.
Fr= om: =C1=A4=B0=E6=C8=C6 [mailto:kyunghun.jung@samsung.com]
Sent: Wednesday, May 15, 2013 1:11 PM
To: RFC Errata System; ingemar.s.johansson@ericsson.com; rlb@ipv.sx;= gonzalo.camarillo@ericsson.com; Flemming Andreasen (fandreas); ari.keranen= @ericsson.com
Cc: Liangxing Wang (liangxwa); mmusic@ietf.org; =C3=D6=C1=BE=BC=F6; =C0=CC=C1=D6=C8=A3
Subject: Re: [Editorial Errata Reported] RFC6236 (3620)
 
Dear Mr. Liangxing Wang and M= MUSIC experts:
 <= /div>
Thank you very much for point= ing out the unfortunate typo.
 <= /div>
We could not locate the typo = as we have been focusing a basic
usage of this SDP attribute o= utlined in 4.2.1, to be used in=
Voice over LTE (VoLTE) servic= es soon.
 <= /div>
The text in section 4.2.4, i.= e., the absence of a left bracket,
should be corrected as sugges= ted.
 <= /div>
Thank you again for the consi= deration.
 <= /div>
Best regards,
Kyunghun Jung
Samsung Electronics Co., LTd.=
 <= /div>
------- Original Message -------
Sender : RFC Errata Sy= stem<<= u>rfc-editor@rfc-editor.org>
Date : 2013-05-15 12:5= 6 (GMT+09:00)
Title : [Editorial Err= ata Reported] RFC6236 (3620)
 <= /div>
The = following errata report has been submitted for RFC6236,
"Negotiation of Generic Image Attributes in the Session Description Pr= otocol (SDP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.ph= p?rfc=3D6236&eid=3D3620

--------------------------------------
Type: Editorial
Reported by: Liangxing Wang

Section: 4.2.4

Original Text
-------------
send [x=3D400:16:800],y=3D[320:16:640],sar=3D[1.0-1.3],par=3D[1.2-1.3]]
Corrected Text
--------------
send [x=3D[400:16:800],y=3D[320:16:640],sar=3D[1.0-1.3],par=3D[1.2-1.3]]
Notes
-----
Mismatching [] in original text.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit th= e report, if necessary.

--------------------------------------
RFC6236 (draft-ietf-mmusic-image-attributes-11)
--------------------------------------
Title           &nbs= p;   : Negotiation of Generic Image Attributes in the Session Des= cription Protocol (SDP)
Publication Date    : May 2011
Author(s)           : I. = Johansson, K. Jung
Category           &= nbsp;: PROPOSED STANDARD
Source           &nb= sp;  : Multiparty Multimedia Session Control
Area            = ;    : Real-time Applications and Infrastructure
Stream           &nb= sp;  : IETF
Verifying Party     : IESG
 <= /div>
 
 --_000_B91B8E5C6DA89643BAC13EA69C7ABA8A1A9AB8xmbalnx07ciscocom_-- From csp@csperkins.org Wed May 15 04:03:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9F421F8FA5 for ; Wed, 15 May 2013 04:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, MANGLED_FORM=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpQ2ceDILFRg for ; Wed, 15 May 2013 04:03:02 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC7D21F856D for ; Wed, 15 May 2013 04:03:02 -0700 (PDT) Received: from [130.209.247.112] (port=65535 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UcZU4-00074F-M0; Wed, 15 May 2013 12:03:01 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Wed, 15 May 2013 12:02:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2BB39401-29DC-4648-BB7F-51F0FE934082@csperkins.org> References: To: Martin Thomson X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 11:03:07 -0000 On 13 May 2013, at 19:42, Martin Thomson wrote: > We've had a great deal of discussion about plan A and B and the > various interactions of these proposals with bundling. But I still > don't get a good sense that there is a working consensus on what an > m-line actually represents. >=20 > I think that we've each reached our own conclusions, but they > definitely are not consistent. We need a well-understood semantic for > m-lines if we have any chance of resolving these issues; Plan A/B > being only the first RTCWEB problem to address. >=20 > RFC 4566 is helpfully devoid of detail, so we are free to come up with > any interpretation we choose. Here are the ones that I have seen: >=20 > 1. an m-line represents a single RTP session > (or at least the part of the session that touches the client) > This appears to be consistent with the Plan B approach This is closest to my understanding, although an RTP session is defined = by a shared SSRC space that can span multiple transport connections, so = I don't think it's quite right. Perhaps "an m-line refers to one = transport endpoint of a single RTP session"?=20 (For example, in a simple two-party voice-only call with RTCP there are = distinct m-lines, with different transport endpoints, in the offer and = the answer. But, since there is a shared SSRC space across the sending = and receiving RTP flows - which there has to be for RTCP to work - you = have one RTP session.) > 2. an m-line represents the set of RTP streams that decode into a > single rendering, including layers, simulcast and FEC >=20 > 3. an m-line represents a single RTP stream; multiple m-lines might > be required to obtain a single rendering if it uses layers, simulcast, > FEC or FID groupings > This appears to be consistent with the Plan A approach >=20 > In the first instance, an m-line can be multiple "things". In the > latter two cases, an m-line is consistently one "thing" (or part > thereof). >=20 > The first interpretation has a natural advantage in terms of signaling > economy and natural bundling. The latter interpretations seem to have > advantages in dealing with call transfer and SSRC renumbering. >=20 > So, which is correct? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From kevindempsey70@gmail.com Wed May 15 06:36:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F0121F8CE9 for ; Wed, 15 May 2013 06:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuORYqfqswYN for ; Wed, 15 May 2013 06:36:15 -0700 (PDT) Received: from mail-lb0-f195.google.com (mail-lb0-f195.google.com [209.85.217.195]) by ietfa.amsl.com (Postfix) with ESMTP id D50F721F89FB for ; Wed, 15 May 2013 06:36:14 -0700 (PDT) Received: by mail-lb0-f195.google.com with SMTP id 13so440147lba.6 for ; Wed, 15 May 2013 06:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=G/RZZlKdKrdmXqIGIxDCyYWZKnly2X4fUvD4sihjf3w=; b=Y/kq8d90YAuPInE2LSRsInC172rucddkcGpec3HzdwEDnfxCMRJmxOalRk1G5+xat4 TaIEw1Ijy4p2CPMlI9jzbO7IrDWr4KWjopqQyePUk0ELrrGtzpIxcCft1XmGJHbOvZb6 LXyrBXMCxaYcN/Q8EYYoz/OAmdYzxyyW2kgjISonD+Pt3w8y0nXY96cYhhw7k1hsQ8Jt m0vhcop6bdtSVfHrqSGWNkwN/vDVWiJDrHv7ZQztqA1KNlGu9GrV9Iy4VjKYc6TXg3d0 sRuPLSsP6vb8ll+P6pdt/1Vun9s2YN04H3oEn7o3IjIr6kKV4+KX/BmuBHDIg4pbuANh DEgg== MIME-Version: 1.0 X-Received: by 10.112.200.104 with SMTP id jr8mr17257370lbc.5.1368624973594; Wed, 15 May 2013 06:36:13 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Wed, 15 May 2013 06:36:13 -0700 (PDT) Date: Wed, 15 May 2013 14:36:13 +0100 Message-ID: From: Kevin Dempsey To: jonathan@vidyo.com, mmusic@ietf.org Content-Type: multipart/alternative; boundary=001a11c36d1261c6b204dcc1d54a X-Mailman-Approved-At: Wed, 15 May 2013 06:44:53 -0700 Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 13:37:25 -0000 --001a11c36d1261c6b204dcc1d54a Content-Type: text/plain; charset=ISO-8859-1 I hadn't seen the MMT idea before, but I like it. It does seem a bit awkward to use though. Perhaps with a few adjustments an offer could be: v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 m=anymedia 30000 UDP 1 a=rtcp-mux a=candidate:1 1 UDP 1694498815 host.atlanta.com 30000 typ host a=candidate:1 2 UDP 1694498815 host.atlanta.com 30000 typ host a=media:audio 1 RTP/AVP 0 8 97 b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=media:video 2 RTP/AVP 31 32 b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=audio 10000 RTP/AVP 0 8 97 a=anymedia-equivalent:1 1 a=rtcp-mux b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host a=candidate:1 2 UDP 1694498815 host.atlanta.com 10000 typ host m=video 20000 RTP/AVP 31 32 a=anymedia-equivalent:1 2 a=rtcp-mux b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:1 1 UDP 1694498815 host.atlanta.com 20000 typ host a=candidate:1 2 UDP 1694498815 host.atlanta.com 20000 typ host where the 'PT' on the m=anymedia line and the 'port' on the a=media: lines are identifiers for the a=anymedia-equivalent attributes. The a=media: line identifiers would need to be non-zero in the offer, but could be zero in the answer to reject that component. In this case the answer with anymedia support the reply would be something like: v=0 o=bob 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 m=anymedia 60000 UDP 1 a=rtcp-mux a=media:audio 1 RTP/AVP 0 8 97 b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=media:video 2 RTP/AVP 31 32 b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:1 1 UDP 1694498815 host.atlanta.com 60000 typ host a=candidate:1 2 UDP 1694498815 host.atlanta.com 60000 typ host m=audio 0 RTP/AVP 0 8 97 m=video 0 RTP/AVP 31 32 and without anymedia support the reply would be something like: v=0 o=bob 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 m=anymedia 0 UDP 1 m=audio 40000 RTP/AVP 0 8 97 a=rtcp-mux b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:1 1 UDP 1694498815 host.atlanta.com 40000 typ host a=candidate:1 2 UDP 1694498815 host.atlanta.com 40000 typ host m=video 50000 RTP/AVP 31 32 a=rtcp-mux b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:1 1 UDP 1694498815 host.atlanta.com 50000 typ host a=candidate:1 2 UDP 1694498815 host.atlanta.com 50000 typ host --001a11c36d1261c6b204dcc1d54a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I hadn't seen the MMT idea before, but I like it. It d= oes seem a bit awkward to use though.=A0

Perhaps w= ith a few adjustments an offer could be:

v=3D0
o=3Dalice 2890844526 2890844526 IN IP4 = host.atlanta.com
s=3D
c=3DIN IP4 host.atlanta.com
t=3D0 0
m=3Danym= edia 30000 UDP 1
a=3Drtcp-mux
a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 30000 typ host
a=3Dcan= didate:1 2 UDP 1694498815 host.atlanta.= com 30000 typ host
a=3Dmedia:audio 1 RTP/AVP 0 8 97
b=3DAS:200
a=3Drt= pmap:0 PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:97 i= LBC/8000
a=3Dmedia:video 2 RTP/AVP 31 32
b=3DAS:1000
a=3Drtpmap:31 H261/90000
a=3Drtpmap:32 MPV/90000
m=3Daudio 10000 RTP/AVP 0 8 97
=
a=3Danymedia-equivalent:1 1
a=3Drtcp-mux
b=3DAS:20= 0
a=3Drtpmap:0 PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:97 iLBC/8000
a=3Dcandidate:1 1 UDP 1694498815 h= ost.atlanta.com 10000 typ host
a=3Dcandidate:1 2 UDP 16944988= 15 host.atlanta.com 10000 typ host<= /div>
m=3Dvideo 20000 RTP/AVP 31 32
a=3Danymedia-equivalent:1 2
a=3Drtcp-mux
b=3DAS:1000
a=3Drtpmap:31 H261/900= 00
a=3Drtpmap:32 MPV/90000
a=3Dcandidate:1 1 UDP 169449= 8815 host.atlanta.com 20000 typ hos= t
a=3Dcandidate:1 2 UDP 1694498815 h= ost.atlanta.com 20000 typ host

where the= 'PT' on the m=3Danymedia line and the 'port' on the a=3Dme= dia: lines are =A0identifiers for the a=3Danymedia-equivalent attributes. T= he a=3Dmedia: line identifiers would need to be non-zero in the offer, but = could be zero in the answer to reject that component.

In this case the answer with anymedia suppo= rt the reply would be something like:

v=3D0
<= div>o=3Dbob 2890844526 2890844526 IN IP4 host.atlanta.com
s=3D
t=3D0 0
m=3Danymedia 60000 UDP 1
a=3Drtcp-mux
a=3Dmedia:audio 1 RTP/AVP 0 8 97
b=3DAS:2= 00
a=3Drtpmap:0 PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpma= p:97 iLBC/8000
a=3Dmedia:video 2 RTP/AVP 31 32
b=3DAS:1= 000
a=3Drtpmap:31 H261/90000
a=3Drtpmap:32 MPV/90000
a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 60000 typ host
a=3Dcandidate:1 2 UDP 1694498815 h= ost.atlanta.com 60000 typ host
m=3Daudio 0 RTP/AVP 0 8 97
m=3Dvideo 0 RTP/AVP 31 32


an= d without anymedia support the reply would be something like:

v=3D0
o=3Dbob 2890844526 2890844526 IN = IP4 host.atlanta.com
s=3D=
t=3D0 0
m=3Danymedia 0 UDP 1
m=3Daudio 40000 RTP/A= VP 0 8 97
a=3Drtcp-mux
b=3DAS:200
a=3Drtpmap:= 0 PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:97 iLBC/8= 000
a=3Dcandidate:1 2 UDP 1694498815 host.atlanta.com 40000 typ host
=
m=3Dvideo 50000 RTP/AVP 31 32
a=3Drtcp-mux
b=3DAS:1000<= /div>
a=3Drtpmap:31 H261/90000
a=3Drtpmap:32 MPV/90000
<= div>a=3Dcandidate:1 1 UDP 1694498815 ho= st.atlanta.com 50000 typ host
a=3Dcandidate:1 2 UDP 1694498815 h= ost.atlanta.com 50000 typ host

--001a11c36d1261c6b204dcc1d54a-- From pkyzivat@alum.mit.edu Wed May 15 08:50:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D465B11E80D7 for ; Wed, 15 May 2013 08:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUc1qKHzoc3d for ; Wed, 15 May 2013 08:50:49 -0700 (PDT) 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 AF58721F8A53 for ; Wed, 15 May 2013 08:50:35 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta07.westchester.pa.mail.comcast.net with comcast id cFmU1l00316LCl057Fqb9K; Wed, 15 May 2013 15:50:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id cFqa1l00X3ZTu2S3SFqabu; Wed, 15 May 2013 15:50:35 +0000 Message-ID: <5193AEC9.7040705@alum.mit.edu> Date: Wed, 15 May 2013 11:50:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Dale R. Worley" References: <7594FB04B1934943A5C02806D1A2204B1C36F22F@ESESSMB209.ericsson.se> <519103E1.8030200@alum.mit.edu> <201305132353.r4DNrTrr4646686@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C3700A9@ESESSMB209.ericsson.se> <201305142036.r4EKaope4759734@shell01.TheWorld.com> In-Reply-To: <201305142036.r4EKaope4759734@shell01.TheWorld.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=1368633035; bh=Ska5ZvcD8kfuo7v/b54C3GC2IsIfSN45zxKmCmQc3ng=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HVHahOX+7vYzTJ47cJ6KXE+JjEr7JTLPm5CIEGzNgrAuFpAMxpINF359DiJmnpiO9 ipc6LbWNwzDlrfm8Jfc5PIrtFLmpaxD5See03CUqqFSoXOAhisSQtuYhOQusUvcvIB erXHH5Z/HbkXMMed8zcuLQ/OLlkrnS+N9wrjpJ1splp1Xb1g02gc7cQC7MxsTblrbM x5GmQHtPR0CrcTCWAZYNgZSt5dvMrhzvTrmXwUWgVCgeZyhXMxf7SKpkRdSHRo2d+B R+TDZdg7SYS7Kevur/dTK3k/TQ9bb/Rms2PngEJDZahY0okD0Wn8oSKQgEd2XVTg9M +zwalgoXBv4UQ== Cc: mmusic@ietf.org, Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: Splitting a BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:50:55 -0000 On 5/14/13 4:36 PM, Dale R. Worley wrote: >> From: Christer Holmberg >> >> Note that there are two cases: >> >> 1) A new bundle is created in the answer >> >> 2) An m- line is moved from bundle_x in the offer to bundle_y in the >> answer. bundle_y was also present in the offer, so it is not created >> by the answerer. >> >> In my opinion 2) should not be allowed either, as the m- line was >> not present in bundle_y in the offer. > > Ugh, yes. Especially since the offerer probably does not want, and > cannot support, the presence of that m= line in bundle_y. +1 From pkyzivat@alum.mit.edu Wed May 15 09:03:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4BC21F8F69 for ; Wed, 15 May 2013 09:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.825 X-Spam-Level: X-Spam-Status: No, score=0.825 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MANGLED_FORM=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpQbcnw2CRPD for ; Wed, 15 May 2013 09:03:42 -0700 (PDT) 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 F1DFC11E80D2 for ; Wed, 15 May 2013 09:03:41 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id cAyf1l0051ap0As53G3hGY; Wed, 15 May 2013 16:03:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id cG3h1l00A3ZTu2S3iG3hNl; Wed, 15 May 2013 16:03:41 +0000 Message-ID: <5193B1DB.2070308@alum.mit.edu> Date: Wed, 15 May 2013 12:03:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: 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=1368633821; bh=0ZmsY/3VhYHx1RXA6ZShInZ/Rkdt1WNb+MG2vPyl2q0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kxhy8RQx6teZ3V3Ywjl+xEvz9aGNj25RHItXHfuFKCksk5n0XXUZrQrOAT0u1bVO2 AUEinokSUYocsPHJAcVtUQHDKclO3S9I9SXTg0QCgput356Ngbixa2NSdtyeUZyGUn Q79BAGAer3+M28T9iep5YGGWFyTU1kBdNxYuMNjnjMwmq0lEQQ0TjP5zOyZoyXHxcD SYfhi+EvxcExHdShqULf2qdSVRj5+UbCj1gMSEqg+tK5AM1Sj0lqyh+KOFpOzCL5Lx KbvjXZAaE2Qvqn2FNRX03SRVfL7/8zEomO+9p335N5m846g4jczOeFj5O0m4Jf5PCM M8pX5cUB+HmHA== Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 16:03:47 -0000 On 5/14/13 9:58 AM, Cullen Jennings (fluffy) wrote: > > People often want to look at this from the point of view of what they wish they can change SDP to mean, but unless we are doing SDPng, we need to look at it from the practical point of view of what has deployed and what SDP was defined as when that equipment deployed. We need to find a way that provided backwards interoperabiliyt while still allowing us to negotiate the things we want now. You can easily define an extension to SDP that means that RTP received on a single m line was meant to be rendered in differnt windows, but the fact of the matter remains that is not how lots of SIP equipment worked so you can't pretend SDP always meant that because it did not. ISTM that there are two questions here: - what is an m-line *without* bundle - what is an m-line *within* a bundle There are necessarily different, though of course our goal is to exploit some similarity between them. My earlier reply with an alternative (4) was intended as an answer to what an m-line *within* a bundle is. We clearly have different ideas of what a "legacy" m-line is. Colin expressed a preference for (1). I guess that is probably a good proxy for what the "real RTP people" intended for it to be. My impression is that Fluffy most likely thinks (3) is closer to right, based on what is deployed in the sip world. The situation where what is deployed is different than what was intended isn't a new one. But its a hard one to come to grips with. But what we most need to agree to is what a m-line will mean *within* a bundle. Thanks, Paul > > On May 13, 2013, at 12:42 PM, Martin Thomson wrote: > >> We've had a great deal of discussion about plan A and B and the >> various interactions of these proposals with bundling. But I still >> don't get a good sense that there is a working consensus on what an >> m-line actually represents. >> >> I think that we've each reached our own conclusions, but they >> definitely are not consistent. We need a well-understood semantic for >> m-lines if we have any chance of resolving these issues; Plan A/B >> being only the first RTCWEB problem to address. >> >> RFC 4566 is helpfully devoid of detail, so we are free to come up with >> any interpretation we choose. Here are the ones that I have seen: >> >> 1. an m-line represents a single RTP session >> (or at least the part of the session that touches the client) >> This appears to be consistent with the Plan B approach >> >> 2. an m-line represents the set of RTP streams that decode into a >> single rendering, including layers, simulcast and FEC >> >> 3. an m-line represents a single RTP stream; multiple m-lines might >> be required to obtain a single rendering if it uses layers, simulcast, >> FEC or FID groupings >> This appears to be consistent with the Plan A approach >> >> In the first instance, an m-line can be multiple "things". In the >> latter two cases, an m-line is consistently one "thing" (or part >> thereof). >> >> The first interpretation has a natural advantage in terms of signaling >> economy and natural bundling. The latter interpretations seem to have >> advantages in dealing with call transfer and SSRC renumbering. >> >> So, which is correct? >> _______________________________________________ >> 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 csp@csperkins.org Wed May 15 11:16:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DA721F8651 for ; Wed, 15 May 2013 11:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1IaiVT8uTaX for ; Wed, 15 May 2013 11:16:11 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 602AF21F85CE for ; Wed, 15 May 2013 11:16:11 -0700 (PDT) Received: from [81.187.2.149] (port=37174 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UcgFC-0002pf-0V; Wed, 15 May 2013 19:16:08 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <5193B1DB.2070308@alum.mit.edu> Date: Wed, 15 May 2013 19:16:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> References: <5193B1DB.2070308@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic@ietf.org Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 18:16:17 -0000 On 15 May 2013, at 17:03, Paul Kyzivat wrote: > On 5/14/13 9:58 AM, Cullen Jennings (fluffy) wrote: >>=20 >> People often want to look at this from the point of view of what they = wish they can change SDP to mean, but unless we are doing SDPng, we need = to look at it from the practical point of view of what has deployed and = what SDP was defined as when that equipment deployed. We need to find a = way that provided backwards interoperabiliyt while still allowing us to = negotiate the things we want now. You can easily define an extension to = SDP that means that RTP received on a single m line was meant to be = rendered in differnt windows, but the fact of the matter remains that is = not how lots of SIP equipment worked so you can't pretend SDP always = meant that because it did not. >=20 > ISTM that there are two questions here: >=20 > - what is an m-line *without* bundle >=20 > - what is an m-line *within* a bundle >=20 > There are necessarily different, though of course our goal is to = exploit some similarity between them. >=20 > My earlier reply with an alternative (4) was intended as an answer to = what an m-line *within* a bundle is. >=20 > We clearly have different ideas of what a "legacy" m-line is. > Colin expressed a preference for (1). I guess that is probably a good = proxy for what the "real RTP people" intended for it to be. My = impression is that Fluffy most likely thinks (3) is closer to right, = based on what is deployed in the sip world. It's not clear to me that the views are all *that* different, given the = assumption/constraints of the devices.=20 Colin > The situation where what is deployed is different than what was = intended isn't a new one. But its a hard one to come to grips with. >=20 > But what we most need to agree to is what a m-line will mean *within* = a bundle. >=20 > Thanks, > Paul >=20 >>=20 >> On May 13, 2013, at 12:42 PM, Martin Thomson = wrote: >>=20 >>> We've had a great deal of discussion about plan A and B and the >>> various interactions of these proposals with bundling. But I still >>> don't get a good sense that there is a working consensus on what an >>> m-line actually represents. >>>=20 >>> I think that we've each reached our own conclusions, but they >>> definitely are not consistent. We need a well-understood semantic = for >>> m-lines if we have any chance of resolving these issues; Plan A/B >>> being only the first RTCWEB problem to address. >>>=20 >>> RFC 4566 is helpfully devoid of detail, so we are free to come up = with >>> any interpretation we choose. Here are the ones that I have seen: >>>=20 >>> 1. an m-line represents a single RTP session >>> (or at least the part of the session that touches the client) >>> This appears to be consistent with the Plan B approach >>>=20 >>> 2. an m-line represents the set of RTP streams that decode into a >>> single rendering, including layers, simulcast and FEC >>>=20 >>> 3. an m-line represents a single RTP stream; multiple m-lines might >>> be required to obtain a single rendering if it uses layers, = simulcast, >>> FEC or FID groupings >>> This appears to be consistent with the Plan A approach >>>=20 >>> In the first instance, an m-line can be multiple "things". In the >>> latter two cases, an m-line is consistently one "thing" (or part >>> thereof). >>>=20 >>> The first interpretation has a natural advantage in terms of = signaling >>> economy and natural bundling. The latter interpretations seem to = have >>> advantages in dealing with call transfer and SSRC renumbering. >>>=20 >>> So, which is correct? >>> _______________________________________________ >>> 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 >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From bernard_aboba@hotmail.com Wed May 15 11:47:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CFA21F8ECB for ; Wed, 15 May 2013 11:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlvAwY0Y3-VA for ; Wed, 15 May 2013 11:47:02 -0700 (PDT) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by ietfa.amsl.com (Postfix) with ESMTP id 277C021F8F0C for ; Wed, 15 May 2013 11:47:02 -0700 (PDT) Received: from BLU169-W119 ([65.55.111.73]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 May 2013 11:47:00 -0700 X-TMN: [+PzcR7r5xHYFfZCUQLxPezL2ViR9VOppp6poyGCJZR8=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_f601f660-fe55-4728-b22f-25a7afcdf4cf_" From: Bernard Aboba To: Colin Perkins Date: Wed, 15 May 2013 11:47:00 -0700 Importance: Normal In-Reply-To: <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> References: , , <5193B1DB.2070308@alum.mit.edu>, <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> MIME-Version: 1.0 X-OriginalArrivalTime: 15 May 2013 18:47:00.0889 (UTC) FILETIME=[95B75090:01CE519C] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 18:47:08 -0000 --_f601f660-fe55-4728-b22f-25a7afcdf4cf_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Colin said:=20 "People often want to look at this from the point of view of what they wish= they can change SDP to mean=2C but unless we are doing SDPng=2C we need to= look at it from the practical point of view of what has deployed and what = SDP was defined as when that equipment deployed. We need to find a way that= provided backwards interoperability while still allowing us to negotiate t= he things we want now. You can easily define an extension to SDP that means= that RTP received on a single m line was meant to be rendered in different= windows=2C but the fact of the matter remains that is not how lots of SIP = equipment worked so you can't pretend SDP always meant that because it did = not." [BA] The reality is that "SIP equipment" covers an awful lot of ground. T= here are implementations that use a single m line for video and can handle = and render multiple SSRCs within that RTP session in different windows. E= mil has referred to one of those (Jitsi videobridge). There are also imple= mentations that use a single m line and support simulcast/layered coding=2C= rendering SSRC groups (e.g. groupings of simulcast and layered sources) in= different windows. Several implementations of H.264/SVC work this way.=20 So when people on the say "SIP equipment works this way" or "SDP works this= way" or even "RTP works this way" my BS meter goes off. Usually they mean= "the equipment I'm familiar with works this way". =20 I'm not sure we can make a definitive statement about what "backwards inter= operability" means with respect to video systems today=2C at least without = some work to survey existing implementations. And this somewhat complicate= s the "Plan A" vs. "Plan B" discussion in RTCWEB=2C because the reality is = that *neither* of these plans can achieve widespread "backwards interoperab= ility" with respect to SDP=2C if what you mean by that is "I can take the S= DP produced by a WebRTC implementation=2C throw it over the wire to an exis= ting implementation and expect anything good to happen".=20 IMHO=2C it is unrealistic to expect *any* implementation of the current Web= RTC API to deliver that. Until "comment 22" is resolved=2C SDP parsing/mun= ging is going to be an unpleasant=2C time consuming but necessary task for = interop with legacy equipment. So as they said in Dr. Strangelove=2C "stop= worrying and love the bomb".=20 What I *would* like is for the RTP/RTCP produced by WebRTC implementations = to not require a compute intensive media gateway/transcoder/munger to enabl= e media to be handled by existing systems=2C at least when the same video c= odecs are available (and no=2C that shouldn't necessarily mean "video codec= implementations based on the same source code"=2C because the spec should = be good enough to enable interoperability of independent implementations). = = --_f601f660-fe55-4728-b22f-25a7afcdf4cf_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Colin said: =3B

=
"People often want to = look at this from the point of view of what they wish they can change SDP t= o mean=2C but unless we are doing SDPng=2C we need to look at it from the p= ractical point of view of what has deployed and what SDP was defined as whe= n that equipment deployed. We need to find a way that provided backwards in= teroperability while still allowing us to negotiate the things we want now.= You can easily define an extension to SDP that means that RTP received on = a single m line was meant to be rendered in different windows=2C but the fa= ct of the matter remains that is not how lots of SIP equipment worked so yo= u can't pretend SDP always meant that because it did not."

[BA]  =3BThe reality is that "SIP equipment" covers an = awful lot of ground.  =3BThere are implementations that use a single m = line for video and can handle and render multiple SSRCs within that RTP ses= sion in different windows.  =3B Emil has referred to one of those (Jits= i videobridge).  =3BThere are also implementations that use a single m = line and support simulcast/layered coding=2C rendering =3BSSRC groups (e.g. groupings of simulcast and layere= d sources) in different windows.  =3B Several implementations of H.264/= SVC work this way. =3B

So when peopl= e on the say "SIP equipment works this way" or "SDP works this way" or even= "RTP works this way" my BS meter goes off.  =3BUsually they mean "the = equipment I'm familiar with works this way".  =3B =3B
<= div>
I'm not sure we can make a definitive statement about = what "backwards interoperability" means with respect to video systems today= =2C at least without some work to survey existing implementations.  =3B= And this somewhat complicates the "Plan A" vs. "Plan B" discussion in RTCWE= B=2C because the reality is that *neither* of these plans can achieve wides= pread "backwards interoperability" with respect to SDP=2C if what you mean = by that is "I can take the SDP produced by a WebRTC implementation=2C throw= it over the wire to an existing implementation and expect anything good to= happen". =3B

<= /span>
IMHO=2C it is unrealist= ic to expect *any* implementation of the current WebRTC API to deliver that= .  =3BUntil "comment 22" is resolved=2C SDP parsing/munging is going to= be an unpleasant=2C time consuming but necessary task for interop with leg= acy equipment.  =3BSo as they said in Dr. Strangelove=2C "stop worrying= and love the bomb". =3B

What I *woul= d* like is for the RTP/RTCP produced by WebRTC implementations to not requi= re a compute intensive media gateway/transcoder/munger to enable media to b= e handled by existing systems=2C at least when the same video codecs are av= ailable (and no=2C that shouldn't necessarily mean "video codec implementat= ions based on the same source code"=2C because the spec should be good enou= gh to enable interoperability of independent implementations).  =3B
= --_f601f660-fe55-4728-b22f-25a7afcdf4cf_-- From martin.thomson@gmail.com Wed May 15 11:53:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEC721F9080 for ; Wed, 15 May 2013 11:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+SZKI5eJpGA for ; Wed, 15 May 2013 11:53:37 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BB28021F9092 for ; Wed, 15 May 2013 11:53:34 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u54so2039347wes.1 for ; Wed, 15 May 2013 11:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=pwj+7Dy4jq7O9v6UXD5CZLU/QmW90c+59tVlYAjyMRE=; b=RO9hlblsHLcl/rQFz7ybBK0LIp0VOjwzk41mHQGqV28sOIsCSZWu1akTUTfh+TgpMa x3Vlj/KzdM4/eIEFNaHCWe6G9oUS3KyW4g7FCtQ2AK4Thly8QlU96jHm4O59E1M3V4os cRI+sTnwLrET4MziWf50AlfvWYUG9Rn8NFZyFja0nHVPCfOoYHEt+wFGT6Q4kWFB5seq 8UEQ43laH2/IzbvCerRfxkCL41iRpEOt9cFTgrnJmxTN2X2eWXwBPWuVHvxKmD9Oy8ac WfQcMSF65w/OoUa8o0T1n3TtsjdKoAxz0bVD0Uc0TMskQWI1cFwjrY2Voe2vqXTrIhyl ZY+w== MIME-Version: 1.0 X-Received: by 10.180.20.148 with SMTP id n20mr16996523wie.8.1368644009999; Wed, 15 May 2013 11:53:29 -0700 (PDT) Received: by 10.194.20.135 with HTTP; Wed, 15 May 2013 11:53:29 -0700 (PDT) In-Reply-To: <2BB39401-29DC-4648-BB7F-51F0FE934082@csperkins.org> References: <2BB39401-29DC-4648-BB7F-51F0FE934082@csperkins.org> Date: Wed, 15 May 2013 11:53:29 -0700 Message-ID: From: Martin Thomson To: Colin Perkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 18:53:38 -0000 On 15 May 2013 04:02, Colin Perkins wrote: >> 1. an m-line represents a single RTP session >> (or at least the part of the session that touches the client) >> This appears to be consistent with the Plan B approach > > This is closest to my understanding, although an RTP session is defined b= y a shared SSRC space that can span multiple transport connections, so I do= n't think it's quite right. Perhaps "an m-line refers to one transport endp= oint of a single RTP session"? That's why I said "at least the part of the session that touches the client", but this is probably more correct given that the same session can have multiple transport endpoints on the same endpoint, described in the same SDP as different m-lines. > (For example, in a simple two-party voice-only call with RTCP there are d= istinct m-lines, with different transport endpoints, in the offer and the a= nswer. But, since there is a shared SSRC space across the sending and recei= ving RTP flows - which there has to be for RTCP to work - you have one RTP = session.) This is a good point. In offer/answer, this can clearly be two things (as dictated by a=3Dsendrecv). I'd like to know how well this offer/answer usage scales. Does this extend to a three-party RTP session with the same characteristics? From csp@csperkins.org Wed May 15 11:59:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA49121F8F33 for ; Wed, 15 May 2013 11:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.448 X-Spam-Level: X-Spam-Status: No, score=-105.448 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCJCq-0QgAk0 for ; Wed, 15 May 2013 11:59:27 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 018C021F859D for ; Wed, 15 May 2013 11:59:27 -0700 (PDT) Received: from [81.187.2.149] (port=39185 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ucgv7-0004uv-Jh; Wed, 15 May 2013 19:59:26 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_6A0C4719-F4E9-416A-A672-B163C9B528DE" From: Colin Perkins In-Reply-To: Date: Wed, 15 May 2013 19:59:24 +0100 Message-Id: <6DBA4FC8-1ED0-4DEB-A6D2-5F7CE032BE8F@csperkins.org> References: , , <5193B1DB.2070308@alum.mit.edu>, <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> To: Bernard Aboba X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 18:59:32 -0000 --Apple-Mail=_6A0C4719-F4E9-416A-A672-B163C9B528DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 15 May 2013, at 19:47, Bernard Aboba wrote: > Colin said:=20 For the record, I think it was Cullen said this, although in a message I = quoted.=20 Colin > "People often want to look at this from the point of view of what they = wish they can change SDP to mean, but unless we are doing SDPng, we need = to look at it from the practical point of view of what has deployed and = what SDP was defined as when that equipment deployed. We need to find a = way that provided backwards interoperability while still allowing us to = negotiate the things we want now. You can easily define an extension to = SDP that means that RTP received on a single m line was meant to be = rendered in different windows, but the fact of the matter remains that = is not how lots of SIP equipment worked so you can't pretend SDP always = meant that because it did not." >=20 > [BA] The reality is that "SIP equipment" covers an awful lot of = ground. There are implementations that use a single m line for video = and can handle and render multiple SSRCs within that RTP session in = different windows. Emil has referred to one of those (Jitsi = videobridge). There are also implementations that use a single m line = and support simulcast/layered coding, rendering SSRC groups (e.g. = groupings of simulcast and layered sources) in different windows. = Several implementations of H.264/SVC work this way.=20 >=20 > So when people on the say "SIP equipment works this way" or "SDP works = this way" or even "RTP works this way" my BS meter goes off. Usually = they mean "the equipment I'm familiar with works this way". =20 >=20 > I'm not sure we can make a definitive statement about what "backwards = interoperability" means with respect to video systems today, at least = without some work to survey existing implementations. And this somewhat = complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, because the = reality is that *neither* of these plans can achieve widespread = "backwards interoperability" with respect to SDP, if what you mean by = that is "I can take the SDP produced by a WebRTC implementation, throw = it over the wire to an existing implementation and expect anything good = to happen".=20 >=20 > IMHO, it is unrealistic to expect *any* implementation of the current = WebRTC API to deliver that. Until "comment 22" is resolved, SDP = parsing/munging is going to be an unpleasant, time consuming but = necessary task for interop with legacy equipment. So as they said in = Dr. Strangelove, "stop worrying and love the bomb".=20 >=20 > What I *would* like is for the RTP/RTCP produced by WebRTC = implementations to not require a compute intensive media = gateway/transcoder/munger to enable media to be handled by existing = systems, at least when the same video codecs are available (and no, that = shouldn't necessarily mean "video codec implementations based on the = same source code", because the spec should be good enough to enable = interoperability of independent implementations). =20 --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_6A0C4719-F4E9-416A-A672-B163C9B528DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Colin = said: 

For = the record, I think it was Cullen said this, although in a message I = quoted. 

Colin


"People often = want to look at this from the point of view of what they wish they can = change SDP to mean, but unless we are doing SDPng, we need to look at it = from the practical point of view of what has deployed and what SDP was = defined as when that equipment deployed. We need to find a way that = provided backwards interoperability while still allowing us to negotiate = the things we want now. You can easily define an extension to SDP that = means that RTP received on a single m line was meant to be rendered in = different windows, but the fact of the matter remains that is not how = lots of SIP equipment worked so you can't pretend SDP always meant that = because it did not."

[BA]  The = reality is that "SIP equipment" covers an awful lot of ground. =  There are implementations that use a single m line for video and = can handle and render multiple SSRCs within that RTP session in = different windows.   Emil has referred to one of those (Jitsi = videobridge).  There are also implementations that use a single m = line and support simulcast/layered coding, rendering SSRC groups (e.g. groupings of simulcast and = layered sources) in different windows.   Several implementations of = H.264/SVC work this way. 

So when = people on the say "SIP equipment works this way" or "SDP works this way" = or even "RTP works this way" my BS meter goes off.  Usually they = mean "the equipment I'm familiar with works this way". =   
I'm not sure = we can make a definitive statement about what "backwards = interoperability" means with respect to video systems today, at least = without some work to survey existing implementations.  And this = somewhat complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, = because the reality is that *neither* of these plans can achieve = widespread "backwards interoperability" with respect to SDP, if what you = mean by that is "I can take the SDP produced by a WebRTC implementation, = throw it over the wire to an existing implementation and expect anything = good to happen". 
IMHO, it is = unrealistic to expect *any* implementation of the current WebRTC API to = deliver that.  Until "comment 22" is resolved, SDP parsing/munging = is going to be an unpleasant, time consuming but necessary task for = interop with legacy equipment.  So as they said in Dr. Strangelove, = "stop worrying and love the bomb". 

What I *would* like is for the RTP/RTCP = produced by WebRTC implementations to not require a compute intensive = media gateway/transcoder/munger to enable media to be handled by = existing systems, at least when the same video codecs are available (and = no, that shouldn't necessarily mean "video codec implementations based = on the same source code", because the spec should be good enough to = enable interoperability of independent implementations). =  



-- 
Colin Perkins



= --Apple-Mail=_6A0C4719-F4E9-416A-A672-B163C9B528DE-- From harald@alvestrand.no Wed May 15 13:04:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC4621F84DC for ; Wed, 15 May 2013 13:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pjEz9AIgZpa for ; Wed, 15 May 2013 13:04:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E0CF721F8233 for ; Wed, 15 May 2013 13:04:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 313FC39E199 for ; Wed, 15 May 2013 22:04:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9+9G2gDlyfW for ; Wed, 15 May 2013 22:04:45 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:c9:5f50:178a:75d] (unknown [IPv6:2001:470:de0a:27:c9:5f50:178a:75d]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 06DB539E116 for ; Wed, 15 May 2013 22:04:44 +0200 (CEST) Message-ID: <5193EA5C.7050905@alvestrand.no> Date: Wed, 15 May 2013 22:04:44 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: , , <5193B1DB.2070308@alum.mit.edu>, <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060604000007040700010308" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 20:04:54 -0000 This is a multi-part message in MIME format. --------------060604000007040700010308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/15/2013 08:47 PM, Bernard Aboba wrote: > > > So when people on the say "SIP equipment works this way" or "SDP works > this way" or even "RTP works this way" my BS meter goes off. Usually > they mean "the equipment I'm familiar with works this way". > > I'm not sure we can make a definitive statement about what "backwards > interoperability" means with respect to video systems today, at least > without some work to survey existing implementations. And this > somewhat complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, > because the reality is that *neither* of these plans can achieve > widespread "backwards interoperability" with respect to SDP, if what > you mean by that is "I can take the SDP produced by a WebRTC > implementation, throw it over the wire to an existing implementation > and expect anything good to happen". Bravo! > > IMHO, it is unrealistic to expect *any* implementation of the current > WebRTC API to deliver that. Until "comment 22" is resolved, SDP > parsing/munging is going to be an unpleasant, time consuming but > necessary task for interop with legacy equipment. So as they said in > Dr. Strangelove, "stop worrying and love the bomb". I take a somewhat different approach: If it's possible to *write an application* that uses the WebRTC interface, does not mangle the SDP, and sends that to an existing implementation (supporting SRTP and ICE), and has something useful happen, I think it's the success we can hope for. This may mean having the application use content settings to force tracks to different m-lines, keep low the number of tracks offered, and other tricks that make sense in the context of *that application*. It's the *application* that needs to interwork, it's not "WebRTC in general". WebRTC just needs to make it possible. I see the idea that *any application* should produce SDP that's useful in such a scenario as an illusion, and pursuing that illusion is just going to hurt us. > > What I *would* like is for the RTP/RTCP produced by WebRTC > implementations to not require a compute intensive media > gateway/transcoder/munger to enable media to be handled by existing > systems, at least when the same video codecs are available (and no, > that shouldn't necessarily mean "video codec implementations based on > the same source code", because the spec should be good enough to > enable interoperability of independent implementations). I find nothing to disagree with in this paragraph. --------------060604000007040700010308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/15/2013 08:47 PM, Bernard Aboba wrote:
<snip>

So when people on the say "SIP equipment works this way" or "SDP works this way" or even "RTP works this way" my BS meter goes off.  Usually they mean "the equipment I'm familiar with works this way".   

I'm not sure we can make a definitive statement about what "backwards interoperability" means with respect to video systems today, at least without some work to survey existing implementations.  And this somewhat complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, because the reality is that *neither* of these plans can achieve widespread "backwards interoperability" with respect to SDP, if what you mean by that is "I can take the SDP produced by a WebRTC implementation, throw it over the wire to an existing implementation and expect anything good to happen".

Bravo!



IMHO, it is unrealistic to expect *any* implementation of the current WebRTC API to deliver that.  Until "comment 22" is resolved, SDP parsing/munging is going to be an unpleasant, time consuming but necessary task for interop with legacy equipment.  So as they said in Dr. Strangelove, "stop worrying and love the bomb".

I take a somewhat different approach:
If it's possible to *write an application* that uses the WebRTC interface, does not mangle the SDP, and sends that to an existing implementation (supporting SRTP and ICE), and has something useful happen, I think it's the success we can hope for.

This may mean having the application use content settings to force tracks to different m-lines, keep low the number of tracks offered, and other tricks that make sense in the context of *that application*.
It's the *application* that needs to interwork, it's not "WebRTC in general". WebRTC just needs to make it possible.

I see the idea that *any application* should produce SDP that's useful in such a scenario as an illusion, and pursuing that illusion is just going to hurt us.



What I *would* like is for the RTP/RTCP produced by WebRTC implementations to not require a compute intensive media gateway/transcoder/munger to enable media to be handled by existing systems, at least when the same video codecs are available (and no, that shouldn't necessarily mean "video codec implementations based on the same source code", because the spec should be good enough to enable interoperability of independent implementations).

I find nothing to disagree with in this paragraph.

--------------060604000007040700010308-- From eckelcu@cisco.com Wed May 15 13:06:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884C421F872E for ; Wed, 15 May 2013 13:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwnW7yUC5je1 for ; Wed, 15 May 2013 13:05:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFA621F871D for ; Wed, 15 May 2013 13:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3634; q=dns/txt; s=iport; t=1368648355; x=1369857955; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G0VRIKnLn2LxKM3Dq7KGVExJGib9IGahU9irmoiy5tc=; b=P9dflqbV3n0filItAy9b0rkwMf8bI+mEczU6ghUtV749xr1yBVTX31ch P3ekGZa4gqjPS+dcciDeg45N8BAINA2bockJBCuhkG8ZmK7cxXGqEjqh/ 6r2oZYQuPRLsxnqemQIt6YeGJxOjVQ7luhRFOqnZQ5T1ZEhAQiI7HNezE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAFjqk1GtJXG//2dsb2JhbABbgwc3gzy9Gw1wFnSCHwEBAQQjEUUMBAIBCA4DBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIh3IDDgEMq1CIbw2IUYEmiyKCJRYbBwaCPDJhA5VPgw2KcoUjgxCCJw X-IronPort-AV: E=Sophos;i="4.87,679,1363132800"; d="scan'208";a="210930646" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 15 May 2013 20:05:54 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4FK5sDM007475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 20:05:54 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.28]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 15 May 2013 15:05:54 -0500 From: "Charles Eckel (eckelcu)" To: Justin Uberti , Martin Thomson , Eric Rescorla Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation Thread-Index: AQHORpl+ckZ1WP/E2EKwDjm+4RXvEJjxI3aAgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIAACOAAgADN64CAAMJ9gIAADKaAgBKmOJA= Date: Wed, 15 May 2013 20:05:53 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882804833FA6@xmb-aln-x08.cisco.com> References: <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Alan Johnston , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 20:06:01 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtbXVzaWMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgSnVz dGluIFViZXJ0aQ0KPiBTZW50OiBGcmlkYXksIE1heSAwMywgMjAxMyAxMToxNSBBTQ0KPiBUbzog TWFydGluIFRob21zb247IEVyaWMgUmVzY29ybGENCj4gQ2M6IFBhdWwgS3l6aXZhdDsgQWxhbiBK b2huc3RvbjsgbW11c2ljQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTU1VU0lDXSBEVExTLVNS VFAgY2xpZW50L3NlcnZlciByb2xlIG5lZ290aWF0aW9uDQo+IA0KPiANCj4gDQo+IA0KPiBPbiBG cmksIE1heSAzLCAyMDEzIGF0IDEwOjI5IEFNLCBNYXJ0aW4gVGhvbXNvbg0KPiA8bWFydGluLnRo b21zb25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IA0KPiAJT24gMiBNYXkgMjAxMyAyMjo1Mywg SnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPiB3cm90ZToNCj4gCT4gVGhpcyBpcyB3 aGVyZSB0aGUgT1AncyBxdWVzdGlvbiBjYW1lIGZyb20gLSB0aGUgZGlmZmVyaW5nIHBvbGljeQ0K PiBiZXR3ZWVuDQo+IAk+IENocm9tZSBhbmQgRmlyZWZveC4gSSAocmVnYXJkaW5nIENocm9tZSkg aGFkIGZpZ3VyZWQgdGhhdCBpZiBJQ0UgaGFkDQo+IG1hZGUgYQ0KPiAJPiBkZXRlcm1pbmF0aW9u IHJlZ2FyZGluZyB3aGljaCBzaWRlIHdhcyBpbiBjaGFyZ2UsIHRoZSBvdGhlciBsYXllcnMgaW4N Cj4gdGhlDQo+IAk+IHN0YWNrIHNob3VsZCBkbyB0aGUgc2FtZSwgYnV0IGl0IHNvdW5kcyBsaWtl IHRoZXJlIGFyZSBhbHJlYWR5DQo+IGVzdGFibGlzaGVkDQo+IAk+IHJ1bGVzIG9uIGhvdyB0byBk byB0aGlzLg0KPiAJPg0KPiAJPiBGcm9tIHRoaXMgdGhyZWFkLCBpdCBzb3VuZHMgbGlrZSB0aGUg cmVjb21tZW5kYXRpb24gaXMgdG8gdXNlDQo+IAk+IGE9c2V0dXA6YWN0cGFzcyBpbiB0aGUgb2Zm ZXIsIGFuZCB0aGVuIHRoZSBhbnN3ZXJlciBjYW4gdXNlDQo+IGE9c2V0dXA6YWN0aXZlDQo+IAk+ IHRvIGNob29zZSB0aGUgY2xpZW50IHJvbGUuIEluIDNwY2MgY2FzZXMsIHRoZSBCMkJVQSBjYW4g c2VsZWN0DQo+IGE9c2V0dXANCj4gCT4gYXBwcm9wcmlhdGVseSB0byBhdm9pZCBhbnkgaXNzdWUu DQo+IAk+DQo+IAk+IElzIHRoYXQgYW4gYWNjdXJhdGUgc3VtbWFyeSwgYW5kIGlzIHRoZXJlIGNv bnNlbnN1cyBvbiB0aGlzPw0KPiANCj4gDQo+IAlUaGUgYW5zd2VyIHNob3VsZCBwcm9iYWJseSBi ZSBhPXNldHVwOnBhc3NpdmUsIHNvIHRoYXQgeW91IGRvbid0IGhhdmUNCj4gCWFueSBkaXNjb25u ZWN0IG9uIHdoYXQgY2FuZGlkYXRlIHBhaXIgaXMgbm9taW5hdGVkLiAgQW5kIHlvdSBkb24ndA0K PiBwYXkNCj4gCWFuIGV4dHJhIGhhbGYtUlRULiAgQnV0IG90aGVyd2lzZSwgeWVzLg0KPiANCj4g DQo+IA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzYzIHJlY29tbWVuZHMgYT1z ZXR1cDphY3RpdmUgZm9yIHRoZQ0KPiBhbnN3ZXJlciwgYW5kIEVyaWMgY29udmluY2VkIG1lIHRo YXQgYW55IHBlcmYgYmVuZWZpdCBmcm9tIGRvaW5nIGFueXRoaW5nDQo+IGRpZmZlcmVudCB3YXMg bm9taW5hbC4NCj4gDQo+IElmIHRoZSBhbnN3ZXJlcidzIGluaXRpYWwgSUNFIGNoZWNrcyByZWFj aCB0aGUgb2ZmZXJlciwgdGhlIGNsaWVudCBoZWxsbyBjYW4gYmUNCj4gc2VudCBieSB0aGUgYW5z d2VyZXIgaW4gMS41IFJUVCwgb3IgdGhlIG9mZmVyZXIgaW4gMi4wIFJUVDoNCj4gMC4wOiBBOiBv ZmZlcg0KPiAwLjUgQjogYW5zd2VyDQo+IDAuNSBCOiBiaW5kaW5nIHJlcXVlc3QNCj4gMS4wIEE6 IGJpbmRpbmcgcmVzcG9uc2UNCj4gMS4wIEE6IHRyaWdnZXJlZCBiaW5kaW5nIHJlcXVlc3QgKFVT RS1DQU5ESURBVEUpDQo+IDEuNSBCOiBEVExTIGNsaWVudCBoZWxsbw0KPiANCj4gSWYgbm90LCB0 aGUgY2xpZW50IGhlbGxvIGlzIHNlbnQgYnkgdGhlIGFuc3dlcmVyIGluIDIuNSBSVFQsIG9yIHRo ZSBvZmZlcmVyIGluIDIuMA0KPiBSVFQ6DQo+IDAuMDogQTogb2ZmZXINCj4gMC41IEI6IGFuc3dl cg0KPiAwLjUgQjogYmluZGluZyByZXF1ZXN0IChkcm9wcGVkKQ0KPiAxLjAgQTogYmluZGluZyBy ZXF1ZXN0IChVU0UtQ0FORElEQVRFKQ0KPiAxLjUgQjogYmluZGluZyByZXNwb25zZQ0KPiAxLjUg QjogdHJpZ2dlcmVkIGJpbmRpbmcgcmVxdWVzdA0KPiAyLjAgQTogYmluZGluZyByZXNwb25zZQ0K PiAyLjUgQjogRFRMUyBjbGllbnQgaGVsbG8NCj4gDQo+IFNvIG92ZXJhbGwgaXQncyBhIGJpdCBv ZiBhIHdhc2gsIGFuZCB0aGVyZWZvcmUgc2ltcGxlciB0byBzdGljayB3aXRoIDU3NjMncw0KPiBy ZWNvbW1lbmRhdGlvbi4NCg0KU29ycnkgZm9yIHRoZSBkZWxheWVkIGNvbW1lbnQgb24gdGhpcyB0 aHJlYWQsIGJ1dCBJIHdhbnRlZCB0byBzdGF0ZSB0aGFuIEkgYWdyZWUuIEluIGFkZGl0aW9uLCB0 aGlzIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgcmVjb21tZW5kYXRpb25zIHByb3ZpZGVkIGJ5IHRo ZSBCRkNQQklTIFdHIHdoZW4gdXNpbmcgRFRMUyB3aXRoIEJGQ1Agb3ZlciBVRFA6DQpodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcy0wNyNzZWN0 aW9uLTkNCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQoNCg== From bernard_aboba@hotmail.com Wed May 15 15:44:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286A711E80BA for ; Wed, 15 May 2013 15:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78UT7dI1jsfu for ; Wed, 15 May 2013 15:43:59 -0700 (PDT) Received: from blu0-omc1-s23.blu0.hotmail.com (blu0-omc1-s23.blu0.hotmail.com [65.55.116.34]) by ietfa.amsl.com (Postfix) with ESMTP id 05F0921F8437 for ; Wed, 15 May 2013 15:43:52 -0700 (PDT) Received: from BLU169-W74 ([65.55.116.9]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 May 2013 15:43:51 -0700 X-TMN: [UV2y9OllaQA/eXhq0MXqSTBZG/O8+2BTeX3+3IRkx8w=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2f96a665-00b8-4027-95aa-7534604a700e_" From: Bernard Aboba To: Harald Alvestrand , "mmusic@ietf.org" Date: Wed, 15 May 2013 15:43:51 -0700 Importance: Normal In-Reply-To: <5193EA5C.7050905@alvestrand.no> References: , , , , <5193B1DB.2070308@alum.mit.edu>, , <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org>, , <5193EA5C.7050905@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 15 May 2013 22:43:51.0719 (UTC) FILETIME=[AC07E370:01CE51BD] Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 22:44:04 -0000 --_2f96a665-00b8-4027-95aa-7534604a700e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said:=20 =0A= =20 =0A= =0A= =20 =0A= "I take a somewhat different approach: =0A= If it's possible to *write an application* that uses the WebRTC=0A= interface=2C does not mangle the SDP=2C and sends that to an existing= =0A= implementation (supporting SRTP and ICE)=2C and has something useful=0A= happen=2C I think it's the success we can hope for." [BA] Since existin= g non-WebRTC audio applications typically have to do at least some SDP mang= ling=2C WebRTC would be at parity if the SDP mangling is no worse than wha= t is typically required today. If we can reach that point with an audio ap= plication (which I think is plausible) then the situation would be tolerabl= e=2C albeit not perfect. The SDP mangling in the WebRTC sample application= is at that level -- not pretty=2C but not shocking by any means. For vide= o=2C the non-WebRTC interop situation is much worse -- both SDP mangling (n= astier than for audio) and RTP/RTCP mangling is typically involved=2C even = for implementations of the same codec. Since RTP/RTCP mangling is the real= ly expensive operation=2C if this can be avoided=2C the cost of interop ca= n be brought way down. In the non-WebRTC world=2C we are just reaching the= point where this has become feasible=2C so I would set the WebRTC bar in r= oughly the same place - we may end up with more SDP mangling than is comfor= table=2C but we need to avoid RTP/RTCP mangling if at all possible. Harald= also said: =0A= "This may mean having the application use content settings to force=0A= tracks to different m-lines=2C keep low the number of tracks offered=2C= =0A= and other tricks that make sense in the context of *that=0A= application*. =0A= It's the *application* that needs to interwork=2C it's not "WebRTC in= =0A= general". WebRTC just needs to make it possible." [BA] Right. The real= ity is that most "applications" (90+ percent of them) won't need to put in = this effort=2C so it just needs to be possible to achieve for those that do= . And as long as it is not necessary to touch every RTP packet in the pro= cess=2C we are just talking about a one-time application development cost t= hat is "just software". Harald finally said: =0A= "I see the idea that *any application* should produce SDP that's=0A= useful in such a scenario as an illusion=2C and pursuing that illusion= =0A= is just going to hurt us." [BA] Agree. s/illusion/delusion/ :) =0A= =20 =0A= =20 =0A= =0A= =0A= =20 =0A= =0A= What I *would* like is for=0A= the RTP/RTCP produced by WebRTC implementations to not=0A= require a compute intensive media gateway/transcoder/munger=0A= to enable media to be handled by existing systems=2C at least= =0A= when the same video codecs are available (and no=2C that=0A= shouldn't necessarily mean "video codec implementations=0A= based on the same source code"=2C because the spec should be=0A= good enough to enable interoperability of independent=0A= implementations). =0A= =0A= =0A= =0A= =20 =0A= I find nothing to disagree with in this paragraph. =0A= =20 =0A= =0A= =0A= _______________________________________________=0A= mmusic mailing list=0A= mmusic@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mmusic = --_2f96a665-00b8-4027-95aa-7534604a700e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald said:
=0A=  =3B =3B =3B =3B =3B =3B =3B =3B =3B
=0A= =0A=  =3B =3B =3B
=0A= "I take a somewhat different approach:
=0A= If it's possible to *write an application* that uses the WebRTC=0A= interface=2C does not mangle the SDP=2C and sends that to an existing= =0A= implementation (supporting SRTP and ICE)=2C and has something useful=0A= happen=2C I think it's the success we can hope for."
 =3B=
[BA] Since existing non-WebRTC audio =3Bapplications typical= ly have to do at least some SDP mangling=2C =3B WebRTC would be at pari= ty if the SDP mangling =3Bis =3Bno =3Bworse than what is typica= lly required today. =3B =3BIf we can reach that point with an audio= application (which I think is plausible) then =3Bthe situation =3B= would be tolerable=2C albeit not perfect.  =3BThe SDP mangling in the W= ebRTC sample application is at that level -- not pretty=2C but not shocking= by any means.
 =3B
For video=2C the non-WebRTC in= terop situation is much worse -- both SDP mangling (nastier than for audio)= and RTP/RTCP mangling is typically =3Binvolved=2C even for= implementations of the same codec. =3B Since RTP/RTCP ma= ngling is the really expensive operation=2C if this can be avoided=2C the c= ost of =3B interop can be brought way down. =3B In the non-WebRTC w= orld=2C we are just reaching the point where this has become feasible=2C so= I would set the WebRTC bar in roughly the same place - we may =3Bend u= p with =3Bmore SDP mangling than is comfortable=2C but we need to avoid= RTP/RTCP mangling if at all possible.
 =3B
Harald= also said:

=0A= "This may mean having the application use content settings to force=0A= tracks to different m-lines=2C keep low the number of tracks offered=2C= =0A= and other tricks that make sense in the context of *that=0A= application*.
=0A= It's the *application* that needs to interwork=2C it's not "WebRTC in= =0A= general". WebRTC just needs to make it possible."
 =3B
[BA] Right. =3B The reality is that most "applications" (90+ pe= rcent of them) won't =3Bneed to put in this effort=2C so it just needs = to be possible to achieve for those that do. =3B  =3BAnd as long as= it is not necessary to touch every RTP packet in the process=2C we are jus= t talking about a one-time application development cost that is "just softw= are".
 =3B
Harald finally said:

=0A= "I see the idea that *any application* should produce SDP that's=0A= useful in such a scenario as an illusion=2C and pursuing that illusion= =0A= is just going to hurt us."
 =3B
[BA] Agree. s/i= llusion/delusion/ :)
=0A=
=0A=
=0A=  =3B =3B =3B
=0A=
=0A=

=0A=
=0A=
What I *would* like is for= =0A= the RTP/RTCP produced by WebRTC implementations to not=0A= require a compute intensive media gateway/transcoder/munger=0A= to enable media to be handled by existing systems=2C at least= =0A= when the same video codecs are available (and no=2C that=0A= shouldn't necessarily mean "video codec implementations=0A= based on the same source code"=2C because the spec should be=0A= good enough to enable interoperability of independent=0A= implementations).
=0A=
=0A=
=0A=
=0A=
=0A= I find nothing to disagree with in this paragraph.
=0A=
=0A= =0A= =0A=
_______________________________________________=0A= mmusic mailing list=0A= mmusic@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mmusic
= --_2f96a665-00b8-4027-95aa-7534604a700e_-- From worley@shell01.TheWorld.com Thu May 16 08:48:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEADC21F8F6E for ; Thu, 16 May 2013 08:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNvFqWJlMC9v for ; Thu, 16 May 2013 08:48:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id BB8BA21F8FC4 for ; Thu, 16 May 2013 08:48:01 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4GFlcJO013205; Thu, 16 May 2013 11:47:41 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4GFlcGn4864532; Thu, 16 May 2013 11:47:38 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4GFlckY4863857; Thu, 16 May 2013 11:47:38 -0400 (EDT) Date: Thu, 16 May 2013 11:47:38 -0400 (EDT) Message-Id: <201305161547.r4GFlckY4863857@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Roni Even" In-reply-to: <008d01ce4fb6$47860250$d69206f0$@gmail.com> (ron.even.tlv@gmail.com) References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> <008d01ce4fb6$47860250$d69206f0$@gmail.com> Cc: magnus.westerlund@ericsson.com, mmusic@ietf.org, payload@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:48:09 -0000 > From: "Roni Even" > > I am also concerned about putting in the registries the different case where > RTCP mux is used or not. I think the best we can do is add a general note in > the registry point at RFC5761 saying that it provides clarification on using > the pt type numbers in different cases. I do not believe that the registry table format allows us to express well the difference between the RTCP-mux case and the non-RTCP-mux case. I believe that we should add RFC 5761 as the *primary* reference for this registry. As a conservative choice, the PTs 64-95 can be marked as "reserved"; the careful reader of RFC 5761 can tell that in the non-RTCP-mux case, there is no danger that the endpoints will confuse those PTs with RTCP packets. Dale From worley@shell01.TheWorld.com Thu May 16 08:48:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E6121F93B0 for ; Thu, 16 May 2013 08:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMJZ08vKWsvz for ; Thu, 16 May 2013 08:48:08 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1B47021F9377 for ; Thu, 16 May 2013 08:48:02 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4GFltNm024996; Thu, 16 May 2013 11:47:57 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4GFltmn4876171; Thu, 16 May 2013 11:47:55 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4GFlt3X4878967; Thu, 16 May 2013 11:47:55 -0400 (EDT) Date: Thu, 16 May 2013 11:47:55 -0400 (EDT) Message-Id: <201305161547.r4GFlt3X4878967@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Magnus Westerlund In-reply-to: <51909E36.9050407@ericsson.com> (magnus.westerlund@ericsson.com) References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:48:14 -0000 > From: Magnus Westerlund > > Ok, I think you have convinced me that there is a point in updating or > at least clarifying the registry. Very good. > From my perspective I don't see major issues to use all 128 values of PT > field if needed when doing dynamic allocation and not using RTP/RTCP > MUX. Yes, I would use the one that collide with SR/RR RTCP packets last, > but I still would use them. The thing that is getting screwed up are > classifier filters, not the actual end-points. This is true. But it is difficult to express this fact in the table format of a registry. My preference is to provide RFC 5761 as the primary reference for the registry and to mark conservatively PTs 64 to 95 as "reserved". The careful reader of RFC 5761 can determine that in the non-RTCP-mux case that the endpoint will not confuse the endpoints, but that it may confuse network diagnostic elements. > I also think you should check with IANA if one can touch a closed > registry at all, or if we are restricted to clarifying notes for the > registry. I have sent an inquiry to Gonzalo about this point. Dale From worley@shell01.TheWorld.com Thu May 16 08:48:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FB721F85C9 for ; Thu, 16 May 2013 08:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWdguUEBrS0M for ; Thu, 16 May 2013 08:48:15 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id EA0BE21F8EB5 for ; Thu, 16 May 2013 08:48:06 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4GFlLbl001790; Thu, 16 May 2013 11:47:23 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4GFlKZL4878276; Thu, 16 May 2013 11:47:21 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4GFlKwa4878884; Thu, 16 May 2013 11:47:20 -0400 (EDT) Date: Thu, 16 May 2013 11:47:20 -0400 (EDT) Message-Id: <201305161547.r4GFlKwa4878884@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Cullen Jennings (fluffy)" In-reply-to: (fluffy@cisco.com) References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> Cc: magnus.westerlund@ericsson.com, mmusic@ietf.org, payload@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:48:21 -0000 I want to confirm that I understand you here: I believe that you are giving the references for the various RTCP packet types that could potentially collide with the numbers given as RTP payload type. E.g., RTP PT 65 could be mistaken for RTCP packet type 65 + 128 = 193. And RTCP 193 is marked in the "RTCP Control Packet types (PT)" registry with reference RFC 2032. So I believe that the information in the table you've written below is captured in "RTCP Control Packet types (PT)" (http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-3). Dale > From: "Cullen Jennings (fluffy)" > CC: Magnus Westerlund , > "mmusic@ietf.org" > , > "payload@ietf.org" > Date: Fri, 10 May 2013 21:19:15 +0000 > Accept-Language: en-US > > > > 64-65 have been obsolete and given the lack of H.261 being used in deployments I think it is safe if they are in the secondary pool. > > I think they would be better to ref > > 65 [RFC2032] > 66 [RFC5484] > > For the rest, I think it should be more like > > 65 [RFC2032] > 66 [RFC5484] > 67 [RFC5450] > > 72 [RFC3550] > 73 [RFC3550] > 74 [RFC3550] > 75 [RFC3550] > 76 [RFC3550] > > 77 [RFC4585] > 78 [RFC4585] > > 79 [RFC3611] > 80 IEEE Std 1733TM-2011 > > Given how the next two are used, bit hard to decide what the impact is when doing O/A > 81 [RFC5760] > 82 [RFC6284] From martin.thomson@gmail.com Thu May 16 09:36:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D221F8F3E for ; Thu, 16 May 2013 09:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fbBdiLUfIRZ for ; Thu, 16 May 2013 09:36:01 -0700 (PDT) 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 B02FF21F898A for ; Thu, 16 May 2013 09:36:00 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id x54so2907843wes.0 for ; Thu, 16 May 2013 09:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=711rnUMyUoWIZr/zUHnIthK5X8uKefQaDYqzCcuzX1o=; b=mOBAI+laGAWNwsbMEbk8+b/XhHkygF4eBnLjFKBuF2g7MVttNXIKfjFdUuoQvSsJWQ 3BwAsuq/9OZO20OXqlxYeqT+c02fR4Q9AYJTlG9ckrjegt7befOklkkDzVx8NAU6Rv5S Gua8BTaZrvqYrE5tTBK85Ix3jrCzgYxhxQbGlnlUaorCEHmg2ACAuzwvgIK9g5TmM2iA GhZidj4EK+ePMg8ekQcJaFu/Qh1I4LO/EkBvS6r6HTia64LwVp1gZTBAH5dM2tv8lPhU Wx72K6ChhcVezLfbfPRmPOSxgfOrqYL97y+LhjBlcECUJXNh3je3pLMcTvTrUiCzGqfA syWQ== MIME-Version: 1.0 X-Received: by 10.180.88.231 with SMTP id bj7mr26269667wib.5.1368722159875; Thu, 16 May 2013 09:35:59 -0700 (PDT) Received: by 10.194.20.135 with HTTP; Thu, 16 May 2013 09:35:59 -0700 (PDT) In-Reply-To: References: <5193B1DB.2070308@alum.mit.edu> <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> <5193EA5C.7050905@alvestrand.no> Date: Thu, 16 May 2013 09:35:59 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:36:01 -0000 On 15 May 2013 15:43, Bernard Aboba wrote: > Harald finally said: > > "I see the idea that *any application* should produce SDP that's useful in > such a scenario as an illusion, and pursuing that illusion is just going to > hurt us." > > [BA] Agree. s/illusion/delusion/ :) I think that is a perfectly pragmatic conclusion to reach. However, it still leaves the issue open. I'd like to at least reach a point where there is agreement on just one model for interpreting the SDP that is output and input to the WebRTC API. If we have multiple interpretations, then we still need to reach consensus on which one is the one we want to use. That's a whole lot harder if that is not "the one true interpretation", because someone wont get what they want. --Martin p.s., It's been a long time, and I've been suppressing the urge, but I can't help but think that Comment 22 is appropriate at this moment. From emil@sip-communicator.org Thu May 16 09:44:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D5621F90DF for ; Thu, 16 May 2013 09:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dVwxCb7XpGp for ; Thu, 16 May 2013 09:44:43 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 957BB21F85C3 for ; Thu, 16 May 2013 09:44:42 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id it19so1222783bkc.13 for ; Thu, 16 May 2013 09:44:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ceNns6kki52dK7BKQEo+gIFk5En67o63DrDb5WIdPOA=; b=gtf4Hh8xqKA1mf2hwlSPZC5wEVvSkcfnkf0q5NwHpcYInWPdK2L7RhLbfdMZ6fWzYU f2xr0hXC4OGqCu42vNEP1Jcs88P7JvpNblj75RjdT2rZiHF8b8mPhOKeTU21m/JAlaqb PSsFv05lpekiXf8Ss3+xvwUDyqL4YgUd3TSYtuAGQKf1dUltcRxYtwWJcodc8CqUu5Et UcSb2iS+pByXQBhnIcduGHCAYuSEd/wLR2paiNjEcBGkjhx1c09DnnrSFbiJ42zylRI9 psvNorriIlI9lw9TWLd5+SnncokIFY2qAIxt8M7qtGhWolyrpwqgJ0msI25QkVJ05/1b /KZg== X-Received: by 10.204.245.201 with SMTP id lv9mr13718489bkb.102.1368722670303; Thu, 16 May 2013 09:44:30 -0700 (PDT) Received: from camionet.local ([79.100.215.70]) by mx.google.com with ESMTPSA id tc9sm2264557bkb.18.2013.05.16.09.44.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 09:44:29 -0700 (PDT) Message-ID: <51950CED.6020305@jitsi.org> Date: Thu, 16 May 2013 19:44:29 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <5193B1DB.2070308@alum.mit.edu> <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> <5193EA5C.7050905@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmR78rrk8p1iW4haxKjHjr0e2Ki2p6VgL5VmbLH0O6Zq7guekc1CkRgnB7NH8zmKZ8piik6 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:44:43 -0000 On 16.05.13, 19:35, Martin Thomson wrote: > On 15 May 2013 15:43, Bernard Aboba wrote: >> Harald finally said: >> >> "I see the idea that *any application* should produce SDP that's useful in >> such a scenario as an illusion, and pursuing that illusion is just going to >> hurt us." >> >> [BA] Agree. s/illusion/delusion/ :) > > I think that is a perfectly pragmatic conclusion to reach. However, > it still leaves the issue open. I'd like to at least reach a point > where there is agreement on just one model for interpreting the SDP > that is output and input to the WebRTC API. If we agree that basing design decisions on legacy devices and their view of what an m= line is (or rather isn't). Then is there any reason not to accept the RTP-centric description of an m= line that Colin described? Emil -- https://jitsi.org From martin.thomson@gmail.com Thu May 16 10:12:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE3321F8AD5 for ; Thu, 16 May 2013 10:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGQTVPYY-wfq for ; Thu, 16 May 2013 10:12:08 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id C736421F8AA8 for ; Thu, 16 May 2013 10:12:07 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so2809659wgh.6 for ; Thu, 16 May 2013 10:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DaCkUO2YK57QXg4wzL2mOFSS8/5jck5oPPo7TLdqLA4=; b=MjjRjiBjAAS5WdlMIVI0Qis4KUSUJIGXFZpi+bmBFRIxRHFWjbUYjWhvo1gS275Y8m rv5V9Ei10N3FajqPogyiTvr8AuhZmFwnmwpnslL3k5AMt0xX8bG9VPOtydksYKLc0z8U ApcEcJ7GpxLJQdMlUDLWGKf492VXLO8a5NHQli2P3c4ce1LOvL2XwUENqLyt5iKFO0kx efR9DNB07/fvk1JAO53gGTdScrqvRq1L+gvEnkDo8dMag05H0nilgi0GLksIIYAjprq5 6jTADJSkuEsHgSKP0z2sLoVem9V1aREJztYrBSDdEVkQs9EWtsYqGQGFPvlO+KMvCZ91 fUOQ== MIME-Version: 1.0 X-Received: by 10.180.20.148 with SMTP id n20mr26329801wie.8.1368724326930; Thu, 16 May 2013 10:12:06 -0700 (PDT) Received: by 10.194.20.135 with HTTP; Thu, 16 May 2013 10:12:06 -0700 (PDT) In-Reply-To: <51950CED.6020305@jitsi.org> References: <5193B1DB.2070308@alum.mit.edu> <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> <5193EA5C.7050905@alvestrand.no> <51950CED.6020305@jitsi.org> Date: Thu, 16 May 2013 10:12:06 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 17:12:08 -0000 On 16 May 2013 09:44, Emil Ivov wrote: >> I think that is a perfectly pragmatic conclusion to reach. However, >> it still leaves the issue open. I'd like to at least reach a point >> where there is agreement on just one model for interpreting the SDP >> that is output and input to the WebRTC API. > > If we agree that basing design decisions on legacy devices and their > view of what an m= line is (or rather isn't). Then is there any reason > not to accept the RTP-centric description of an m= line that Colin > described? Yes, it might be premature. I'm not sure that we've explored all of the implications of that statement. For instance, no one has even discussed call transfer scenarios yet. We haven't explored the consequences of SSRC collision. We have to agree that the model we use actually fits the sorts of things that need to fit. From adam@nostrum.com Thu May 16 10:23:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247EE21F882A; Thu, 16 May 2013 10:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wX3OtTA-l6D; Thu, 16 May 2013 10:23:30 -0700 (PDT) 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 7200D21F8605; Thu, 16 May 2013 10:23:30 -0700 (PDT) Received: from Orochi.local (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 r4GHNIwd070721 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 12:23:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51951605.6030602@nostrum.com> Date: Thu, 16 May 2013 12:23:17 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Dale R. Worley" References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> <201305161547.r4GFlt3X4878967@shell01.TheWorld.com> In-Reply-To: <201305161547.r4GFlt3X4878967@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: Magnus Westerlund , mmusic@ietf.org, payload@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 17:23:31 -0000 On 5/16/13 10:47, Dale R. Worley wrote: > My preference is to provide RFC 5761 as the primary reference for the > registry and to mark conservatively PTs 64 to 95 as "reserved". The > careful reader of RFC 5761 can determine that in the non-RTCP-mux case > that the endpoint will not confuse the endpoints, but that it may > confuse network diagnostic elements. It can also frustrate attempts to gateway between a system that does multiplexing and one that does not. I think we should treat them as off-limits for all uses, regardless of whether we're multiplexing RTCP over the same channel. /a From emcho@sip-communicator.org Thu May 16 10:52:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D6C11E812A for ; Thu, 16 May 2013 10:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIX3ZtzXSB1k for ; Thu, 16 May 2013 10:52:26 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id E70FD11E8126 for ; Thu, 16 May 2013 10:52:25 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ey16so2980629wid.5 for ; Thu, 16 May 2013 10:52:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=I2TlNnewVIz/YKzF5hmJu3soxR8S0k1GM7/oiK6FZ2E=; b=Iqmd3YwBugA8nhLbmMvOZLJPAXio44geq4xjnMUnWgHn6zRgGYEUxqsn2MpfA1DOKc AppLYpx1K3za+3SNRZAVXr530vNwgcotvPpUSe9y4n3JkwfyoRtUQgm/SqsQku+ncMxE NseWjv2gMhUJ271OJqOdPo1/8TnZtY7X7mdJ10jFahtQgn1oFA/vOKxBbhI6xf7TXtcU CHCcUXQ9w5825GWyun1ctNH1BLdR6hodPiMp3Ps6KOU9usEhih2TYs5bfLBFjEjSSbSi jhMGkJtSLJY/BzbIF7ZUTV7Hz1B/8rMBfF0cGHJOvvxdU1JBvVuEJSLjrbzw7BvSy685 xqgQ== X-Received: by 10.180.189.68 with SMTP id gg4mr12290231wic.27.1368726744865; Thu, 16 May 2013 10:52:24 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [2607:f8b0:400c:c01::231]) by mx.google.com with ESMTPSA id dj7sm5324930wib.6.2013.05.16.10.52.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 10:52:24 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id ox1so3275862veb.36 for ; Thu, 16 May 2013 10:52:22 -0700 (PDT) X-Received: by 10.58.50.198 with SMTP id e6mr28496038veo.30.1368726742522; Thu, 16 May 2013 10:52:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.167.197 with HTTP; Thu, 16 May 2013 10:52:01 -0700 (PDT) In-Reply-To: References: <5193B1DB.2070308@alum.mit.edu> <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> <5193EA5C.7050905@alvestrand.no> <51950CED.6020305@jitsi.org> From: Emil Ivov Date: Thu, 16 May 2013 20:52:01 +0300 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkmOnI8M5j37V4Vr+2KWjHaum/nTEFx8xLL69H9mA7p3J6e4BCw4K+ECZv8SKVfm65Pt1oz Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 17:52:26 -0000 On Thu, May 16, 2013 at 8:12 PM, Martin Thomson wrote: > On 16 May 2013 09:44, Emil Ivov wrote: >>> I think that is a perfectly pragmatic conclusion to reach. However, >>> it still leaves the issue open. I'd like to at least reach a point >>> where there is agreement on just one model for interpreting the SDP >>> that is output and input to the WebRTC API. >> >> If we agree that basing design decisions on legacy devices and their >> view of what an m= line is (or rather isn't). Then is there any reason >> not to accept the RTP-centric description of an m= line that Colin >> described? > > Yes, it might be premature. I'm not sure that we've explored all of > the implications of that statement. For instance, no one has even > discussed call transfer scenarios yet. We haven't explored the > consequences of SSRC collision. Could you please be more specific about the sorts of problems you expect and how they are caused by adhering to the basics of RTP? > We have to agree that the model we use actually fits the sorts of > things that need to fit. I always thought people agreed on that when they chose RTP for these things, but again, I'd be very interested to hear about the problems you expect. Emil -- https://jitsi.org From keith.drage@alcatel-lucent.com Thu May 16 10:54:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D6011E8142; Thu, 16 May 2013 10:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWy2ovAUanVv; Thu, 16 May 2013 10:54:22 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2D311E8126; Thu, 16 May 2013 10:54:21 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r4GHs7pR024308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 May 2013 12:54:08 -0500 (CDT) 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 r4GHs6gN032140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 13:54:06 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 16 May 2013 13:54:06 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 16 May 2013 19:54:03 +0200 From: "DRAGE, Keith (Keith)" To: "Dale R. Worley" , Roni Even Thread-Topic: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? Thread-Index: AQHOUkzLLsu164tLIUibgvMxBULeBZkIFknQ Date: Thu, 16 May 2013 17:54:03 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B03B590@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> <008d01ce4fb6$47860250$d69206f0$@gmail.com> <201305161547.r4GFlckY4863857@shell01.TheWorld.com> In-Reply-To: <201305161547.r4GFlckY4863857@shell01.TheWorld.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] 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.39 Cc: "magnus.westerlund@ericsson.com" , "mmusic@ietf.org" , "payload@ietf.org" Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 17:54:32 -0000 The registry is not there to show how values are used. It should concentrate on two issues: - Making sure the value is reserved so that it can not be reused for someth= ing else - Identifying where the user should go to find further information about th= at value. Anything else should be in the RFCs. If there is lack of clarity as a resul= t, that means spinning a new version of the RFC or filing a fix. We cannot fix lack of clarity in the RFCs by playing with the IANA tables. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Dale R. Worley > Sent: 16 May 2013 16:48 > To: Roni Even > Cc: magnus.westerlund@ericsson.com; mmusic@ietf.org; payload@ietf.org > Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC > 5761? >=20 > > From: "Roni Even" > > > > I am also concerned about putting in the registries the different case > where > > RTCP mux is used or not. I think the best we can do is add a general > note in > > the registry point at RFC5761 saying that it provides clarification on > using > > the pt type numbers in different cases. >=20 > I do not believe that the registry table format allows us to express > well the difference between the RTCP-mux case and the non-RTCP-mux > case. I believe that we should add RFC 5761 as the *primary* > reference for this registry. As a conservative choice, the PTs 64-95 > can be marked as "reserved"; the careful reader of RFC 5761 can tell > that in the non-RTCP-mux case, there is no danger that the endpoints > will confuse those PTs with RTCP packets. >=20 > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Thu May 16 11:01:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C6E21F8F0C for ; Thu, 16 May 2013 11:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYVKF15GrWgj for ; Thu, 16 May 2013 11:01:07 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA4721F8F09 for ; Thu, 16 May 2013 11:01:07 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so2846695wgh.15 for ; Thu, 16 May 2013 11:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=O5SRWqVuBDcUWcZglU66mdLC08m/PFQrub7mnUhwsHc=; b=y9jH6ielQa37MXOIyx0yN3btCqbykVQLYurEbZjDhN+1JZoa4ZC1/XOWnKjPxa7Xp+ CoDWKEpvsB8YjjmhpQ4vyHYRSD3zs5MhkGC7YwJFy1i2/gxHk0NE4rFae/kz6AgUC7Xc LcQ8tZB8gxdnH+92wyCR/dKcu7lUpSENRkEQn6yeSEYcOXmWvFQOzeYcxkVN7o7C+cgT uP15JkFT/X9l+jv0YJ9yJtDIBYUCpCB+ZTKkmA6Dk8JfHh/BhX3XcybHV+xvDk+0u7zI ra8qEZfpMx2Aw99RdUoxjxp5EKMN40dPhEqh31LKQTCVg13QBV9k4OfqLBYH6ikYoBOp eKrQ== MIME-Version: 1.0 X-Received: by 10.181.13.112 with SMTP id ex16mr8548941wid.28.1368727266243; Thu, 16 May 2013 11:01:06 -0700 (PDT) Received: by 10.194.20.135 with HTTP; Thu, 16 May 2013 11:01:06 -0700 (PDT) In-Reply-To: References: <5193B1DB.2070308@alum.mit.edu> <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> <5193EA5C.7050905@alvestrand.no> <51950CED.6020305@jitsi.org> Date: Thu, 16 May 2013 11:01:06 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:01:07 -0000 On 16 May 2013 10:52, Emil Ivov wrote: > Could you please be more specific about the sorts of problems you > expect and how they are caused by adhering to the basics of RTP? I'm not a strong proponent of these things, and I expect those proponents to stand up and say something. However, it is my understanding that in a call transfer case, the arrival of a new SSRC is treated as though the remote source has been switched out, not as though a new participant has been added to the session. The same has to be true when a new SSRC is chosen in the case of a collision. This is clearer when you talk about video. Does the video from the new SSRC go in the same window (/frame/
--0015175cf92a8338a804dd5e516a-- From magnus.westerlund@ericsson.com Thu May 23 01:23:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10421F9686 for ; Thu, 23 May 2013 01:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.965 X-Spam-Level: X-Spam-Status: No, score=-104.965 tagged_above=-999 required=5 tests=[AWL=1.284, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6F0RTKdQiM7 for ; Thu, 23 May 2013 01:23:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D9E7721F96C1 for ; Thu, 23 May 2013 01:23:39 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-5e-519dd20a9090 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AC.72.28930.A02DD915; Thu, 23 May 2013 10:23:38 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 23 May 2013 10:23:38 +0200 Message-ID: <519DD209.3010100@ericsson.com> Date: Thu, 23 May 2013 10:23:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mmusic (E-mail)" , Gonzalo Camarillo References: <20130521192043.28957.35761.idtracker@ietfa.amsl.com> In-Reply-To: <20130521192043.28957.35761.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+JvrS7XpbmBBs//SllMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGbOv7mArOC9csXHZZeYGxgv8XYwcHBICJhILlnt0MXICmWIS F+6tZ+ti5OIQEjjFKPGk5xELSEJIYDmjxIZ/gSA2r4C2xOpVe8DiLAKqElfb34PZbAIWEjd/ NLKB2KICwRJHtm9mgagXlDg58wmYLSIQJ7G4/So7iC0sUCexce8xVoj5jhLXmz8xgdicAk4S v5sgbAkBSYktL9rB6pkF9CSmXG1hhLDlJZq3zmaG6NWWaGjqYJ3AKDgLybpZSFpmIWlZwMi8 ipE9NzEzJ73ccBMjMPgObvmtu4Px1DmRQ4zSHCxK4ry92lMDhQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTCyGq/u5A/d0Gto801k2yWN2/LpPdr3ZCLd+y09NliZqIuwH69pdfBz/lt34tFs w2XyebkccY0GXC0HN2w9X9v2LOx2jFgvU/z+473n3pbP2r9GieHP/HOHFzJ5ybf57inye7R3 9uLlvdPTivr3R/5dmz1/tZO/mMzGKP4KBvaQ+v1yxeukHJVYijMSDbWYi4oTAaYTYgMMAgAA Subject: Re: [MMUSIC] Last Call: (Real Time Streaming Protocol 2.0 (RTSP)) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 08:23:49 -0000 WG and AD, We authors have received private feedback about some editorial issues. We intended to address these at the end of the IETF last call. So don't be surprised by yet another revision. Cheers Magnus On 2013-05-21 21:20, The IESG wrote: > > The IESG has received a request from the Multiparty Multimedia Session > Control WG (mmusic) to consider the following document: > - 'Real Time Streaming Protocol 2.0 (RTSP)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-06-04. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > 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-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). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/2028/ > http://datatracker.ietf.org/ipr/1189/ > > > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From suhasietf@gmail.com Thu May 23 01:43:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B244311E81AD for ; Thu, 23 May 2013 01:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fak52-FDyeAL for ; Thu, 23 May 2013 01:43:30 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C462811E81A5 for ; Thu, 23 May 2013 01:43:29 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j11so3298078qag.16 for ; Thu, 23 May 2013 01:43:29 -0700 (PDT) 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=B6IucTl2sL3VCzhcWMCXdqH9tYSukVUvdeW1mHxdXd0=; b=suYPKsTT6zCekVwLlud/7i0cO2WeO0BaPKU7rRmZ9nVu17Aatoo79vYpSb13TJa2x7 0K6aEH3wxQHPS7nT5DuIINCnkSSNtRGAQ1MXXW2ZjV7D/YkHWgSKSp0K4E2oPfdyWTAT OJa8IF5BBmiIsfWlQ7jVVzdk2PaRti3+saC4kist9iu+Ue6ALzFmZypot0pMgz4c/v4p Xi72hcnar9+Y48kxJRWjeIYvW27pwyAJLT6eqhDqbCdKswJvGYnDND1LeyamrbSYABAR ZsC1MtGaMu1el/GhfHe5KXZ9pJwGp/vaNw3hLyh6WNnLO7DteTzgFTTDvcrwu1Ex08Pk Vizg== MIME-Version: 1.0 X-Received: by 10.49.29.97 with SMTP id j1mr12057511qeh.52.1369298609219; Thu, 23 May 2013 01:43:29 -0700 (PDT) Received: by 10.49.25.14 with HTTP; Thu, 23 May 2013 01:43:29 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> Date: Thu, 23 May 2013 01:43:29 -0700 Message-ID: From: Suhas Nandakumar To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bea3e1631e19c04dd5ead9a Cc: mmusic , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 08:43:30 -0000 --047d7bea3e1631e19c04dd5ead9a Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 3:55 PM, Justin Uberti wrote: > I think we could do this using the existing syntax, e.g. > > an offer of a=group:BUNDLE A B C would indicate that the offerer would > prefer A, B, and C to be muxed onto A, and > an answer of a=group:BUNDLE C A would indicate that the answerer is going > to mux C and A onto C, and send B unbundled. > > > Agree with this. This also fits with the way to categorization for Attr Muxing as TRANSPORT. > > On Wed, May 22, 2013 at 7:11 AM, Kevin Dempsey wrote: > >> Would it make it simpler if the offer included an attribute in bundled m= >> lines that said where to send the media if bundle is supported by the >> answerer; and for the answer to include an attribute that said where it was >> going to send the media (ie. to the bundled destination or the unbundled >> destination) >> >> >> On 22 May 2013 14:55, Paul Kyzivat wrote: >> >>> On 5/22/13 1:00 AM, Justin Uberti wrote: >>> >>> Taking into account Emil's suggestion as well, this leads to this >>>> restatement of the rules: >>>> >>>> 1.1) An offerer must be prepared to receive unbundled traffic on the >>>> offered ports, as if talking to a legacy endpoint. >>>> 1.2) An offerer must be prepared to receive bundled traffic on any port, >>>> except the port associated with the last m= line. >>>> 2) Once the answer is received, the decision on bundled/unbundled and >>>> which ports to use is finalized. >>>> 2.1) BUNDLEd m= lines use the port of the m= line that appears first in >>>> the bundle. >>>> 2.2) Unused ports can be discarded at this point. >>>> 3.1) m= lines offered with distinct ports may be omitted from the bundle >>>> answer, in line with RFC 5888. >>>> 3.2) m= lines offered with the same port may not be omitted from the >>>> bundle answer, since there is no unbundled port from them to fall back >>>> to. >>>> 3.3) m= lines that are rejected are omitted from the bundle answer, per >>>> RFC 5888. >>>> >>>> Quick check on 2.1: are we using the m= line that appears first in the >>>> SDP, or the m= line that appears first in the a=group:BUNDLE? >>>> >>> >>> IMO it would be best to use the lexically first m-line that has a >>> non-zero port and that appears in the bundle group of the answer. >>> >>> Alternately, it *could* be the m-line with non-zero port that appears >>> first in the bundle group of the answer. But if so, the exception in 1.2 >>> would also need to be correspondingly adjusted. >>> >>> AFAICT the only reason to mention that exception in 1.2 is that might >>> provide an opportunity for optimization, by setting up the port with >>> simpler code that doesn't support bundling. I don't see a requirement in >>> 5888 that the bundle group in the answer be ordered the same way as in the >>> offer. So the one m-line guaranteed not to receive bundled traffic would >>> then not be predictable at the time of the offer, so could not be >>> exploited. This problem doesn't exist if the lexical ordering of m-lines is >>> used. >>> >>> Thanks, >>> Paul >>> >>> >>> ______________________________**_________________ >>> 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 > > --047d7bea3e1631e19c04dd5ead9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 22, 2013 at 3:55 PM, Justin = Uberti <juberti@google.com> wrote:
I think we could do this using the existing syntax, e.g.= =A0

an offer of a=3Dgroup:BUNDLE A B C would indicate th= at the offerer would prefer A, B, and C to be muxed onto A, and=A0
an answer of a=3Dgroup:BUNDLE C A would indicate that the answerer is goi= ng to mux C and A onto C, and send B unbundled.


<= div>Agree with this. This also fits with the way to categorization for Attr= Muxing as TRANSPORT.=A0
On Wed, May 22, 2013 at 7:11 AM, Kevin Dempsey = <kevindempsey70@gmail.com> wrote:
Would it make it simpler if= the offer included an attribute in bundled m=3D lines that said where to s= end the media if bundle is supported by the answerer; and for the answer to= include an attribute that said where it was going to send the media (ie. t= o the bundled destination or the unbundled destination)


On = 22 May 2013 14:55, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:
On 5/22/13 1:00 AM, Justin Uberti wrote:

Taking into account Emil's suggestion as well, this leads to this
restatement of the rules:

1.1) An offerer must be prepared to receive unbundled traffic on the
offered ports, as if talking to a legacy endpoint.
1.2) An offerer must be prepared to receive bundled traffic on any port, except the port associated with the last m=3D line.
2) Once the answer is received, the decision on bundled/unbundled and
which ports to use is finalized.
2.1) BUNDLEd m=3D lines use the port of the m=3D line that appears first in=
the bundle.
2.2) Unused ports can be discarded at this point.
3.1) m=3D lines offered with distinct ports may be omitted from the bundle<= br> answer, in line with RFC 5888.
3.2) m=3D lines offered with the same port may not be omitted from the
bundle answer, since there is no unbundled port from them to fall back to.<= br> 3.3) m=3D lines that are rejected are omitted from the bundle answer, per RFC 5888.

Quick check on 2.1: are we using the m=3D line that appears first in the SDP, or the m=3D line that appears first in the a=3Dgroup:BUNDLE?

IMO it would be best to use the lexically first m-line that has a non-zero = port and that appears in the bundle group of the answer.

Alternately, it *could* be the m-line with non-zero port that appears first= in the bundle group of the answer. But if so, the exception in 1.2 would a= lso need to be correspondingly adjusted.

AFAICT the only reason to mention that exception in 1.2 is that might provi= de an opportunity for optimization, by setting up the port with simpler cod= e that doesn't support bundling. I don't see a requirement in 5888 = that the bundle group in the answer be ordered the same way as in the offer= . So the one m-line guaranteed not to receive bundled traffic would then no= t be predictable at the time of the offer, so could not be exploited. This = problem doesn't exist if the lexical ordering of m-lines is used.

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


_______________________________________________
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


--047d7bea3e1631e19c04dd5ead9a-- From suhasietf@gmail.com Thu May 23 02:05:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4460A21F8E9A for ; Thu, 23 May 2013 02:05:00 -0700 (PDT) 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=[AWL=-1.766, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MANGLED_FORM=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgX2mekoCJxd for ; Thu, 23 May 2013 02:04:56 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0728F21F8D94 for ; Thu, 23 May 2013 02:04:55 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so1044010qea.21 for ; Thu, 23 May 2013 02:04:55 -0700 (PDT) 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=QUrmdo+mk70mHeiTcR7vz6Nyxg06KEsFagVsNkh9E4M=; b=jYcyimkocGfGZyxRVF8N3/aRpCCTiKiXKVm3t/AJB0NQ1UsDkjpv7G/2OfDK8R0utW cMuzk1Ujiw9ODfApkiK5av4gsc/7zYyhBlfALYXObXtJBrLjdpozj8Hy+ZPraGQM0u+5 jHcC3Tj2Ei5ycyBTCTf8Zg9q0uwtp55SXpoH5vJWa5mQSI8ynDlHuq80lAQPCYqmvJpW hC9aoQXG2ZTIebHzS8yOJadeIAUW/Pt6T1GiC6QhRX2VWXwRuZVpeTL6UJGCH55w/Aa5 QvlmKBjp+DOekUlUroGPirBlUlXg/1rXwHeLNhUOcAX0aYOqR4zSQbXSVNyFzrrCUS2n stDQ== MIME-Version: 1.0 X-Received: by 10.224.34.198 with SMTP id m6mr10842253qad.39.1369299895512; Thu, 23 May 2013 02:04:55 -0700 (PDT) Received: by 10.49.25.14 with HTTP; Thu, 23 May 2013 02:04:55 -0700 (PDT) In-Reply-To: <519138CB.5020202@alum.mit.edu> References: <519138CB.5020202@alum.mit.edu> Date: Thu, 23 May 2013 02:04:55 -0700 Message-ID: From: Suhas Nandakumar To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf3074b7b0dd0e6804dd5ef9c4 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] What is an m-line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:05:00 -0000 --20cf3074b7b0dd0e6804dd5ef9c4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 13, 2013 at 12:02 PM, Paul Kyzivat wrote: > On 5/13/13 2:42 PM, Martin Thomson wrote: > >> We've had a great deal of discussion about plan A and B and the >> various interactions of these proposals with bundling. But I still >> don't get a good sense that there is a working consensus on what an >> m-line actually represents. >> >> I think that we've each reached our own conclusions, but they >> definitely are not consistent. We need a well-understood semantic for >> m-lines if we have any chance of resolving these issues; Plan A/B >> being only the first RTCWEB problem to address. >> >> RFC 4566 is helpfully devoid of detail, so we are free to come up with >> any interpretation we choose. Here are the ones that I have seen: >> >> 1. an m-line represents a single RTP session >> (or at least the part of the session that touches the client) >> This appears to be consistent with the Plan B approach >> > > Well, it was my impression that Plan B still intends to allow bundling in > order to combine audio and video into a single RTP session. So in that case > neither of the m-lines represents a single RTP session in full. > > > 2. an m-line represents the set of RTP streams that decode into a >> single rendering, including layers, simulcast and FEC >> > > Hmm. I was thinking *this* was what Cullen intended by Plan A. > But now that you bring it up, I thing there is some existing SDP syntax > for simulcast/FEC/FID that might only work with (3). (But I don't have the > details of that stuff in my head.) > > > 3. an m-line represents a single RTP stream; multiple m-lines might >> be required to obtain a single rendering if it uses layers, simulcast, >> FEC or FID groupings >> This appears to be consistent with the Plan A approach >> > > I offer another try: > > 4. an m-line represents one or more (zero or more?) > sources/flows/tracks/captures (pick the name that suits you) that share a > single RTP session and that all are consistent with the media description > accompanying the m-line. > > IIUC this is what Plan B is trying to achieve. > > I think trying to describe a m=line based on the usage isn't the right way. Since each approach, either Plan A or Plan B or Plan Z can choose to add/remove aspects of the description in defining a m=line. In general all the above can be m=line. Media description as understood by RFC4566 is a way to describe aspects of media stream from a sender to a receiver. It should be able to describe - underlying transport context - media context (encoder/decoder) most importantly How such description(s) is/are mapped to the underlying RTP session(s) or how is it mapped to source and sinks or how relationships is established is just a matter of choice as enforced by the usage. Hence i feel this question turns out to be more philosophical to me :) ./Suhas > Thanks, > Paul > > > In the first instance, an m-line can be multiple "things". In the >> latter two cases, an m-line is consistently one "thing" (or part >> thereof). >> >> The first interpretation has a natural advantage in terms of signaling >> economy and natural bundling. The latter interpretations seem to have >> advantages in dealing with call transfer and SSRC renumbering. >> >> So, which is correct? >> ______________________________**_________________ >> 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 > --20cf3074b7b0dd0e6804dd5ef9c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, May 13, 2013 at 12:02 PM, Paul K= yzivat <pkyzivat@alum.mit.edu> wrote:
On 5/13/13 2:42 PM, Martin Thomson wrote:
We've had a great deal of discussion about plan A and B and the
various interactions of these proposals with bundling. =A0But I still
don't get a good sense that there is a working consensus on what an
m-line actually represents.

I think that we've each reached our own conclusions, but they
definitely are not consistent. =A0We need a well-understood semantic for m-lines if we have any chance of resolving these issues; Plan A/B
being only the first RTCWEB problem to address.

RFC 4566 is helpfully devoid of detail, so we are free to come up with
any interpretation we choose. =A0Here are the ones that I have seen:

=A0 1. an m-line represents a single RTP session
=A0 =A0 =A0(or at least the part of the session that touches the client) =A0 =A0 =A0This appears to be consistent with the Plan B approach

Well, it was my impression that Plan B still intends to allow bundling in o= rder to combine audio and video into a single RTP session. So in that case = neither of the m-lines represents a single RTP session in full.


=A0 2. an m-line represents the set of RTP streams that decode into a
single rendering, including layers, simulcast and FEC

Hmm. I was thinking *this* was what Cullen intended by Plan A.
But now that you bring it up, I thing there is some existing SDP syntax for= simulcast/FEC/FID that might only work with (3). (But I don't have the= details of that stuff in my head.)


=A0 3. an m-line represents a single RTP stream; multiple m-lines might
be required to obtain a single rendering if it uses layers, simulcast,
FEC or FID groupings
=A0 =A0 =A0This appears to be consistent with the Plan A approach

I offer another try:

4. an m-line represents one or more (zero or more?) sources/flows/tracks/ca= ptures (pick the name that suits you) that share a single RTP session and t= hat all are consistent with the media description accompanying the m-line.<= br>
IIUC this is what Plan B is trying to achieve.


=A0 =A0 =A0 =A0 I think trying to desc= ribe a m=3Dline based on the usage isn't the right way. Since each appr= oach, either Plan A or Plan B or Plan Z can choose to add/remove aspects of= the description in defining a m=3Dline. In general all the above can be m= =3Dline.

Media description as understood by RFC4566 is a way to = describe aspects of media stream from a sender to a receiver. It should be = able to describe=A0
=A0 =A0 - underlying transport context
<= div> =A0 =A0 - media context (encoder/decoder)=A0
=A0 =A0most importan= tly

How such =A0description(s) is/are mapped to th= e underlying RTP session(s) =A0or how is it mapped to source and sinks or h= ow =A0relationships is established is just a matter of choice as enforced b= y the usage.

Hence i feel this question turns out to be more philoso= phical to me :)


./Suhas
= =A0
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


In the first instance, an m-line can be multiple "things". =A0In = the
latter two cases, an m-line is consistently one "thing" (or part<= br> thereof).

The first interpretation has a natural advantage in terms of signaling
economy and natural bundling. =A0The latter interpretations seem to have advantages in dealing with call transfer and SSRC renumbering.

So, which is correct?
_______________________________________________
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

--20cf3074b7b0dd0e6804dd5ef9c4-- From suhasietf@gmail.com Thu May 23 02:20:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515DD21F9631 for ; Thu, 23 May 2013 02:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAD6E8k0mxpk for ; Thu, 23 May 2013 02:20:43 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6C40021F93DC for ; Thu, 23 May 2013 02:20:43 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id l11so1598115qcy.23 for ; Thu, 23 May 2013 02:20:42 -0700 (PDT) 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=WslwLdRYyQioaPJK3gKed/2Me4iQlkGtMQraenYRHO0=; b=BV3DefthrvsKBk6TWqrkTvedPZJy2qVUxnzTWhWtBCy0AxmWPUMVi15IEC0vdlOapC 39en1p2McK6TZA7KEVxztwXEAvPViMd7SG0McQ9qiQsaaI3hZ7zWGYG6MhAVv2WjLQvq ps5h1vAYKiCKwBPmURfJyJup1Bywr1ltvLYKEaKUWpdSUmj9HmSc7F/f0xS6AggQ4+sD EogeJ+KW4K8jQGaFXFAnBwRRfIBHtSTQLvEVXavR0DtVPRJ+Czx23663sdJnz7CkvoE8 Jsg+Ry0wqSP09XdN0YUTYNmrRSS5mbPJIvN5h3u3dayTaWDn8G0YoCrGrzt0Agj+MWMY p45Q== MIME-Version: 1.0 X-Received: by 10.224.136.194 with SMTP id s2mr10690545qat.97.1369300842897; Thu, 23 May 2013 02:20:42 -0700 (PDT) Received: by 10.49.25.14 with HTTP; Thu, 23 May 2013 02:20:42 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36EC5C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se> <518D6E48.5060700@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36EC5C@ESESSMB209.ericsson.se> Date: Thu, 23 May 2013 02:20:42 -0700 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2d8e255017c04dd5f321d Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:20:44 -0000 --001a11c2d8e255017c04dd5f321d Content-Type: text/plain; charset=ISO-8859-1 Hello Christer Sorry for the delayed response. I do support Alt-1 in the cases when the Offerer doesnot know of Answerer;s BUNDLE support. and Alt-3 in the case, when Both the parties can support BUNDLE but Answerer wants to change the offered configuration for a reason specific to it. In which case, the Answerer should take the lead on setting up the new offer to let its intention known. Thanks Suhas On Mon, May 13, 2013 at 12:44 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Ok, so the outcome seems to be that we allow Alt 1 as long as the rejected > m- lines in the offer contains unique port numbers. > > Regards, > > Christer > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Martin Thomson > Sent: 11. toukokuuta 2013 1:14 > To: Paul Kyzivat > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle > > On 10 May 2013 15:01, Paul Kyzivat wrote: > > Alt 1 is better in cases when you can use it. Alt 3 should work when > > Alt 1 won't. I envision no cases when Alt 2 is useful, but I see no > > reason to ban it. > > I agree. A good summary. > _______________________________________________ > 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 > --001a11c2d8e255017c04dd5f321d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Christer
=A0 Sorry for the delayed response.

=
=A0 =A0I do support Alt-1 in the cases when the Offerer doesnot know o= f Answerer;s BUNDLE support.
=A0 and
=A0Alt-3 in the ca= se, when Both the parties can support BUNDLE but Answerer wants to change t= he offered configuration for a reason specific to it. In which case, the An= swerer should take the lead on setting up the new offer to let its intentio= n known.

Thanks
Suhas=A0

On Mon, May 13, 2013 at 12:44 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

Ok, so the outcome seems to be that we allow Alt 1 as long as the rejected = m- lines in the offer contains unique port numbers.

Regards,

Christer

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.or= g] On Behalf Of Martin Thomson
Sent: 11. toukokuuta 2013 1:14
To: Paul Kyzivat
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle

On 10 May 2013 15:01, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> Alt 1 is better in cases when you can use it. Alt 3 should work when > Alt 1 won't. I envision no cases when Alt 2 is useful, but I see n= o
> reason to ban it.

I agree. =A0A good summary.
_______________________________________________
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

--001a11c2d8e255017c04dd5f321d-- From magnus.westerlund@ericsson.com Thu May 23 02:38:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF4F21F96D3 for ; Thu, 23 May 2013 02:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.729 X-Spam-Level: X-Spam-Status: No, score=-104.729 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDQs5R2sjtoT for ; Thu, 23 May 2013 02:38:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3421F96D2 for ; Thu, 23 May 2013 02:38:00 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-20-519de375faa6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 08.56.31782.573ED915; Thu, 23 May 2013 11:37:57 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Thu, 23 May 2013 11:37:57 +0200 Message-ID: <519DE375.7010309@ericsson.com> Date: Thu, 23 May 2013 11:37:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= References: <518BB81A.8090608@cisco.com> <51965190.10900@ericsson.com> In-Reply-To: <51965190.10900@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+JvrW7p47mBBqfX6lrc7X3BZDF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj2mWJglUSFW9PnGdsYLwg1MXIySEhYCIx 9dEsRghbTOLCvfVsXYxcHEICpxglOjesZIdwljNKfLo2mwmkildAW2Lyu8tgNouAqsSeh7/A utkELCRu/mhkA7FFBYIljmzfzAJRLyhxcuYTMFtEwFZiztW17CA2s0CoxJ+La8DqhQX8JPoO 7QSbKSTgJvFp03uwek4BLYkPT9vYIK6TlNjyoh2qV09iytUWRghbXqJ562xmiF5tiYamDtYJ jEKzkKyehaRlFpKWBYzMqxjZcxMzc9LLjTYxAkP14JbfqjsY75wTOcQozcGiJM7bqz01UEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjrPVM/2Oy19ocDAt8+bHxm32nDWtoUvuNlQe3sTY+ FYuw77PxNflwv9b7Z1HwRf4nCmuYzzF8+N3+an5uREN4+VfH7yYODA69Qd0ZLhVx95tZqh/p XJKPcyq8b3tv3V7fb8Gur8W/CtZN2LBpNleZbe9BFakb/15cETuqvfeJSsJ1W4HtQq1KLMUZ iYZazEXFiQCTZZgxIwIAAA== Cc: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:38:06 -0000 Thanks Ari, I will try to role a new version within the next few days addressing your comments. If there are any issues in implementing them I will come back with such discussion. Cheers Magnus On 2013-05-17 17:49, Ari Keränen wrote: > Hi, > > I had a quick read over the draft and have a few comments: > > 3. Requirements on NAT-Traversal > > 1. Must work for all flavors of NATs, including NATs with address > and port restricted filtering. > > The term used by RFC 4787 is "Address and Port-Dependent Filtering" > > > 3. Requirements on NAT-Traversal > > The list of feature requirements for RTSP NAT solutions are given > below: > > I guess this should say "RTSP NAT traversal solutions". > > > * Address discovery for NAT traversal should take automatically, > if possible > > I assume this means the discovery of the address assigned by the NAT? > Maybe say that explicitly, e.g., "Discovery of the address(es) assigned > by NAT should happen automatically if possible". > > > 4.7.4. Security Considerations > > An ALG will not work whit deployment of end-to-end RTSP signaling > > Typo: whit > > > 4.9.1. [TURN] Introduction > > On the external side this is > limited to the source address/port pair of the first packet arriving > on the binding. After the first packet has arrived the mapping is > "locked down" to that address. Packets from any other source on this > address will be discarded. > > This doesn't sound right. This behavior was changed (eventually into > using permissions) somewhere back in draft-rosenberg-midcom-turn-06. See > http://tools.ietf.org/html/rfc5766#section-2.3 for up-to-date behavior. > Check also steps 5 & 7 in the next section and section 4.9.4 for more > lock down text. > > > 6. Comparison of NAT traversal techniques > > C2: How Robust is the solution to changing NAT behaviors > > Since the answer is yes/no, maybe this should be "is the solution > robust..." > > > 10. Informative References > > [STUN-IMPL] > "Open Source STUN Server and Client, http:// > www.vovida.org/applications/downloads/stun/index.html", > June 2007. > > This site seems to be unavailable nowadays. Better reference would be > "http://sourceforge.net/projects/stun/". And of course, there are plenty > of other open source STUN implementations, but likewise there are for > ICE (PJNATH, libnice, ice4j, etc.) if we want to use that as an argument. > > > Cheers, > Ari (as individual) > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From christer.holmberg@ericsson.com Thu May 23 03:13:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3570121F96B4 for ; Thu, 23 May 2013 03:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoJtsGbcfx9N for ; Thu, 23 May 2013 03:13:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2E521E804A for ; Thu, 23 May 2013 03:13:19 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-1c-519debbe8b3a Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D0.56.28930.EBBED915; Thu, 23 May 2013 12:13:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Thu, 23 May 2013 12:13:17 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , Justin Uberti Thread-Topic: [MMUSIC] Bundle offer with different ports - where to expect media? Thread-Index: AQHOVWQYFllMQWcPdEapMYgKF+xnpZkOHfyA///oz4CAAATTgIABJz4AgACaOACAAE6KAIAADiMAgABcnwCAAJViAIAABFwAgACSgQCAAAedgIAAktnQgABDxqA= Date: Thu, 23 May 2013 10:13:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C376AB5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> <519D5349.2030202@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C37656C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37656C@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre6+13MDDe4cFrfYOlXIYuryxywW KzYcYHVg9vj7/gOTx4JNpR5LlvxkCmCO4rJJSc3JLEst0rdL4MpY2XuUreCgWsWzGTdZGxhb pbsYOTkkBEwkFl9/yQphi0lcuLeerYuRi0NI4DCjROOV6UwQzhJGiZ2LH7F0MXJwsAlYSHT/ 0wZpEBFoYpRoOsQGYjMLyEjMONvIBGILCwRJbF29hBmiJlii/80DRpA5IgJdQPXrf7OAJFgE VCUOtX5gBZnJK+ArcfmxIcSu8xwSK148ZQKJcwr4SXy8WwpSzgh03PdTa5ggdolL3Hoynwni aAGJJXvOM0PYohIvH/8DGykhoCixvF8OolxHYsHuT1BnakssW/garJxXQFDi5MwnLBMYxWYh mToLScssJC2zkLQsYGRZxciem5iZk15uuIkRGDEHt/zW3cF46pzIIUZpDhYlcd5e7amBQgLp iSWp2ampBalF8UWlOanFhxiZODilGhglvCSyvj1JtU/Mf8147L3JM4VF68/NLqn/fn3PJ1vV zxvS63/numYejrrppS1Xuu/usbf97LdcJu2recB79tiCM4qL7x28cPSLrt70m4Kmcgd2uZfa Pn24Zq0zf3wnj8WxEE3DZDvF6O8+22+fcJnf6pz8pDhFMH6x44y4RzLb6h/zNF7IS41QYinO SDTUYi4qTgQAxcdZqWYCAAA= Cc: mmusic Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 10:13:27 -0000 Hi, >>> I think we could do this using the existing syntax, e.g. >>> >>> an offer of a=3Dgroup:BUNDLE A B C would indicate that the offerer=20 >>> would prefer A, B, and C to be muxed onto A, and an answer of=20 >>> a=3Dgroup:BUNDLE C A would indicate that the answerer is going to mux C= =20 >>> and A onto C, and send B unbundled. >> >> That would work. I don't have an objection to it. >> But I'm also ok with choosing based on static ordering of m-lines. > > There are different ways an offerer can tell the remote bundle endpoint o= n which port it prefers to receive media. > > But, again, if there is an intermediary that doesn't understand bundle, i= t will send according to the ports indicated in the m=3D lines. > > The way we solve that is by sending the second offer, with identical port= numbers. So, the sooner we send that second offer, the sooner we get rid o= f the problem about where to send the media :) Actually, correcting myself. The intermediary will of course forward media only towards the bundle port = (however it is indicated), as the answerer is only sending towards that por= t. The problem is that the intermediary may trigger error events when it detec= ts media types etc not negotiated for that port. So, for THAT reason the se= cond offer needs to be sent asap :) Regards, Christer > > wrote: > > Would it make it simpler if the offer included an attribute in > bundled m=3D lines that said where to send the media if bundle is > supported by the answerer; and for the answer to include an > attribute that said where it was going to send the media (ie. to the > bundled destination or the unbundled destination) > > > On 22 May 2013 14:55, Paul Kyzivat > wrote: > > On 5/22/13 1:00 AM, Justin Uberti wrote: > > Taking into account Emil's suggestion as well, this leads to > this > restatement of the rules: > > 1.1) An offerer must be prepared to receive unbundled > traffic on the > offered ports, as if talking to a legacy endpoint. > 1.2) An offerer must be prepared to receive bundled traffic > on any port, > except the port associated with the last m=3D line. > 2) Once the answer is received, the decision on > bundled/unbundled and > which ports to use is finalized. > 2.1) BUNDLEd m=3D lines use the port of the m=3D line that > appears first in > the bundle. > 2.2) Unused ports can be discarded at this point. > 3.1) m=3D lines offered with distinct ports may be omitted > from the bundle > answer, in line with RFC 5888. > 3.2) m=3D lines offered with the same port may not be omitted > from the > bundle answer, since there is no unbundled port from them to > fall back to. > 3.3) m=3D lines that are rejected are omitted from the bundle > answer, per > RFC 5888. > > Quick check on 2.1: are we using the m=3D line that appears > first in the > SDP, or the m=3D line that appears first in the a=3Dgroup:BUN= DLE? > > > IMO it would be best to use the lexically first m-line that has > a non-zero port and that appears in the bundle group of the answe= r. > > Alternately, it *could* be the m-line with non-zero port that > appears first in the bundle group of the answer. But if so, the > exception in 1.2 would also need to be correspondingly adjusted. > > AFAICT the only reason to mention that exception in 1.2 is that > might provide an opportunity for optimization, by setting up the > port with simpler code that doesn't support bundling. I don't > see a requirement in 5888 that the bundle group in the answer be > ordered the same way as in the offer. So the one m-line > guaranteed not to receive bundled traffic would then not be > predictable at the time of the offer, so could not be exploited. > This problem doesn't exist if the lexical ordering of m-lines is > used. > > Thanks, > Paul > > > _________________________________________________ > 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 emil@sip-communicator.org Thu May 23 03:38:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8155221F9121 for ; Thu, 23 May 2013 03:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbRMubnLCKSR for ; Thu, 23 May 2013 03:38:24 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8265721F8E93 for ; Thu, 23 May 2013 03:38:24 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id mx1so1704683bkb.40 for ; Thu, 23 May 2013 03:38:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=e3FH+FwFO7dqr33sblYJByaL+ehQTIesW3HogXIxqS8=; b=Z07om9BUkuZERh8JxOwEaQ92DvRNAw0AwSjSlWx0cs+TGFSuf2fY/V4sdN68FpKn3t fG87OAv1jGjvm4L/E/kMOJIjM4X6xpFNu+n5exjzEK2N/IrbcgQI6Fe3Oen/I4GCrpYV 6xg930ixwVDYy3C7VEj3CfUZpcP2vpfKGY3O9vHQpld8viW3sVHZEKJSkrf/i2s6X66l tTMazBHg2RpoRGF3ZHY/vQP9u2eSt0xcl45KPtyQrsHLZcApflHemV4vw5v6fBJgnl/g nr452yJJEMxln/kKtHCo7M5BOE7rk+CscQ4djipUsrSXwjTseD4XE16M6JgCS+dqGUDm /aIA== X-Received: by 10.205.35.136 with SMTP id sw8mr6126486bkb.127.1369305503248; Thu, 23 May 2013 03:38:23 -0700 (PDT) Received: from [192.168.43.3] ([212.5.158.4]) by mx.google.com with ESMTPSA id tl1sm3074245bkb.7.2013.05.23.03.36.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 03:38:22 -0700 (PDT) Message-ID: <519DF0F8.1070407@jitsi.org> Date: Thu, 23 May 2013 13:35:36 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> In-Reply-To: <519BB598.1030909@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm0uleK5sSv+wGLofJp1UVl4Z8cF6AMsod/ctzLp6wnvjK7Km3e1e3NxTscTAtMcAkPDGY+ Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 10:38:25 -0000 Hey all, Paul, One more thought on the use of the port in the first accepted line rather than the first offered. As is often the case, the discussion on the list is delightfully confusing so apologies if this was already mentioned and I missed it: On 21.05.13, 20:57, Paul Kyzivat wrote: >> > Still, I think being consistent about the ports where one could get >> > multiplexed data is a good thing, and it could help (humans) when >> > analysing traffic and debugging network issues. > Consistency is good. But isn't it just as consistent to say that the > first *accepted* m-line defines the bundle addr/port as it is to say > that the first offered m-line? In case a bundle offer gets forked and various answers accept the bundle but reject different m= lines, then we could end up with receiving bundled traffic on any port. In this case consistently using the first offered port as the one for the bundle would give us use of a single port. I agree this is not necessarily a big deal but I thought I'd mention it just the same. Cheers, Emil -- https://jitsi.org From christer.holmberg@ericsson.com Thu May 23 06:15:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFEB21F91B2 for ; Thu, 23 May 2013 06:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrScs9TrWKhb for ; Thu, 23 May 2013 06:15:47 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 445DC21F90CC for ; Thu, 23 May 2013 06:15:46 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-15-519e16816f85 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FD.8B.31782.1861E915; Thu, 23 May 2013 15:15:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Thu, 23 May 2013 15:15:44 +0200 From: Christer Holmberg To: Justin Uberti , Kevin Dempsey Thread-Topic: [MMUSIC] Bundle offer with different ports - where to expect media? Thread-Index: AQHOVWQYFllMQWcPdEapMYgKF+xnpZkOHfyA///oz4CAAATTgIABJz4AgACaOACAAE6KAIAADiMAgABcnwCAAJViAIAABFwAgACSgQCAARDl0A== Date: Thu, 23 May 2013 13:15:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C376D01@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+JvrW6j2LxAg2P/VSy2ThWyuDn/LYvF 1OWPWSxWbDjA6sDi8ff9ByaPnbPusnss2FTqsWTJT6YAligum5TUnMyy1CJ9uwSujLfdS9gK FrBXbDs5kb2BsYO9i5GTQ0LAROL17D4oW0ziwr31bF2MXBxCAocZJU7s6GKFcJYwSmzr/cXU xcjBwSZgIdH9TxukQUQgSGLCobmsIDazgJPEta6XzCC2MFB86+olzBA1wRL9bx4wQth1Eutm vQezWQRUJSae/8cGYvMK+EqceT4BLC4kcJZD4supNBCbUyBQ4mD7QbA4I9Bx30+tYYLYJS5x 68l8JoijBSSW7DnPDGGLSrx8/I8V5EwJAUWJ5f1yICazgKbE+l36EJ2KElO6H7JDbBWUODnz CcsERrFZSIbOQuiYhaRjFpKOBYwsqxjZcxMzc9LLjTYxAiPo4JbfqjsY75wTOcQozcGiJM7b qz01UEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjJO3gRN03d1SU254Y/1O8Jnvd6l+wwtzl GSemLwqbvsv+oL5kwaw9NrxnDsRqlHpKKb5pn/mM9+ErbhM9KdaJ0q/e/HLWCYw+tOjd8Zml IvWrPgm7RX/7/exgzXeOnI9rFxlxG9xfZHRYZto1i+JdnKG/ErguyJm6XRRu8N2zqPtZcOGM wnwOJZbijERDLeai4kQAQ+4g5m4CAAA= Cc: mmusic , Paul Kyzivat Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 13:15:54 -0000 SGksDQoNCj5JIHRoaW5rIHdlIGNvdWxkIGRvIHRoaXMgdXNpbmcgdGhlIGV4aXN0aW5nIHN5bnRh eCwgZS5nLsKgDQo+DQo+YW4gb2ZmZXIgb2YgYT1ncm91cDpCVU5ETEUgQSBCIEMgd291bGQgaW5k aWNhdGUgdGhhdCB0aGUgb2ZmZXJlciB3b3VsZCBwcmVmZXIgQSwgQiwgYW5kIEMgdG8gYmUgbXV4 ZWQgb250byBBLCBhbmTCoA0KPmFuIGFuc3dlciBvZiBhPWdyb3VwOkJVTkRMRSBDIEEgd291bGQg aW5kaWNhdGUgdGhhdCB0aGUgYW5zd2VyZXIgaXMgZ29pbmcgdG8gbXV4IEMgYW5kIEEgb250byBD LCBhbmQgc2VuZCBCIHVuYnVuZGxlZC4NCg0KSW4gZ2VuZXJhbCwgaXMgdGhlcmUgYXJlIHJlYXNv biB3aHkgd2Ugd291bGQgd2FudCB0byBhbGxvdyB0aGUgYW5zd2VyZXIgdG8gdXNlIGEgc2VwYXJh dGUgcG9ydCB0aGFuIHRoZSBvbmUgaW5kaWNhdGVkIGJ5IHRoZSBvZmZlcmVyPyBUaGVyZSBtYXkg YmUgcmVhc29ucyB3aHkgdGhlIG9mZmVyZXIgaGFzIGNob3NlbiB0aGF0IHNwZWNpZmljIHBvcnQu DQoNCkFsc28sIEkgdGhpbmsgaXQgaXMgc2VtYW50aWNhbGx5IHdyb25nIHRvIGRvIGFzIHlvdSBz dWdnZXN0LCBhcyB5b3Ugd291bGQgdXNlIHRoZSBncm91cCBhdHRyaWJ1dGUgdG8gaW5kaWNhdGUg YSBTRU5ESU5HIGNhcGFiaWxpdHkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From fluffy@cisco.com Thu May 23 06:19:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DCB21F93D1 for ; Thu, 23 May 2013 06:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.424 X-Spam-Level: X-Spam-Status: No, score=-110.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbGRsa58GkEr for ; Thu, 23 May 2013 06:19:23 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D591F21F9420 for ; Thu, 23 May 2013 06:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=511; q=dns/txt; s=iport; t=1369315163; x=1370524763; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QhDeZhfnWXM51V3riap5aYEBRuJAzet300ch9HeEfXo=; b=BvwKOxJEAy/4OGCecaOc1BgJYvRI3YYU1nswBglcy2vMSjMqJlgY57n+ hlr5zqv9bujrZoMn7nHPZPpPYsrRDXRMEFDn0KuvoSsok6xEGRc8GcZIi gYca70IcKJsOQhDIPpHbUqli1nWhxq6slN0mfnuwdw9t78x7RWvt3RcKe 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFABwXnlGtJV2b/2dsb2JhbABagwiDJL83gQoWdIIjAQEBAwFrDgULAgEIIiQyJQIEDgUIh38GulqOagIxB4JzYQOIZ6ARgw+CJg X-IronPort-AV: E=Sophos;i="4.87,728,1363132800"; d="scan'208";a="214077220" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 23 May 2013 13:19:23 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4NDJNEX021582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 13:19:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 23 May 2013 08:19:22 -0500 From: "Cullen Jennings (fluffy)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] Reply to Liaison statement to IETF concerning 3D video Thread-Index: AQHOV7gjAFkj0SFtC0mjxtIYwciMJA== Date: Thu, 23 May 2013 13:19:00 +0000 Message-ID: References: <51953A56.1070505@ericsson.com> <519D416F.8080105@ericsson.com> In-Reply-To: <519D416F.8080105@ericsson.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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , mmusic Subject: Re: [MMUSIC] Reply to Liaison statement to IETF concerning 3D video X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 13:19:29 -0000 I talked to more people about this after I sent my email and the more I tal= ked to people, the more I thought your original proposal was just fine.=20 On May 22, 2013, at 4:06 PM, Ari Ker=E4nen wrote= : > Hi Cullen, >=20 > Thanks for your feedback. We already mention in the reply draft that we w= elcome more input on the matter but having also domain experts could be hel= pful. We'll take also this into consideration for the reply. >=20 >=20 > Cheers, > Ari From fluffy@cisco.com Thu May 23 06:42:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4436F11E80E9 for ; Thu, 23 May 2013 06:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.382 X-Spam-Level: X-Spam-Status: No, score=-110.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRvH7zornJws for ; Thu, 23 May 2013 06:42:19 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9428321F9501 for ; Thu, 23 May 2013 06:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1719; q=dns/txt; s=iport; t=1369316539; x=1370526139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oqTyaEwIsS0EYXeDXjX79KHSHeN9Al/5435ddsHSixc=; b=DpWTFQECviI6iD99gOpv9CtJYnGGSiCxrUCaGGRb9SfTodDGYayCsHPU 0ET9cFnujYZZH5SxS2rpuBt8IYfRcq1uEcHP10cyUkxBUErO8c9AREYW7 htS3ID4LJzABe7gQuI0opS9PHfo/dXBnLwN6ltOdvMMa3uuTndqX2MxuH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABccnlGtJXG8/2dsb2JhbABagwjCW4EKFnSCIwEBAQMBOj8FCwIBCA4UFBAyJQIEDgUIh38GulmNW4EPAjEHgnNhA6h4gw+BcTU X-IronPort-AV: E=Sophos;i="4.87,728,1363132800"; d="scan'208";a="211144608" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 23 May 2013 13:42:19 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4NDgJrM031490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 13:42:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 23 May 2013 08:42:18 -0500 From: "Cullen Jennings (fluffy)" To: Justin Uberti Thread-Topic: [MMUSIC] Bundle offer with different ports - where to expect media? Thread-Index: AQHOV7tXnw9Y3/7qwkiw+0gqKiqo3A== Date: Thu, 23 May 2013 13:41:55 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@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: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <800A12B2E8F16D48A8C1129B92E65969@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 13:42:25 -0000 On May 21, 2013, at 11:00 PM, Justin Uberti wrote: >=20 > 1.1) An offerer must be prepared to receive unbundled traffic on the offe= red ports, as if talking to a legacy endpoint. > 1.2) An offerer must be prepared to receive bundled traffic on any port, = except the port associated with the last m=3D line. I'm fine with this but would be just as happy without the "except last one" > 2) Once the answer is received, the decision on bundled/unbundled and whi= ch ports to use is finalized. Yes, as long as we keen final answer. For provisional answer you need to no= t free the resources. Yes, I expect to get emails from folks telling me tha= t provisioning and final aren't defined but you know what I mean and this i= s the clearest way to say it for this email.=20 > 2.1) BUNDLEd m=3D lines use the port of the m=3D line that appears first = in the bundle. Again, we could go this way or the using the group syntax to do=20 > 2.2) Unused ports can be discarded at this point. > 3.1) m=3D lines offered with distinct ports may be omitted from the bundl= e answer, in line with RFC 5888. yes, I would change "bundle answer" to "bundle group in the answer"=20 =20 > 3.2) m=3D lines offered with the same port may not be omitted from the bu= ndle answer, since there is no unbundled port from them to fall back to. uh, no, not on aboard with this part. As we have discussed many times, havi= ng multiple m line in the original offer with the same port won't work. I t= hink EKR's proposal of allowing m-lines with 0 port in offer will work well= .=20 > 3.3) m=3D lines that are rejected are omitted from the bundle answer, per= RFC 5888. >=20 From fluffy@cisco.com Thu May 23 06:42:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6DE21F9501 for ; Thu, 23 May 2013 06:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBWneA7bdbsF for ; Thu, 23 May 2013 06:42:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B2B1121F9512 for ; Thu, 23 May 2013 06:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=617; q=dns/txt; s=iport; t=1369316540; x=1370526140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YA6ULa5IcJ+9dqu+A8LNDNDLoBI4NzaRdn6O1HspxC8=; b=APynPxe5YKcWd/lYD5siQbS6V40uxwcQRhOSgr6i/8Wqi+vPWiUqmMNC yZ1TPb5Al6qk+/a8g8lVwOxlp3bYdFCqhcLoDWGLcXYjE467B/YPpecrp C+S27OLzxAAoLaKFbfeRflcXFt4qnXRx14l4dqsgbpwNsw7uqagJDtM+M M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFACMbnlGtJV2c/2dsb2JhbABagwiDJL83gQoWdIIjAQEBAwE6PwULAgEIDhQUEDIlAgQOBQiHfwa6WY5qAjEHgnNhA6h4gw+CJg X-IronPort-AV: E=Sophos;i="4.87,728,1363132800"; d="scan'208";a="214126739" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 23 May 2013 13:42:20 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4NDgKrQ010504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 13:42:20 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 23 May 2013 08:42:19 -0500 From: "Cullen Jennings (fluffy)" To: Justin Uberti Thread-Topic: [MMUSIC] Bundle offer with different ports - where to expect media? Thread-Index: AQHOV7tYcnKGA1yNPkulAJ9ywf0gBw== Date: Thu, 23 May 2013 13:41:56 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@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: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 13:42:27 -0000 On May 22, 2013, at 4:55 PM, Justin Uberti wrote: > I think we could do this using the existing syntax, e.g.=20 >=20 > an offer of a=3Dgroup:BUNDLE A B C would indicate that the offerer would = prefer A, B, and C to be muxed onto A, and=20 > an answer of a=3Dgroup:BUNDLE C A would indicate that the answerer is goi= ng to mux C and A onto C, and send B unbundled. >=20 I suspect several people are on the fence about using this approach or the = first non rejected m-line in the bundle.=20 Can anyone think of reasons why to pick one of the other of these two appro= aches ? From magnus.westerlund@ericsson.com Thu May 23 07:47:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EAE21F8A6B for ; Thu, 23 May 2013 07:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.117 X-Spam-Level: X-Spam-Status: No, score=-105.117 tagged_above=-999 required=5 tests=[AWL=0.832, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykvBZwx8iW1z for ; Thu, 23 May 2013 07:47:23 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9E721F8CA5 for ; Thu, 23 May 2013 07:47:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-51-519e2bf8c7ff Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A2.14.28930.8FB2E915; Thu, 23 May 2013 16:47:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Thu, 23 May 2013 16:47:20 +0200 Message-ID: <519E2BF8.7040500@ericsson.com> Date: Thu, 23 May 2013 16:47:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= References: <518BB81A.8090608@cisco.com> <51965190.10900@ericsson.com> In-Reply-To: <51965190.10900@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvre4P7XmBBh1zbCzu9r5gspi6/DGL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJVx5cZz5oJ3PBVzz75jamDcwNXFyMkhIWAi MefJCkYIW0ziwr31bF2MXBxCAqcYJZ5vPc0K4SxnlPj2bz8zSBWvgLbE1xu72UFsFgFVia/r p7KB2GwCFhI3fzSC2aICwRJHtm9mgagXlDg58wmYLSJgKzHn6lqwXmaBUIk/F9eA1QsL+En0 HdrJBGILCbhJfNr0HqyeU0BL4sPTNjaI6yQltrxoh+rVk5hytYURwpaXaN46mxmiV1uioamD dQKj0Cwkq2chaZmFpGUBI/MqRvbcxMyc9HLDTYzAYD245bfuDsZT50QOMUpzsCiJ8/ZqTw0U EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNiZ+MbYKr1mzqtZUz7ub363XdTH1tfw1xX9W3E1 8wIkGNa1Z4T7vqjz3Ft56+BqdfFL0opif9SrW17OFOWSO/Y2XeAfw5SKkJNa9nclWb8rBfUx XDTcLRYcul68tYWPjV+tdI670NSXMaydLCJLWiL61uwWtT/mq9KxiDvkQW3S3eplrQmOSizF GYmGWsxFxYkA9WmLKiQCAAA= Cc: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 14:47:28 -0000 On 2013-05-17 17:49, Ari Keränen wrote: > > > 4.9.1. [TURN] Introduction > > On the external side this is > limited to the source address/port pair of the first packet arriving > on the binding. After the first packet has arrived the mapping is > "locked down" to that address. Packets from any other source on this > address will be discarded. > > This doesn't sound right. This behavior was changed (eventually into > using permissions) somewhere back in draft-rosenberg-midcom-turn-06. See > http://tools.ietf.org/html/rfc5766#section-2.3 for up-to-date behavior. > Check also steps 5 & 7 in the next section and section 4.9.4 for more > lock down text. I changed this to: To prevent DoS attacks on either recipient, the packets forwarded are restricted to the specific source address. On the client side it is restricted to the source setting up the allocation. On the external side this is limited to the source address/port pair that have been given permission by the TURN client creating the allocation. Packets from any other source on this address will be discarded. I will shortly submit an updated draft. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Thu May 23 07:53:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEF521F96B7; Thu, 23 May 2013 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6hKeIFCuW0O; Thu, 23 May 2013 07:53:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 879DB21F96AB; Thu, 23 May 2013 07:53:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523145333.21950.32598.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 07:53:33 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 14:53:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : The Evaluation of Different Network Address Translator (= NAT) Traversal Techniques for Media Controlled by Real-time Streaming Proto= col (RTSP) Author(s) : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-07.txt Pages : 40 Date : 2013-05-23 Abstract: This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description on 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 relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0. 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-evaluation-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Thu May 23 10:46:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B21921F8B16 for ; Thu, 23 May 2013 10:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2Pb5-RyZiiR for ; Thu, 23 May 2013 10:46:32 -0700 (PDT) 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 E6BB921F8FDC for ; Thu, 23 May 2013 10:34:06 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id fPz81l0060QuhwU5DVa5AL; Thu, 23 May 2013 17:34:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id fVa51l00a3ZTu2S3NVa5UR; Thu, 23 May 2013 17:34:05 +0000 Message-ID: <519E530C.60705@alum.mit.edu> Date: Thu, 23 May 2013 13:34:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> In-Reply-To: <519DF0F8.1070407@jitsi.org> 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=1369330445; bh=A7+EJFTfcJ+Qo3rU1AjEVhyx1eL/URu6syuu1Yf82mM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DszQTvoiduoL1VP9tZGj4tYfuzsy4fbRhFPIxLrIgQH+xuFiAfXuvqnMF+dGRlmrP FS1sN0D7AKGWhVHKVdfRi8e2yL7VAG7iUSQeOTsaKDpYqfCndAtZmsIZcDWg3XvpbM gAd4YVKnpQVlfZYczvE0BTOO9fu1mN3BHXia23aDrHLKZ8J6Meej7s8r/+jE4VWQ6A 7uw9cJz5ZR3r2vc4MEXTMY0KIGdrbxRIoG/zoajOkb/jy4+qmNC1hXXFYk4+9OIQll w/9TVxDRYrYMkM00a1dsretqz3+G9xQQS677/pLAzwCTssHYak0lrbTmWav1NNsh8Y 23rDMXnQSIKdg== Cc: mmusic , Christer Holmberg Subject: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 17:46:47 -0000 On 5/23/13 6:35 AM, Emil Ivov wrote: > In case a bundle offer gets forked and various answers ... I trimmed everything else out of Emil's reply, and changed to subject, because this is a whole different can of worms! I think we must acknowledge that this *can* happen, though it is a low probability event. It raises all sorts of ugly issues. A few: * if the bundle is accepted by multiple forks, does this form one RTP session or several? If so, - if so, then if each fork accepts a different set of m-lines from the bundle, how can that work with a single RTP session? * How does ICE work in this case? (Is that already covered by ICE, since it mostly isn't specific to bundle? * If one fork adds/removes an m-line from the bundle, should that be mirrored to the other forks? * ... ISTM that the simplest thing we could do about this is put a statement in the draft that this draft does not specify behavior in the case of forking - that conforming devices are constrained to a single fork, and that behavior in forking cases could be a subject of future standardization. Thanks, Paul From ari.keranen@ericsson.com Thu May 23 11:17:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1138121F96ED for ; Thu, 23 May 2013 11:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLBJm3VSuige for ; Thu, 23 May 2013 11:16:53 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CAEBC21F95E4 for ; Thu, 23 May 2013 10:58:43 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-ad-519e58d27f98 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 52.28.28930.2D85E915; Thu, 23 May 2013 19:58:42 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 23 May 2013 19:58:42 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DD364237A; Thu, 23 May 2013 20:58:41 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 89B15550E0; Thu, 23 May 2013 20:58:40 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 220CA55098; Thu, 23 May 2013 20:58:40 +0300 (EEST) Message-ID: <519E58D1.6080600@ericsson.com> Date: Thu, 23 May 2013 20:58:41 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Magnus Westerlund References: <518BB81A.8090608@cisco.com> <51965190.10900@ericsson.com> <519E2BF8.7040500@ericsson.com> In-Reply-To: <519E2BF8.7040500@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvre6liHmBBjeeaVrc7X3BZDF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj6eYfTAUTuCv+71jK3sD4nKOLkZNDQsBE Ytr1JUwQtpjEhXvr2UBsIYFTjBJtK5S7GLmA7A2MEsfun2OESOxmlLjwOAQisY5RYuqyRUwQ iRWMEh07rEBsXgFtiZcfusEmsQioSlxY9A6shk3AXuLmhOvsILaoQLLE5KkrWCDqBSVOznwC ZosImEk8nLAfrJdZIFTiz8U1YLawgJ9E36GdULvSJHbOPMQKYnMK6EgcXnqbEaLeVuLCnOss ELa8RPPW2cwQn6lJXD23iRmiV1Xi6r9XjBMYRWchWT0LSfssJO0LGJlXMbLnJmbmpJcbbmIE Bv3BLb91dzCeOidyiFGag0VJnLdXe2qgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkY17oBf 4e6Pn+w2sJixtN9FdnLd5xfut54cVflopSPFOC3vff/sK1MOdh9nerzB5toE78zQCyrFU1Ln zty+ou+yjoTObIUWi/Pvjl9ysXsYVbtocd7f2W/7ud7b35hx6czH/z0Jx0V0F5ZJhXfLyq1+ Gvz0//vHS+dtWMm3R8+myPF8ThD7fb9VSizFGYmGWsxFxYkA3EpJ9EgCAAA= Cc: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 18:17:08 -0000 On 5/23/13 5:47 PM, Magnus Westerlund wrote: > On 2013-05-17 17:49, Ari Keränen wrote: > >> >> >> 4.9.1. [TURN] Introduction >> >> On the external side this is >> limited to the source address/port pair of the first packet arriving >> on the binding. After the first packet has arrived the mapping is >> "locked down" to that address. Packets from any other source on this >> address will be discarded. >> >> This doesn't sound right. This behavior was changed (eventually into >> using permissions) somewhere back in draft-rosenberg-midcom-turn-06. See >> http://tools.ietf.org/html/rfc5766#section-2.3 for up-to-date behavior. >> Check also steps 5 & 7 in the next section and section 4.9.4 for more >> lock down text. > > I changed this to: > > To prevent DoS attacks on either recipient, the packets forwarded are > restricted to the specific source address. On the client side it is > restricted to the source setting up the allocation. On the external side > this is limited to the source address/port pair that have been given > permission by the TURN client creating the allocation. Packets from any > other source on this address will be discarded. > > I will shortly submit an updated draft. Looks good to me. However, also the following sections had some "lock down" text that should be updated (see details on my original mail above). Cheers, Ari From fluffy@cisco.com Thu May 23 11:23:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2DF21F9705 for ; Thu, 23 May 2013 11:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeyOkzmr0WhS for ; Thu, 23 May 2013 11:22:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB5D21F84F5 for ; Thu, 23 May 2013 11:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1325; q=dns/txt; s=iport; t=1369332189; x=1370541789; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=AthhxXYEsBoryLBTCsniJrHAXitOqW0PmYiDDuUecDU=; b=EXL+ykmFg4JIJFPFrslpv3sFot9sOhBALJ3PGw3g6P+N6u9S3haDiJUX 9SoxSlSJ82lD8KhI3AMx62ZEXgrEUxZYLT9tJzmbjHeqIAZbSFSDM6Bpl mLmG5faunDSUpjggzDbqvNomVP0JSYlrPMv5GC+sr4TBQ1hlotrXzr9It Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAH1ZnlGtJXG9/2dsb2JhbABZgwjCW4ELFnSCJQEEOlEBKhRCJwQbiAWaEKAujmyDK2EDk2qVEYMPgiY X-IronPort-AV: E=Sophos;i="4.87,729,1363132800"; d="scan'208";a="214263398" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 23 May 2013 18:03:01 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4NI31MY008424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 May 2013 18:03:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 23 May 2013 13:03:00 -0500 From: "Cullen Jennings (fluffy)" To: mmusic WG Thread-Topic: Proposal for what bundle should say about demux Thread-Index: AQHOV9/DVjr8src5NEuGXcSJwmehbA== Date: Thu, 23 May 2013 18:02:37 +0000 Message-ID: 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="us-ascii" Content-ID: <7A7C3CE1291E044884E1E0D0B7101FA4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 18:23:23 -0000 Here's is my proposal for roughly what the bundle draft should say about th= is demux topic=20 Application will decide which packet processing pipeline to pass an given R= TP/RTCP packet to based on what the application knows: 1) If future RFCs define new things (like RTP header extension), that expli= citly specify the mapping, check if that future RFC is in use and if so the= n use that to form the mapping=20 2) If the PT type is uniquely identifies a mapping, use that to form the ma= pping 3) If application knows the SSRC the other side will use, use that to form = the mapping=20 4) if there is no way to know which pipeline to pass it too, the packet MAY= be discarded or the application MAY decide to buffer it until the mapping = is known=20 This is trivial to implement. It meets the requirements for Plan A, Plan B,= UCIF, CLUE, and so on.=20 We could swap the order of step 2 and 3, My thinking for this order was the= only time it made any difference the order was if the PT were unique and i= ndicated a different mapping than the SSRC. The only way this could happen = is with a SSRC collision so the PT is the one that would be correct not the= SSRC. If someone feels strongly the order of steps 2 and 3 should be the o= pposite way around, I can live with that. From partha@parthasarathi.co.in Thu May 23 11:37:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9ED21F8895 for ; Thu, 23 May 2013 11:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIJbLB5LBeS7 for ; Thu, 23 May 2013 11:36:59 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [70.87.28.142]) by ietfa.amsl.com (Postfix) with ESMTP id CC41A21F96E1 for ; Thu, 23 May 2013 11:16:57 -0700 (PDT) Received: from userPC (unknown [122.179.94.120]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 920BD638DEA; Thu, 23 May 2013 18:16:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1369333016; bh=RAFsJWThWeTh4EYNG8SwhEWid4Q3LkCw7g0MMxOmjbg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mNKOt8Byw0v8iHCTozLeMpmyXiv7/GwQ3KyU2YBLC57eDfPFKkVGoqmCoccI++jyJ SFr4361OrOvyHUMnVvg350p1cBEZ+WvnQY+dLTIf2C9cIxqDI/KxKnE0sc7iZAF0gL tn4WiqnyxsfTN2A/QB8GVPDI548aqsBf9gL9M7Ss= From: "Parthasarathi R" To: "'Dale R. Worley'" References: <20130520161935.17435.91264.idtracker@ietfa.amsl.com> <002801ce564b$51e52230$f5af6690$@co.in> <201305230204.r4N247r25245471@shell01.TheWorld.com> In-Reply-To: <201305230204.r4N247r25245471@shell01.TheWorld.com> Date: Thu, 23 May 2013 23:46:41 +0530 Message-ID: <007601ce57e1$b15a5b30$140f1190$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5XWfEoz2m+qfSRQQuBF32v01GLgwAgEOyg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0201.519E5D18.00F2, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: fluffy@cisco.com, mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 18:37:13 -0000 Dale, The current scope of this draft is to add the offer/answer (O/A) consideration to RFC 4856 as it is missing in RFC 4856. The draft provides clarification like "annexb=no" is in the offer whether annexb=yes is allowed by the answerer or not. Your proposal breaks RFC 4856 default value for annexb as the missing annexb parameter in SDP implies that Annexb is supported as per 4856. The reason for the default annexb value as "Yes" instead of "no" is as follows: RFC3551 snippet related to G729 AnnexB: Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registration for G729 in RFC 3555 specifies a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames. If the answerer supports RFC3551, then the answerer has to support RFC3555 for annexb parameter. Annexb value default value is "Yes" in RFC 3555 as per RFC 3551. RFC 4856 obsoletes RFC 3555 without changing "annexb" related requirement. Please let me know any reason that you wish to change AnnexB parameter default value now. Thanks Partha > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Thursday, May 23, 2013 7:34 AM > To: Parthasarathi R > Cc: fluffy@cisco.com; mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729- > 01.txt > > > > From: Cullen Jennings (fluffy) > > > > > > What happens when an endpoint that understands the [annexb] > attribute > > > sends [an] offer to an endpoint that does not understand or > implement > > > the [annexb] attribute ? > > > From: "Parthasarathi R" > > > > As per Sec 2.1.9 RFC 4856, "annexb=no" has to be sent by Answerer in > case > > the answerer does not support G729 AnnexB. The exact RFC snippet is > as > > follows: > > > > "annexb: indicates that Annex B, voice activity detection, is > > used or preferred. Permissible values are "yes" and "no" > > (without the quotes); "yes" is implied if this parameter is > > omitted." > > > > Please let me know whether you wish to explicitly mention in the > draft that > > Answerer *MUST* send "annexb=no". > > No, if the offerer sends "annexb=yes" and the answerer *does not > understand it*, that is, does not support this I-D, the answer will > not contain an annexb parameter. You should make sure the draft > describes how the *offerer* detects this situation and ensures that > the operation of the codec is done as well as possible. > > Dale From partha@parthasarathi.co.in Thu May 23 11:37:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604E721F941D for ; Thu, 23 May 2013 11:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0Q6hLuGIm6u for ; Thu, 23 May 2013 11:37:39 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [70.87.28.142]) by ietfa.amsl.com (Postfix) with ESMTP id 194C421F896D for ; Thu, 23 May 2013 11:17:30 -0700 (PDT) Received: from userPC (unknown [122.179.94.120]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id BE7C4638E16; Thu, 23 May 2013 18:17:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1369333049; bh=dBXNf/zzY7hQHQvbySD647Zoqo3QPY/NmJVCqm8bHEQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=atGxv1n7qc2FASAgS3w+Z5mxDc9jJk3XdlqUdcCFHoHGaMptqOvOLI+mWr/GzCzD8 kuEf6cPCe5BwiPEf4WqPCeNuezDiyKvMXFBPZ0gCZSoz6BcjgwHcHSjOxJvAJ6rdLg u7xc7HSvAi13cbU332JxwGtzRWQws67u3jW/ud5Q= From: "Parthasarathi R" To: "'Paul Kyzivat'" , "'Emil Ivov'" References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> In-Reply-To: <519E530C.60705@alum.mit.edu> Date: Thu, 23 May 2013 23:47:15 +0530 Message-ID: <007801ce57e1$c523a9f0$4f6afdd0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5X3YKNkaUsPeBUTL2j62YyxAU0kwAANcLQ Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.519E5D39.014A, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 2 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: 'mmusic' , 'Christer Holmberg' Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 18:37:52 -0000 Paul, I agree with you that it takes more energy to solve bundle with forking. Forking is not low probability event as of now in SIP deployments. I wish to see the forking within the scope of this work. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, May 23, 2013 11:04 PM > To: Emil Ivov > Cc: mmusic; Christer Holmberg > Subject: [MMUSIC] When a bundle offer is forked > > On 5/23/13 6:35 AM, Emil Ivov wrote: > > > In case a bundle offer gets forked and various answers ... > > I trimmed everything else out of Emil's reply, and changed to subject, > because this is a whole different can of worms! > > I think we must acknowledge that this *can* happen, though it is a low > probability event. It raises all sorts of ugly issues. A few: > > * if the bundle is accepted by multiple forks, does this form > one RTP session or several? If so, > > - if so, then if each fork accepts a different set of m-lines from > the bundle, how can that work with a single RTP session? > > * How does ICE work in this case? (Is that already covered by ICE, > since it mostly isn't specific to bundle? > > * If one fork adds/removes an m-line from the bundle, should that > be mirrored to the other forks? > > * ... > > ISTM that the simplest thing we could do about this is put a statement > in the draft that this draft does not specify behavior in the case of > forking - that conforming devices are constrained to a single fork, and > that behavior in forking cases could be a subject of future > standardization. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Thu May 23 11:50:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B15E21F942D for ; Thu, 23 May 2013 11:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlGKnIK90qaK for ; Thu, 23 May 2013 11:50:15 -0700 (PDT) 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 9803121F9608 for ; Thu, 23 May 2013 11:26:30 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id fQXR1l0051YDfWL5DWSVSL; Thu, 23 May 2013 18:26:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id fWSV1l00c3ZTu2S3gWSVJz; Thu, 23 May 2013 18:26:29 +0000 Message-ID: <519E5F54.3000806@alum.mit.edu> Date: Thu, 23 May 2013 14:26:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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=1369333589; bh=+ybxvzpTN9QDqwDRWv4/EJRu/R2QJN0rsL082EChGvE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YHMRcrWW5KOqoMS7PpRpc/K0QtY2nhwitZZ2Kdvudtd3V3AJz+DLGx2tUPfmE/bXi 1qysYka9VoirUnEZssKMm0s3a7rcm3wSUKa+ln66LBryfFX8Y6cT8MBeMIr+RBAOcQ 41JbWXixg0CLB0HfZ4t6rEpNmWSgIQLLBTnCRLdsncf3AI1ySCx70XpFaMT3CrUF1c ROzGz1ZFiEPCz7MqTSsBA5NvEAHoJh9pYzFEMLTu7rkAAGJR9a3MiyufudYFIX+nJc pbByDBm/xiY5hzmc+nBckokqy0Wmty2q/P/4HTzUaU3l0+x0o4QL++/WmxXQVqR/YS XcWysCa6Y5SSA== Subject: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 18:50:31 -0000 After all the discussion in the meeting today, I thought it would be good to unwind all the indenting and start a new thread on one issue that is part of the "demux" problem: IMO the following should obviously be a truism. I want to know if all agree. If an O/A exchange negotiates a bundle with multiple m-lines, then attributes in those m-lines and the associated media sections must provide sufficient information to associate each incoming packet on the 5-tuple to exactly *one* of those m-lines. (If it doesn't, then there was no point in including those m-lines in the bundle.) For instance a=ssrc, if unique to one m-line, can bind packets with that SSRC to the m-line. If a property such as SSRC is used this way, then there is the possibility of receiving packets that don't match any of the m-lines. I think we ought to address that, by defining some syntax to specify what to do with packets that don't match any m-line. This might be to specify one m-line as the default, or that packets that don't match be discarded. This is not the complete demux problem. Added data and logic may be needed to decide what application processing each of those packets may require. Once a packet has been associated with an m-line, then some of the attributes associated with that m-line may provide may provide further information about how to decide how to process the packet. There can also be information that comes via other means to qualify packet processing. Thanks, Paul From pkyzivat@alum.mit.edu Thu May 23 12:04:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD64121F8FED for ; Thu, 23 May 2013 12:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atDjmIvrIXJH for ; Thu, 23 May 2013 12:04:06 -0700 (PDT) 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 D094C21F9720 for ; Thu, 23 May 2013 11:39:34 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id fQgx1l0031ap0As5DWfaGv; Thu, 23 May 2013 18:39:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id fWfa1l00K3ZTu2S3iWfaRH; Thu, 23 May 2013 18:39:34 +0000 Message-ID: <519E6265.4090102@alum.mit.edu> Date: Thu, 23 May 2013 14:39:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: 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=1369334374; bh=c0ztsFiaVH3qLWdfU+a1WCKr6SJczr5KyrX76Rr+XK4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PpQZB9GPNf8pBuu2Iq+WOFiWCd0hZ7/Ws9RmfhrD+FbQrmjzzElgoFRiNhUkBx50b /eUMSTi2EYZiDeBKSTA0FJ6SdV1N7LBRKhIt95yRrf2pU2GUtMVWgL3n/fh0V87amS 2s/VcROc9ArQDDZECvGnso6lUBLL2mwY6DFR8DhVzIDmB1zmYSWRWgZP/Xq4lJ1iwT PMsI3sX1gysnJK5DLviC1MrdV2zaPc3mRxTHw9RJ+8cA8hh/fCi7JBS0Dl7RJkorJm OvqkM82+jT4KmqSl4JgZsSeHMN1AaPfy/hDTswUPA28/hsLDWT4HQoyfQA+GQRyTPz lj/0x7lIqoSAw== Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:04:20 -0000 Cullen, I just posted a separate, related, message on associating packets to m-lines. IMO they are complementary, and somewhat layered: First, the packet should be matched to the m-line. The m-line then provides an bunch of related info: - mapping from PT to codec - bandwidth info - per-ssrc info - labels that can be bound to application specific data - ... All of that info is then available to help associate the packet to a processing pipeline. Then the algorithms you talk about kick in. Of course that is the hypothetical layering. It is subject to optimization. Generally, once one packet has been bound to a processing pipeline then the SSRC from that can be remembered, and used to shortcut the mapping for future packets that have the same SSRC. Thanks, Paul On 5/23/13 2:02 PM, Cullen Jennings (fluffy) wrote: > > Here's is my proposal for roughly what the bundle draft should say about this demux topic > > Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows: > > 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping > > 2) If the PT type is uniquely identifies a mapping, use that to form the mapping > > 3) If application knows the SSRC the other side will use, use that to form the mapping > > 4) if there is no way to know which pipeline to pass it too, the packet MAY be discarded or the application MAY decide to buffer it until the mapping is known > > This is trivial to implement. It meets the requirements for Plan A, Plan B, UCIF, CLUE, and so on. > > We could swap the order of step 2 and 3, My thinking for this order was the only time it made any difference the order was if the PT were unique and indicated a different mapping than the SSRC. The only way this could happen is with a SSRC collision so the PT is the one that would be correct not the SSRC. If someone feels strongly the order of steps 2 and 3 should be the opposite way around, I can live with that. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Thu May 23 12:08:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E0C21F9737 for ; Thu, 23 May 2013 12:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.292 X-Spam-Level: X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTszHZp9udjr for ; Thu, 23 May 2013 12:08:27 -0700 (PDT) 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 2815A21F8859 for ; Thu, 23 May 2013 11:44:08 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id fUWR1l0020xGWP853Wk81P; Thu, 23 May 2013 18:44:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id fWk71l01d3ZTu2S3YWk7iP; Thu, 23 May 2013 18:44:08 +0000 Message-ID: <519E6376.9020302@alum.mit.edu> Date: Thu, 23 May 2013 14:44:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> <007801ce57e1$c523a9f0$4f6afdd0$@co.in> In-Reply-To: <007801ce57e1$c523a9f0$4f6afdd0$@co.in> 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=1369334648; bh=xsaVdnqYKrXLpomH8lec1GN3wdGwABLMrz4qwq6AA0o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=imaPdQkD2s5Y+wUCHslqz03ojwEaR6IJrqPtG628xEVS8u/3fj+Thxs9hWAjdCe+l o0Hsv+QUd206Jg+u//7TiXvkeXGieWpQ+5mkez06sVMM9HVcIEhEM6H/KIHqCTmDG6 ZXdLfKTqXsFHyxe60WGgh6qH339/aOx79KnZYxaKXZVxgjCrENi9OQuJ6Ttq//Lvn7 0OM9aRVIa9Xe9kPz4XHgEgDZGBB29+2zD9/9f7qXJ2CeICD9vrRscAF8/KmUipNg2H UplyhiwB7Rewzs60N4/vhI21zs3tjx7HK29H423ol5mmUz0hUJBfL3JvcusCXxWSo8 okQ+Z+OCecmBQ== Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:08:42 -0000 Partha, On 5/23/13 2:17 PM, Parthasarathi R wrote: > Paul, > > I agree with you that it takes more energy to solve bundle with forking. > Forking is not low probability event as of now in SIP deployments. I wish to > see the forking within the scope of this work. If so, can you take a stab at enumerating the issues that can arise, and how they should be handled? Thanks, Paul > Thanks > Partha > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Thursday, May 23, 2013 11:04 PM >> To: Emil Ivov >> Cc: mmusic; Christer Holmberg >> Subject: [MMUSIC] When a bundle offer is forked >> >> On 5/23/13 6:35 AM, Emil Ivov wrote: >> >>> In case a bundle offer gets forked and various answers ... >> >> I trimmed everything else out of Emil's reply, and changed to subject, >> because this is a whole different can of worms! >> >> I think we must acknowledge that this *can* happen, though it is a low >> probability event. It raises all sorts of ugly issues. A few: >> >> * if the bundle is accepted by multiple forks, does this form >> one RTP session or several? If so, >> >> - if so, then if each fork accepts a different set of m-lines from >> the bundle, how can that work with a single RTP session? >> >> * How does ICE work in this case? (Is that already covered by ICE, >> since it mostly isn't specific to bundle? >> >> * If one fork adds/removes an m-line from the bundle, should that >> be mirrored to the other forks? >> >> * ... >> >> ISTM that the simplest thing we could do about this is put a statement >> in the draft that this draft does not specify behavior in the case of >> forking - that conforming devices are constrained to a single fork, and >> that behavior in forking cases could be a subject of future >> standardization. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 emil@sip-communicator.org Thu May 23 14:35:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40EB21F95C4 for ; Thu, 23 May 2013 14:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsbYXVVqeEBy for ; Thu, 23 May 2013 14:34:58 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 35E8321F8618 for ; Thu, 23 May 2013 13:49:45 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm2so509463bkc.30 for ; Thu, 23 May 2013 13:49:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=mr2Lmd8EEAT/EITCa9Hx8H+zu1NnAt5NaXUDDA+LbTI=; b=TYG7LsQWg+aH1Af5h9r3oc8mjlsS9IUqaD9XK62Rq5yp1ztFX9+JViRVYp0IBOP76m UoiQVoKoU0CvsgSkwSqocemBcE3/pL5kerEKrILqWqUKAbOeHBZOHve72+I0Y+eijP5i wlIblHe8dj0L04QA9gA6A71Dec6k9WDptaGlJUY0GleZfngXlx4+vmYut+YrRr5uoyHk PmQ1FumpXDH+pvHgkksUoZmo92TTF8bF5TyAMzR85eTuWI09rqCRj2o0hgRZxulLWzDt XZd7MCyFi9GNhMzZQauCgonZHgxcJ7emIHIAMa6sf9GCZf6PAZ3yBSkYxGfaYUOAMKw9 lWmw== X-Received: by 10.204.200.139 with SMTP id ew11mr7882859bkb.70.1369342184987; Thu, 23 May 2013 13:49:44 -0700 (PDT) Received: from [192.168.43.3] ([212.5.158.176]) by mx.google.com with ESMTPSA id es13sm3747318bkc.8.2013.05.23.13.49.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 13:49:44 -0700 (PDT) Message-ID: <519E80E4.6010904@jitsi.org> Date: Thu, 23 May 2013 23:49:40 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlw/voLHSyrj9xWpjjlO3ZjUIshLEwDE7GNto/f6spy2HubPC40nBQNYP2XY78gNcKjjC2M Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:35:09 -0000 Hey all, So first of all, I'd like to say that I like the approach and think this is the way to go. I have just one concern here. I already mentioned it in the call but I am not quite sure what the answer was. So here I go: On 23.05.13, 21:02, Cullen Jennings (fluffy) wrote: > > Here's is my proposal for roughly what the bundle draft should say about this demux topic > > Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows: > > 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping So my problem with having the above as number one is that while it would work perfectly with protocols like XMPP that have good discovery support, it would be a problem for SDP O/A based ones like SIP and WebRTC. The reason is that even when demuxing RFCs like that exist, an offerer won't know if the remote party supports them. They would hence always need to construct an offer where a fallback to another mechanism could be possible (like for example falling back to uniquely allocated PTs). Now, if the offerer does indeed know in advance that the fancy demuxing RFC will be supported, and only then, they would be able to rely on it and be careless about PT allocation. I believe we've built bundle port allocation and trickle ICE (and a number of other O/A mechanisms) around the same model. Emil -- https://jitsi.org From martin.thomson@gmail.com Thu May 23 14:42:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE3A21F8E06 for ; Thu, 23 May 2013 14:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.59 X-Spam-Level: X-Spam-Status: No, score=-4.59 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqbW2893JDMd for ; Thu, 23 May 2013 14:41:57 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6F21F920B for ; Thu, 23 May 2013 13:55:19 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id v10so3867700lbd.6 for ; Thu, 23 May 2013 13:55:18 -0700 (PDT) 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=ysL0v7jsAO0lqWqMgUfSSbnGN/w87lg8fYWTH+4qFuQ=; b=ahjdhoqC2W+ZhCI8ZK7bcI+6d2jE84YToMG7G8S2guYwr0CxjNQVclUxxrKkzAkdUe qmxLSLiGj9ndMEyav47swM6biBCGUqFA+B7S2xS97jBf7qfIFrFD+zpPGmUv1ZMtXEh8 KfZQ8Uv7b66M1i7nvU/lcDTXNJQF91Fp8cc5V8UugpP8VP4ir6wn3S6qsn8Sre6e1TtP kCHcFpeZ/gBS3YWpNkKQvOpMaoMZDZPdH3troHNaagecAUMxRiQLHoYEJoNByXAgwoWA CzA7KEW0HQOzCmY5LkPdpfaNJD34fZ7ASJkfUBGb+mwfj+s4GDtGUzq5kepeF1qPwfae mOEA== MIME-Version: 1.0 X-Received: by 10.112.154.35 with SMTP id vl3mr4561344lbb.55.1369342518249; Thu, 23 May 2013 13:55:18 -0700 (PDT) Received: by 10.112.235.233 with HTTP; Thu, 23 May 2013 13:55:18 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> Date: Thu, 23 May 2013 13:55:18 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: Christer Holmberg , mmusic , Paul Kyzivat Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:42:11 -0000 On 23 May 2013 06:41, Cullen Jennings (fluffy) wrote: > On May 22, 2013, at 4:55 PM, Justin Uberti wrote: > >> I think we could do this using the existing syntax, e.g. >> >> an offer of a=group:BUNDLE A B C would indicate that the offerer would prefer A, B, and C to be muxed onto A, and >> an answer of a=group:BUNDLE C A would indicate that the answerer is going to mux C and A onto C, and send B unbundled. >> > > I suspect several people are on the fence about using this approach or the first non rejected m-line in the bundle. > > Can anyone think of reasons why to pick one of the other of these two approaches ? I was originally strongly in favor of basing transport parameter choice solely on the order of m-lines in the SDP document. However, after our discussion this morning, if we allow a previously rejected m-line to be revived and added to a BUNDLE group, then the rule stating that any existing transport is used would take precedence over this. But that sucks. I have a better solution for this case. We should require that previously negotiated m-lines cannot change their BUNDLE affiliation. That would prevent the old m-line from being re-added to an existing BUNGLE. A new m-line would be required. From martin.thomson@gmail.com Thu May 23 14:44:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15121F881F for ; Thu, 23 May 2013 14:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFwwrkVA4igm for ; Thu, 23 May 2013 14:44:46 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C00F621F8F27 for ; Thu, 23 May 2013 13:57:50 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id er20so3685144lab.5 for ; Thu, 23 May 2013 13:57:49 -0700 (PDT) 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=Uv7L8j18D7MupRcGYhTQGtDxwXc8tRutYSdTDtx/SBQ=; b=YW2dxg4foDGKuCvaT4jg3hme14d12/ZW0Fg/bNglNcjNwZljPtf4s+Fz3vmYM2XNeV 4hE72a33+ggXosCsjbhSl18MGaKaSOWfVqm6tmpxDeQ13FOe5nAXVjDR/i+ncfOaXPcX bO9Imsmx4Jr5YDcYql63VNQ8WywpoHuR3Cq6LxmJF2ddKFls7pYXO3fUe6DAEhJiB0AX ZSTo2JkTl8XJnBZda2Ve+/83uN0cjt77E+i4+wtZE4oGYdjL4FxD2NpsZPA0f1oHeErV 9UrR7Ece7MXYOe3IdocYghC73SA0czjH3Ke6kx46VjeFMdfHxGKZGV/8ECFX9k6gPHgZ rDIw== MIME-Version: 1.0 X-Received: by 10.112.154.35 with SMTP id vl3mr4564919lbb.55.1369342669499; Thu, 23 May 2013 13:57:49 -0700 (PDT) Received: by 10.112.235.233 with HTTP; Thu, 23 May 2013 13:57:49 -0700 (PDT) In-Reply-To: <519E6265.4090102@alum.mit.edu> References: <519E6265.4090102@alum.mit.edu> Date: Thu, 23 May 2013 13:57:49 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:44:56 -0000 On 23 May 2013 11:39, Paul Kyzivat wrote: > Generally, once one packet has been bound to a processing pipeline then the > SSRC from that can be remembered, and used to shortcut the mapping for > future packets that have the same SSRC. This is actually the key. The pipeline should be attached to the SSRC. How that attachment is initially formed is what I think that Cullen is talking about. From martin.thomson@gmail.com Thu May 23 14:57:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD321F8CB4 for ; Thu, 23 May 2013 14:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.508 X-Spam-Level: X-Spam-Status: No, score=-4.508 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGUVtmzVnaVI for ; Thu, 23 May 2013 14:57:37 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id DFB0221F8E2C for ; Thu, 23 May 2013 14:09:54 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id x10so3961219lbi.35 for ; Thu, 23 May 2013 14:09:53 -0700 (PDT) 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=mieWA8ZLYnrTINhPcq6QTJuVRhJfDh8gI0YZaXp6WFU=; b=JAbN/jypsZ8ZV+OIPosW6c0o36f2iaduIMdBqrZa8gdDXxzsx4TZ4cewxvVCiDIbrc 1Ew9V9n+7807zZ5W2bfkQYA7m/wKgK9GAkGrWDZZmXyx1U3MoLZyfs/pdGVkHEEPCdXV /PWbEK2tQmcKIHo0RP9Y47k9l30h8vJV1IfaYa6Jb04q4s7bsFvYZzdvr2aLCDM4ZdBQ It6OQHaQNmM46vJbRR1gI/S65s57o1yAN5KNZe0yduh7tjTKmCSOCw57XTzWextIKeHr A8mEl+11rqbNmL/WsTrvqxif45xvzPBnQkOAYl2ZXIuKwRkwkfFJOfKAq1MHimrxkkWz n35Q== MIME-Version: 1.0 X-Received: by 10.112.190.73 with SMTP id go9mr7435948lbc.43.1369343393847; Thu, 23 May 2013 14:09:53 -0700 (PDT) Received: by 10.112.235.233 with HTTP; Thu, 23 May 2013 14:09:53 -0700 (PDT) In-Reply-To: <519E530C.60705@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> Date: Thu, 23 May 2013 14:09:53 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:57:52 -0000 The more I think about forking, the more I don't want to think about it any more. On 23 May 2013 10:34, Paul Kyzivat wrote: > * if the bundle is accepted by multiple forks, does this form > one RTP session or several? If the subjective view of the RTP session that the offerer holds is bound to a 5-tuple (as opposed to just local addressing), then this forms multiple sessions. However... Prior to getting answer(s), the offerer might be unable to tell that there are multiple RTP sessions, or if it is just media arriving from multiple source addresses. This would only be a problem in the absence of ICE and with multiple m-lines. > * How does ICE work in this case? (Is that already covered by ICE, > since it mostly isn't specific to bundle? I believe that ICE works in this case. Each RTP session should have a different set of ufrag/pwd for the peer. I know that others have talked about the implications for the ICE state machine for bundle, but that depends on ufrag/pwd. > * If one fork adds/removes an m-line from the bundle, should that > be mirrored to the other forks? I don't see how that has a significant impact. Each fork could choose different bundling configurations. This is not significantly different to other forking cases. The offerer has to be prepared to demux at the session layer first. From pkyzivat@alum.mit.edu Thu May 23 15:18:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6588E21F9837 for ; Thu, 23 May 2013 15:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99urmzo0jpFN for ; Thu, 23 May 2013 15:18:37 -0700 (PDT) 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 A3C9221F984B for ; Thu, 23 May 2013 14:34:17 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta10.westchester.pa.mail.comcast.net with comcast id fSo11l0060QuhwU5AZaHrk; Thu, 23 May 2013 21:34:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id fZaG1l00i3ZTu2S3NZaGvb; Thu, 23 May 2013 21:34:17 +0000 Message-ID: <519E8B58.9030604@alum.mit.edu> Date: Thu, 23 May 2013 17:34:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <519E6265.4090102@alum.mit.edu> In-Reply-To: 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=1369344857; bh=BKIIqzjnmPOnVpdVqPH/QgiLbVjASz/bzM//QzHFDnI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q07yDhAO4CX81/13Bi5WLo0Ov9ErB/T4HuECNwwJBofEklvMu35mXFwByIX+6L5EM t0EcG4Bz5vij13kUMjnEnRyoxJexjun0k0tQAxDGtftYkdX9adKgUzzrJqkaFe+nfd vmID8q8IyUzTjdzC0mAdqCZ6+z1iMiZQW1JSDM2BWUlHt+hwCfCdR9bH76B16dqBlE V92xcnuiL6VGHcAmUJ//zqNEjh9cCldhAy1q++/eHIwsnUO5P0wZxO3I6C0jZ0ERrC 9idZJDWc7LxfYt1rae7GrKVD4geZTrPPLMUSlMJ70Dto1Elso7KFTWpoGzFE9MJ6h/ HN2Bd4AudZXxw== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:18:52 -0000 On 5/23/13 4:57 PM, Martin Thomson wrote: > On 23 May 2013 11:39, Paul Kyzivat wrote: >> Generally, once one packet has been bound to a processing pipeline then the >> SSRC from that can be remembered, and used to shortcut the mapping for >> future packets that have the same SSRC. > > This is actually the key. The pipeline should be attached to the > SSRC. How that attachment is initially formed is what I think that > Cullen is talking about. > Well, I said *generally*, not *always*. For instance, we have a clue case where we can have two clue switched captures, one representing the video for loudest speaker, and one for the 2nd loudest speaker. A single SSRC can move from one of those captures to the other. Its the capture (identified by an rtp header extension) that selects the processing pipeline. Or, you can view it as layered. Where the ssrc maps to an early stage of the pipeline (selected by ssrc) that does the codec processing, and then a different stage of the pipeline (selected by capture id from the header extension) that switches the decoded output to a particular rendering device. Thanks, Paul From pkyzivat@alum.mit.edu Thu May 23 15:26:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2905B21F8FDB for ; Thu, 23 May 2013 15:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRxjqmejPZzn for ; Thu, 23 May 2013 15:26:01 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 833EA21F8F87 for ; Thu, 23 May 2013 14:39:52 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id fV2H1l0020SCNGk51Zfs2Z; Thu, 23 May 2013 21:39:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id fZfr1l00X3ZTu2S3VZfrXN; Thu, 23 May 2013 21:39:51 +0000 Message-ID: <519E8CA6.1090009@alum.mit.edu> Date: Thu, 23 May 2013 17:39:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> In-Reply-To: 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=1369345192; bh=74YscLOOKOjvPgOsW8crKxigyrnEwtyiOH+t3XlciEY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GbytfqnFH5H8ozEsv3zKafzfEK+CTmqUlPgDYG+Szo7QIktd9978Mg90d1YlPllau f8bum1o2xdfGVgg7qfAG4MzdanKEqT5SgN/8A7FCTpzRLpUxCnZ7j6ujmaqHfyQzM8 T8xBYGbuQOIf2F6k4aQEn2kmgwP622xUnpcVDFVocbBVLfgQKoV4oTU5owOXe/xnZq B2qXg/QDwrUhrxyX1naML1ZGzZ6j4IYwc+nZ1bFGMwOBMIF23ljffwSP6ItfqpSEh1 t0MiW5LuXWFiC5eVx7tPZso/EvP94F54T6gFOMuRsiMbIvn8PyG7rZ4reO2KmKm/np 9f/mzFoIyiMag== Cc: "Cullen Jennings \(fluffy\)" , Christer Holmberg , mmusic Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:26:16 -0000 On 5/23/13 4:55 PM, Martin Thomson wrote: > On 23 May 2013 06:41, Cullen Jennings (fluffy) wrote: >> On May 22, 2013, at 4:55 PM, Justin Uberti wrote: >> >>> I think we could do this using the existing syntax, e.g. >>> >>> an offer of a=group:BUNDLE A B C would indicate that the offerer would prefer A, B, and C to be muxed onto A, and >>> an answer of a=group:BUNDLE C A would indicate that the answerer is going to mux C and A onto C, and send B unbundled. >>> >> >> I suspect several people are on the fence about using this approach or the first non rejected m-line in the bundle. >> >> Can anyone think of reasons why to pick one of the other of these two approaches ? > > I was originally strongly in favor of basing transport parameter > choice solely on the order of m-lines in the SDP document. > > However, after our discussion this morning, if we allow a previously > rejected m-line to be revived and added to a BUNDLE group, then the > rule stating that any existing transport is used would take precedence > over this. > > But that sucks. I have a better solution for this case. We should > require that previously negotiated m-lines cannot change their BUNDLE > affiliation. That would prevent the old m-line from being re-added to > an existing BUNGLE. A new m-line would be required. I am pretty strongly opposed to restricting how one can recycle m-lines. IMO this is a pretty basic and fundamental mechanism. Your concern is only important if you we use the "first m-line in the SDP that is non-zero and part of the bundle" rather than "first mid in the bundle that identifies a non-zero m-line". I thought we settled that. Thanks, Paul From pkyzivat@alum.mit.edu Thu May 23 15:28:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BF521F9765 for ; Thu, 23 May 2013 15:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy0b41VrEdP8 for ; Thu, 23 May 2013 15:28:10 -0700 (PDT) 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 0E40D21F90CD for ; Thu, 23 May 2013 14:45:46 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta08.westchester.pa.mail.comcast.net with comcast id fZBU1l0021ZXKqc58ZlmUU; Thu, 23 May 2013 21:45:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id fZlm1l00D3ZTu2S3hZlm0t; Thu, 23 May 2013 21:45:46 +0000 Message-ID: <519E8E06.5060002@alum.mit.edu> Date: Thu, 23 May 2013 17:45:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> In-Reply-To: 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=1369345546; bh=AWyfzxJsD2b7kbnhftRNRL+KFcM1yAuE/GndT237kUY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VQU1kEyXzAVggKyJ9jPKYGKWW3nm4y25VSIFuGpFQ2jcNXc7WfcivqcjapX1Du5pN jXP+5Q88JOZ5XOWlSSunpv2hPQXVnwdzqyL4U95SWeFWKbWN1Yh6FwR9FHYPzZW63Z pSTJUCuJBlcHIIcEDMAWqGREzhbPb3JcprbCqS1UOiw3OiOAVr5cN8k6fyiRue05HK XaY466b0sltXX0S/PBQcLHjSiO2e7IqSmT7jxedzm8+QJ9BlDSf2o73+qDOQiid+or UqoJ7+pzWZCmH/AJX+aa/Zi7GNZa1SCgcD1YTyEJ7PtZ2In7ZV3LoiNZ91NGpGQNiY Oq4wyEMDL0ibg== Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:28:15 -0000 On 5/23/13 5:09 PM, Martin Thomson wrote: > The more I think about forking, the more I don't want to think about > it any more. You and everybody else. :-) That's why I'm happy to leave it out of scope here unless somebody volunteers to do the hard work. Thanks, Paul From mzanaty@cisco.com Thu May 23 15:29:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA221F90EA for ; Thu, 23 May 2013 15:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG3x6OglKEfw for ; Thu, 23 May 2013 15:29:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 507D321F9929 for ; Thu, 23 May 2013 14:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3092; q=dns/txt; s=iport; t=1369345690; x=1370555290; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZTstaeb5UIz6VxUGTI2aJZoBR0DPoHK37M5fWt8q2jI=; b=dT2YpRlwSrMMtle/lFxFpM/36NNQ2XVGmMb9uJS6CuKjXJtKYBOJcm1X paf6aTY0QdfUKZ2MA0Z6fzl1Z/Ar/UOLMTN9GEerWT5Au0VP4GfgQfNaX H0iK+hHFBywfQVjcSVm31Ta91Za8xEzefEYV4NYNcIzlDH9jfLa9FesOh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGAAOJnlGtJV2d/2dsb2JhbABZgwgwwi+BDBZ0giMBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCIgFDLlrBI1lgQc4BoJtYQOTapURgw+BaD4 X-IronPort-AV: E=Sophos;i="4.87,730,1363132800"; d="scan'208";a="214347136" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 23 May 2013 21:48:10 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4NLm9v6032099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 May 2013 21:48:09 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 23 May 2013 16:48:09 -0500 From: "Mo Zanaty (mzanaty)" To: "Cullen Jennings (fluffy)" , mmusic WG Thread-Topic: [MMUSIC] Proposal for what bundle should say about demux Thread-Index: AQHOV9/DVjr8src5NEuGXcSJwmehbJkTIk8w Date: Thu, 23 May 2013 21:48:08 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D47B98B@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.88.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:29:07 -0000 I agree with this, including the order of 2 and 3. I was initially averse to PT demux, for RTP purist reasons (since it is int= ended to convey codecs not sources) and practical reasons (limited space of= 32-96 code points, depending on your interop risk tolerance, for all combi= nations of codecs and sources). But I have warmed up to it based on a reali= zation that I (and maybe others) missed. When using rtcp-mux, there must *always* be an initial step: 0) PT demux to classify RTP vs. RTCP ...before you can look at RTP header extensions in 1 (no X bit in RTCP head= ers) ...before you can look at SSRCs in 3 (different SSRC offsets in RTP vs. RTC= P headers) Given step 0, it is hard to argue against PT demux from a RTP purist view. = The practical problem of the limited PT space remains. But for simple cases= , like a single audio and video stream with a reasonable number of codec fo= rmats, I see no reason to disallow or discourage this, since step 2 can be = folded into step 0. For more complex cases, with more sources and codec for= mats, FEC/RTX, scalable/simulcast layers, screen sharing, multiple cameras,= etc., it quickly becomes impractical or impossible. In that sense, Plan A = may work best for simple cases, while Plan B may work best for complex case= s. But both could still share these common demux rules. Mo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Cullen Jennings (fluffy) Sent: Thursday, May 23, 2013 2:03 PM To: mmusic WG Subject: [MMUSIC] Proposal for what bundle should say about demux Here's is my proposal for roughly what the bundle draft should say about th= is demux topic=20 Application will decide which packet processing pipeline to pass an given R= TP/RTCP packet to based on what the application knows: 1) If future RFCs define new things (like RTP header extension), that expli= citly specify the mapping, check if that future RFC is in use and if so the= n use that to form the mapping=20 2) If the PT type is uniquely identifies a mapping, use that to form the ma= pping 3) If application knows the SSRC the other side will use, use that to form = the mapping=20 4) if there is no way to know which pipeline to pass it too, the packet MAY= be discarded or the application MAY decide to buffer it until the mapping = is known=20 This is trivial to implement. It meets the requirements for Plan A, Plan B,= UCIF, CLUE, and so on.=20 We could swap the order of step 2 and 3, My thinking for this order was the= only time it made any difference the order was if the PT were unique and i= ndicated a different mapping than the SSRC. The only way this could happen = is with a SSRC collision so the PT is the one that would be correct not the= SSRC. If someone feels strongly the order of steps 2 and 3 should be the o= pposite way around, I can live with that. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Thu May 23 15:32:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F105521F8CB4 for ; Thu, 23 May 2013 15:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgY6Nfhd7Cz8 for ; Thu, 23 May 2013 15:32:38 -0700 (PDT) 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 50A6421F85C0 for ; Thu, 23 May 2013 14:59:14 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id fR701l0051c6gX853ZzEbd; Thu, 23 May 2013 21:59:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id fZzE1l0063ZTu2S3jZzEg2; Thu, 23 May 2013 21:59:14 +0000 Message-ID: <519E9131.2080400@alum.mit.edu> Date: Thu, 23 May 2013 17:59:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <519E80E4.6010904@jitsi.org> In-Reply-To: <519E80E4.6010904@jitsi.org> 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=1369346354; bh=CTZa18/rxTs1Ti9Lt/J+3qSiOxOzzY58RABWFv5WaAc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MRJ0c327iZZ+0rDUCTypUChTS9Dq97KIPRaXoVreXF8D0TLA8PLpfqFcutbfiIXwI m4x9w/J2Er0huafLuW+hoS3N0/3y4VcrwxTlI0t9ygUSSvl3r76qbR/uOZljfA1/iq 2t7D5hbhkT7TL+IHoEh5tf3NuenQHXo+lwc559uikK3eeP2M8u8U/Go6HvqZAoIYG5 AZaeqD4MpkWhWCUO91EtYZggyJYRVDmwQtsCvbc/0nvoRbrXFMzaeVMF9zf/nxfdc9 ZTMZysWUTr16Mx9dE4MJqwOq+UdBbnachsmlgyzZD7OPH7crA2iRmJjhKU7QwZhYqd wFEh41+5QMvxw== Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:32:44 -0000 On 5/23/13 4:49 PM, Emil Ivov wrote: > Hey all, > > So first of all, I'd like to say that I like the approach and think this > is the way to go. > > I have just one concern here. I already mentioned it in the call but I > am not quite sure what the answer was. So here I go: > > On 23.05.13, 21:02, Cullen Jennings (fluffy) wrote: >> >> Here's is my proposal for roughly what the bundle draft should say about this demux topic >> >> Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows: >> >> 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping > > So my problem with having the above as number one is that while it would > work perfectly with protocols like XMPP that have good discovery > support, it would be a problem for SDP O/A based ones like SIP and WebRTC. > > The reason is that even when demuxing RFCs like that exist, an offerer > won't know if the remote party supports them. They would hence always > need to construct an offer where a fallback to another mechanism could > be possible (like for example falling back to uniquely allocated PTs). > > Now, if the offerer does indeed know in advance that the fancy demuxing > RFC will be supported, and only then, they would be able to rely on it > and be careless about PT allocation. It will work for CLUE, because CLUE won't start using it on the first O/A. It will only do so after it knows that it makes sense. And in clue it can potentially take precedence over PT. *In theory* we could have one switched capture that sometimes gets an H.264 RTP stream, and other times gets a VP8 RTP stream. (I don't know if that is likely to happen in practice. Jonathan might have more to say about that.) IMO the "before the O/A completes" issues are separate from the "after the O/A completes" issues. I'm still not convinced that the "before the O/A completes" issues are important. (We have reliable 183 responses to deal with it.) But I'm ok with Cullen using PT to solve that problem if he thinks he needs to. I'm more concerned with having a well defined way of associating packets with m-lines in the bundle after the O/A is complete. Thanks, Paul > I believe we've built bundle port allocation and trickle ICE (and a > number of other O/A mechanisms) around the same model. > > Emil > > From worley@shell01.TheWorld.com Thu May 23 15:35:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DD621F8A14 for ; Thu, 23 May 2013 15:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ad4RcK298z8 for ; Thu, 23 May 2013 15:35:05 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3D21F95E5 for ; Thu, 23 May 2013 15:07:51 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4NM7Fkr019872; Thu, 23 May 2013 18:07:17 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4NM7FEH5316045; Thu, 23 May 2013 18:07:15 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4NM7Fck5320993; Thu, 23 May 2013 18:07:15 -0400 (EDT) Date: Thu, 23 May 2013 18:07:15 -0400 (EDT) Message-Id: <201305232207.r4NM7Fck5320993@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <519E6265.4090102@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <519E6265.4090102@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:35:11 -0000 > From: Paul Kyzivat > > Cullen, > > I just posted a separate, related, message on associating packets to > m-lines. > > IMO they are complementary, and somewhat layered: > > First, the packet should be matched to the m-line. > The m-line then provides an bunch of related info: > - mapping from PT to codec > - bandwidth info > - per-ssrc info > - labels that can be bound to application specific data > - ... > > All of that info is then available to help associate the packet to a > processing pipeline. Then the algorithms you talk about kick in. I think Cullen is addressing both layers together, but his proposal is best looked at by splitting it into two parts, one that addresses the first layer and one that addresses the second layer. The reason that splitting the layers is useful is that the second layer problem has been solved -- or solved in multiple ways -- but it is a problem somebody already has to solve, and any legacy situation has solved it in some particular way. So we only have to solve the first layer problem. As I read it, Cullen proposes that the first layer demultiplexing by 1) looking for an RTP extension header, or RTCP SDES extension information, that tells which m= line the packet is allocated to 2) seeing if the payload type identifies a unique m= line 3) seeing if the SSRC is specified by some attribute in an an m= line The second layer demultiplexing is close to the "A vs. B" problem, how do you differentiate packets for the application processing streams, which is closely tied to which application processing streams can share the same m= line, and how that sharing is signaled. Dale From worley@shell01.TheWorld.com Thu May 23 15:35:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8736521F941D for ; Thu, 23 May 2013 15:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3ZtdA9jPhY6 for ; Thu, 23 May 2013 15:35:08 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4CED121F97D4 for ; Thu, 23 May 2013 15:08:01 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4NM7T2E011287; Thu, 23 May 2013 18:07:31 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4NM7Tlq5333991; Thu, 23 May 2013 18:07:29 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4NM7Tlv5329814; Thu, 23 May 2013 18:07:29 -0400 (EDT) Date: Thu, 23 May 2013 18:07:29 -0400 (EDT) Message-Id: <201305232207.r4NM7Tlv5329814@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <519E5F54.3000806@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <519E5F54.3000806@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:35:15 -0000 > From: Paul Kyzivat > > IMO the following should obviously be a truism. I want to know if all agree. > > If an O/A exchange negotiates a bundle with multiple m-lines, > then attributes in those m-lines and the associated media sections must > provide sufficient information to associate each incoming packet on the > 5-tuple to exactly *one* of those m-lines. I agree. I think there are non-legacy situations where this need may be relaxed, but all interoperation in legacy situations seems to require discerning the appropriate m= line so information in the SDP section can be used to identify the particular application processing stream. > [...] receiving packets that don't match any of the m-lines. I > think we ought to address that, by defining some syntax to specify what > to do with packets that don't match any m-line. This might be to specify > one m-line as the default, or that packets that don't match be discarded. I think that discarding them is the only workable approach. There's no reason to assume that sending them to a default m= line would allow the upper level of demultiplexing to succeed. Dale From worley@shell01.TheWorld.com Thu May 23 15:35:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E961621F95E5 for ; Thu, 23 May 2013 15:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guiQaYNE+N7g for ; Thu, 23 May 2013 15:35:11 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4D33121F9811 for ; Thu, 23 May 2013 15:08:02 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4NM6m1C026667; Thu, 23 May 2013 18:06:50 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4NM6mFP5335825; Thu, 23 May 2013 18:06:48 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4NM6l5C5338062; Thu, 23 May 2013 18:06:47 -0400 (EDT) Date: Thu, 23 May 2013 18:06:47 -0400 (EDT) Message-Id: <201305232206.r4NM6l5C5338062@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <519E530C.60705@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:35:18 -0000 > From: Paul Kyzivat > > On 5/23/13 6:35 AM, Emil Ivov wrote: > > > In case a bundle offer gets forked and various answers ... > > I trimmed everything else out of Emil's reply, and changed to subject, > because this is a whole different can of worms! > > I think we must acknowledge that this *can* happen, though it is a low > probability event. It raises all sorts of ugly issues. A few: Is this actually complicated? That is, worse than is already the case in SIP... My understanding is that in SIP (and this must be a SIP situation), each fork proceeds with completely independent state from all other forks. The forks happen to share sending/receiving ports, but the received packets can be demultiplexed to the correct fork based on their sending addresses. Of course, there are a range of obnoxious situations where you receive packets before you receive a SIP response (SDP answer) that describes them, but that is true in non-bundled SIP as well. Dale From worley@shell01.TheWorld.com Thu May 23 15:35:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9996621F968E for ; Thu, 23 May 2013 15:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeQ7aA2Jp+jX for ; Thu, 23 May 2013 15:35:14 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 47ED721F9914 for ; Thu, 23 May 2013 15:08:05 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4NM7nRw026559; Thu, 23 May 2013 18:07:52 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4NM7n205319481; Thu, 23 May 2013 18:07:49 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4NM7nFn5297137; Thu, 23 May 2013 18:07:49 -0400 (EDT) Date: Thu, 23 May 2013 18:07:49 -0400 (EDT) Message-Id: <201305232207.r4NM7nFn5297137@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Parthasarathi R" In-reply-to: <007601ce57e1$b15a5b30$140f1190$@co.in> (partha@parthasarathi.co.in) References: <20130520161935.17435.91264.idtracker@ietfa.amsl.com> <002801ce564b$51e52230$f5af6690$@co.in> <201305230204.r4N247r25245471@shell01.TheWorld.com> <007601ce57e1$b15a5b30$140f1190$@co.in> Cc: fluffy@cisco.com, mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:35:21 -0000 > From: "Parthasarathi R" > > If the answerer supports RFC3551, then the answerer has to support RFC3555 > for annexb parameter. Annexb value default value is "Yes" in RFC 3555 as per > RFC 3551. RFC 4856 obsoletes RFC 3555 without changing "annexb" related > requirement. Please let me know any reason that you wish to change AnnexB > parameter default value now. Sorry, my mistake, I didn't realize that "annexb" is not an extension of audio/g729, it's defined in the base specification: RFC 4856 section 2.1.9 Registration of Media Type audio/G729 Type name: audio Subtype name: G729 Optional parameters: [...] annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted. So the answer to Cullen's query is: > From: "Cullen Jennings (fluffy)" > > What happens when an endpoint that understands the anexb attribute > sends and offer to an endpoint that does not understand or implement > the anexb attribute ? Since the annexb attribute is part of the (original) registration of audio/g729, any endpoint that implements that media type understands the annexb attribute. If the answer does not include the annexb attribute, the answerer knows that it has implied the default "annexb=yes". Dale From fluffy@cisco.com Thu May 23 15:38:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AD721F978B for ; Thu, 23 May 2013 15:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a41Yi4dR2ln9 for ; Thu, 23 May 2013 15:38:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4561321F8B98 for ; Thu, 23 May 2013 15:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3346; q=dns/txt; s=iport; t=1369347798; x=1370557398; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=imj7/Vr0vseG833cu00e8ygLqHYFYv2gRdFg6xG95Xc=; b=FHvXCRbhs0SiqRI4E4K3xZkOjy6cc1ciCrPXjoNuZRYjxloIg4Kkz271 HpwuyioxCSPurw3QbNHROTHL1i6t/yH73ZypefxuKSC1F62UCf4SCKWnG jtdKCHBaAVxowirfvJkLWCiAGs0kftBA+LPZHDVfa0h3df8K3GvHzwKgH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKSWnlGtJV2d/2dsb2JhbABZgwjCX4EMFnSCIwEBAQMBZxIFCwIBCA4KCiQyJQIEDgUIh38GuhSOagIxB4JzYQOIZ6AUgw+CJg X-IronPort-AV: E=Sophos;i="4.87,730,1363132800"; d="scan'208";a="214381198" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 23 May 2013 22:22:58 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4NMMwvh031543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 22:22:58 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 23 May 2013 17:22:58 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [MMUSIC] Proposal for what bundle should say about demux Thread-Index: AQHOV/cQIaUMan7TmECSKq/rU07GDJkTrAqA Date: Thu, 23 May 2013 22:22:33 +0000 Message-ID: References: <519E80E4.6010904@jitsi.org> In-Reply-To: <519E80E4.6010904@jitsi.org> 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="iso-8859-1" Content-ID: <2F9B32C462A59F459A37FC03A77BF53B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:38:41 -0000 On May 23, 2013, at 2:49 PM, Emil Ivov wrote: > Hey all, >=20 > So first of all, I'd like to say that I like the approach and think this > is the way to go. >=20 > I have just one concern here. I already mentioned it in the call but I > am not quite sure what the answer was. So here I go: >=20 > On 23.05.13, 21:02, Cullen Jennings (fluffy) wrote: >>=20 >> Here's is my proposal for roughly what the bundle draft should say about= this demux topic=20 >>=20 >> Application will decide which packet processing pipeline to pass an give= n RTP/RTCP packet to based on what the application knows: >>=20 >> 1) If future RFCs define new things (like RTP header extension), that ex= plicitly specify the mapping, check if that future RFC is in use and if so = then use that to form the mapping=20 >=20 > So my problem with having the above as number one is that while it would > work perfectly with protocols like XMPP that have good discovery > support, it would be a problem for SDP O/A based ones like SIP and WebRTC= . >=20 > The reason is that even when demuxing RFCs like that exist, an offerer > won't know if the remote party supports them. They would hence always > need to construct an offer where a fallback to another mechanism could > be possible (like for example falling back to uniquely allocated PTs). >=20 > Now, if the offerer does indeed know in advance that the fancy demuxing > RFC will be supported, and only then, they would be able to rely on it > and be careless about PT allocation. >=20 > I believe we've built bundle port allocation and trickle ICE (and a > number of other O/A mechanisms) around the same model. >=20 > Emil >=20 What I had in mind was something along the lines of the following=20 A is sending an offer that forks to B and C. A and B support the new mechan= isms but C does not. A has no idea if the things it is talking to support t= he new thing.=20 A constructs an offer that in the SDP has an indication it can receive the = header extension. Perhaps something like "a=3Dnew-hdr-ext=3D123456". The ne= w header extension allows one to embed an identifer in the RTP packets and = this SDP indicates that the identifier should be 123456 for RTP with this m= apping.=20 A sends the offer and it arrives at both B and C. C does not understand it = and just ignores it. B understands it and inserts a TP header extension wit= h the identifier 123456.=20 Imagine the RTP packets from B and C arrive at A before any SDP answer. A l= ooks at the RTP packet from B, and see the header exertion and reads out th= e identifier 123456 and now knows the mapping. A looks at the RTP packet fr= om C and does not see the RTP header extension so it carries on to try othe= r things.=20 So yes, as you point out, for the packets from C where it can't use PT, it = needs to fall back to SSRC which means A can't really process the packets f= rom C until the answer arrives. But that is fine - if you are using somethi= ng that does not support the new stuff, the behavior you get is the best we= can do with the old stuff yet at the same time you get the faster behavior= with things that do the new stuff. C is as fast as it can be and B is as f= ast as it can be.=20 That seems like the type of design we want.=20 From martin.thomson@gmail.com Thu May 23 17:14:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D4E21F8EA4 for ; Thu, 23 May 2013 17:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUHJrNU4J7Rn for ; Thu, 23 May 2013 17:14:41 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE8621F8CEC for ; Thu, 23 May 2013 17:14:40 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id fg20so3898244lab.15 for ; Thu, 23 May 2013 17:14:39 -0700 (PDT) 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=i22sQ7BVvsL5KbVgtym8S6V4ywACLiM17/rUEFEzE2s=; b=cEdm4XxqMUbaT8nCGRfuDm0QRVe/0gRufSHHqxUpHMbSHb25zMv2HThRxMRn7pORKt 6NBGcqr2F/Pb/6lxhogb4ymtS01+HI4BctfHj2yafK7blwxwuGRGW+rSrW2WG3Jt1jbq l4mdRzkY2AT42LNSoqtglwsA4gvE2iFkuvtOpdzY3xLxFG7U5gXkKjSBlhucZ47Qkg/U YNkxUM0rANHi89Ri2j99kWnKaEX+cD8cm6Gcy5tQpoZyekyic/ZXNobRAu8rxVDkI067 qREV12czKZDIVBAiSA1Z2VjxdppiEvrAO26q0EwMowipKIbN+tOXcN0XX/nNiBPD91Zo apFQ== MIME-Version: 1.0 X-Received: by 10.112.190.42 with SMTP id gn10mr5793718lbc.82.1369354479755; Thu, 23 May 2013 17:14:39 -0700 (PDT) Received: by 10.112.166.38 with HTTP; Thu, 23 May 2013 17:14:39 -0700 (PDT) In-Reply-To: <519E8CA6.1090009@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> <519E8CA6.1090009@alum.mit.edu> Date: Thu, 23 May 2013 17:14:39 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , Christer Holmberg , mmusic Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 00:14:42 -0000 On 23 May 2013 14:39, Paul Kyzivat wrote: > I am pretty strongly opposed to restricting how one can recycle m-lines. > IMO this is a pretty basic and fundamental mechanism. What I'm suggesting would permit recycling(*). However, if you are amending a session (as opposed to throwing it out entirely and starting over), then I would rather that you cannot (I suggest MUST NOT) change the BUNDLE affiliation of an m-line. This is - of course - only possible if you permit rejected m-lines to remain in a group. This really goes back to the whole BUNDLE negotiation model. If a line is tentatively part of a BUNDLE group in the first exchange, confirmed in the second, do we permit splitting, reassignment, etc... in subsequent exchanges? Or, do we permit the movement in and out of BUNGLE groups for any m-line? If I want to migrate off one BUNDLE and to another, do I first reject the line and remove it from the BUNDLE group (exchange 1) and then re-animate it with a new BUNDLE group (exchange 2)? From martin.thomson@gmail.com Thu May 23 17:18:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EBD21F93B9 for ; Thu, 23 May 2013 17:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.438 X-Spam-Level: X-Spam-Status: No, score=-4.438 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcYeAbSIYXfZ for ; Thu, 23 May 2013 17:17:55 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1921F9413 for ; Thu, 23 May 2013 17:17:24 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id r10so3999248lbi.25 for ; Thu, 23 May 2013 17:17:23 -0700 (PDT) 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=IpGdmrhmAJV9zvJy1KMI2N5DEloxBCoLFFJLJU8JNEU=; b=xOwKJ8F3bj27v4KUeF+/gMezlcf2bPhN5TSIkmHknQgb1elNdHqOBmwtiERBj4vABX K3aRzGpzWzkwc/HgGBQg1bSXh4AQmOVgNhDG5x0EZoEaYHINN63MawtEZeofZNVvowU0 pNKobsKDHvLlm0/d05v2Er/K7pr2EzNxHb7xc4Y4OP8DPVJQp2ZTD3OqBdZsXRmSOy4C rD3Pkbnv8CeLLvf/WyZVT3g1V4nLROFZI61N0KPIQWWymH3sG0lKsX5yLH/uRgkcLzF8 Tpt1xkVakRyU7A+IVfxCLIj8+uLebpQk0JUDaDuy0+Texxxc0iE20NG5n+wXllTT6IAG 8t7Q== MIME-Version: 1.0 X-Received: by 10.112.210.101 with SMTP id mt5mr7677937lbc.85.1369354643448; Thu, 23 May 2013 17:17:23 -0700 (PDT) Received: by 10.112.166.38 with HTTP; Thu, 23 May 2013 17:17:23 -0700 (PDT) In-Reply-To: <519E8B58.9030604@alum.mit.edu> References: <519E6265.4090102@alum.mit.edu> <519E8B58.9030604@alum.mit.edu> Date: Thu, 23 May 2013 17:17:23 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 00:18:00 -0000 On 23 May 2013 14:34, Paul Kyzivat wrote: > Or, you can view it as layered. Where the ssrc maps to an early stage of the > pipeline (selected by ssrc) that does the codec processing, and then a > different stage of the pipeline (selected by capture id from the header > extension) that switches the decoded output to a particular rendering > device. That is what I would do for that case. At the layer I'm concerned about, this is still the same stream. The fact that someone downstream might use other information to wiggle that around doesn't concern me greatly. From mperumal@cisco.com Thu May 23 21:20:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BEC21F9649 for ; Thu, 23 May 2013 21:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slU9mB2iNsBl for ; Thu, 23 May 2013 21:20:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B977A21F8E76 for ; Thu, 23 May 2013 21:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2213; q=dns/txt; s=iport; t=1369369220; x=1370578820; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VyxmAdwjskiNnLiMq4jCQ1Cx4ofba96BllCXvAhNTtE=; b=ADMIQxBJDua6YvqkWxaBeoqiPty1Il5ZWfkHx6Ly8LWGphjuUW+a3Lek ly1n9XBH+3wHjrCGR/HT1GBvduaIUkK50tdvimbxOm4SN0KnNGW710Zxl rm7b221X6MqX+yqZC5y4ljRcs4N+lUAumJ1iOBvjkfxHnhlMmcmfjRCTy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAAzqnlGtJV2Y/2dsb2JhbABZgwjCWIELFnSCIwEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAgQBDQUIiAW6PY5sMQcGgm1hA6h7gw+CJg X-IronPort-AV: E=Sophos;i="4.87,732,1363132800"; d="scan'208";a="214402110" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 24 May 2013 04:20:19 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4O4KJt4007808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 04:20:19 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.15]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 23 May 2013 23:20:18 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Dale R. Worley" , Parthasarathi R Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt Thread-Index: AQHOWAIBpBvYmClCD0e8SeThOrsMVpkTu0ow Date: Fri, 24 May 2013 04:20:18 +0000 Message-ID: References: <20130520161935.17435.91264.idtracker@ietfa.amsl.com> <002801ce564b$51e52230$f5af6690$@co.in> <201305230204.r4N247r25245471@shell01.TheWorld.com> <007601ce57e1$b15a5b30$140f1190$@co.in> <201305232207.r4NM7nFn5297137@shell01.TheWorld.com> In-Reply-To: <201305232207.r4NM7nFn5297137@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.209.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 04:20:27 -0000 |Since the annexb attribute is part of the (original) registration of |audio/g729, any endpoint that implements that media type understands |the annexb attribute. If the answer does not include the annexb |attribute, the answerer knows that it has implied the default |"annexb=3Dyes". Thank you for the clarifying text. We'll include it in the next revision of= the draft. Muthu |-----Original Message----- |From: Dale R. Worley [mailto:worley@ariadne.com] |Sent: Friday, May 24, 2013 3:38 AM |To: Parthasarathi R |Cc: Cullen Jennings (fluffy); mmusic@ietf.org; Muthu Arul Mozhi Perumal (m= perumal) |Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt | |> From: "Parthasarathi R" |> |> If the answerer supports RFC3551, then the answerer has to support RFC35= 55 |> for annexb parameter. Annexb value default value is "Yes" in RFC 3555 as= per |> RFC 3551. RFC 4856 obsoletes RFC 3555 without changing "annexb" related |> requirement. Please let me know any reason that you wish to change Annex= B |> parameter default value now. | |Sorry, my mistake, I didn't realize that "annexb" is not an extension |of audio/g729, it's defined in the base specification: | |RFC 4856 section 2.1.9 | | Registration of Media Type audio/G729 | | Type name: audio | Subtype name: G729 | Optional parameters: | [...] | annexb: indicates that Annex B, voice activity detection, is | used or preferred. Permissible values are "yes" and "no" | (without the quotes); "yes" is implied if this parameter is | omitted. | |So the answer to Cullen's query is: | |> From: "Cullen Jennings (fluffy)" |> |> What happens when an endpoint that understands the anexb attribute |> sends and offer to an endpoint that does not understand or implement |> the anexb attribute ? | |Since the annexb attribute is part of the (original) registration of |audio/g729, any endpoint that implements that media type understands |the annexb attribute. If the answer does not include the annexb |attribute, the answerer knows that it has implied the default |"annexb=3Dyes". | |Dale From emil@sip-communicator.org Fri May 24 00:08:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA5A21F9434 for ; Fri, 24 May 2013 00:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biEf1vkZxtv3 for ; Fri, 24 May 2013 00:08:07 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA2621F9408 for ; Fri, 24 May 2013 00:08:06 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id mx1so2282400bkb.26 for ; Fri, 24 May 2013 00:08:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=WfPvuV2+ls+t7lDUd6Pt8fo6THyQZxFw64gGxZ1+4Uo=; b=MgwB4gcWgmxVrnEl/9dBeINl7gWHbU4ETN+fOMRPp2J5EaPg2kfWyaAQ9U/yRQy4TU mzwRsMeWClD9fMnRinrWRl+OLx70o4dpwTLF9z32iyzOTyr8DgU0HJFfOHSepotMxpSb kqjbOzOGjHKxWYhrSdjwQG5pPlzawNhr4ITrC0qaCf4fD8zaPXNrvFR09xkYAWxTUxKc h1Iv7bcjnlY93vh0ErvjlpUBUbvaKx8q8ls7vx7taBgetvg6XxePiaYLRqBMy4gv5JtE cNG8jfgc5/6Gz/HO13xXBCRuzDHuKSnMM/kGF669g5lvAxwRlAuosUSJ3Y9rLdjpzRd5 bYNw== X-Received: by 10.204.108.196 with SMTP id g4mr8480059bkp.26.1369379285688; Fri, 24 May 2013 00:08:05 -0700 (PDT) Received: from [192.168.43.3] ([212.5.158.176]) by mx.google.com with ESMTPSA id fz10sm4010804bkc.9.2013.05.24.00.08.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 00:08:04 -0700 (PDT) Message-ID: <519F11D0.504@jitsi.org> Date: Fri, 24 May 2013 10:08:00 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <519E80E4.6010904@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnsGyT9PktY03oFVMuEXdVrVXrSeaeS2EaL/i2PW3YvAIBzCw7YtEX+MjV15/ONHD5E3emB Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 07:08:08 -0000 Hey Cullen, On 24.05.13, 01:22, Cullen Jennings (fluffy) wrote: > > > > What I had in mind was something along the lines of the following > > A is sending an offer that forks to B and C. A and B support the new > mechanisms but C does not. A has no idea if the things it is talking > to support the new thing. Exactly. > A constructs an offer that in the SDP has an indication it can > receive the header extension. Perhaps something like > "a=new-hdr-ext=123456". The new header extension allows one to embed > an identifer in the RTP packets and this SDP indicates that the > identifier should be 123456 for RTP with this mapping. OK. > A sends the offer and it arrives at both B and C. C does not > understand it and just ignores it. B understands it and inserts a TP > header extension with the identifier 123456. > > Imagine the RTP packets from B and C arrive at A before any SDP > answer. A looks at the RTP packet from B, and see the header exertion > and reads out the identifier 123456 and now knows the mapping. A > looks at the RTP packet from C and does not see the RTP header > extension so it carries on to try other things. That's it. This is the point that I am talking about. In order for A to be able to fall back to something, it needs to have attributed PTs such that they could be used for demuxing. So in other words: when constructing your offer, whatever you do, you MUST make sure that your PTs would be enough for you to match to m= lines, UNLESS you are certain that the other party would support some other mechanism for doing the same. Does this make sense? > So yes, as you point out, for the packets from C where it can't use > PT, it needs to fall back to SSRC SSRC is also a non-guaranteed approach because you don't know if C is going to pre-announce them in SDP. Emil -- https://jitsi.org From emil@sip-communicator.org Fri May 24 00:18:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CB921F957D for ; Fri, 24 May 2013 00:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFiVxmMKJuYf for ; Fri, 24 May 2013 00:18:10 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B0CDC21F955C for ; Fri, 24 May 2013 00:18:00 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id jk13so2311741bkc.29 for ; Fri, 24 May 2013 00:17:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=G0ywIdmot9uVwFgW7PPr42fvWGs6LV/ZedifDjuwQkQ=; b=kc0VY/uC6EHireReBci0fZMqw3dj8qg8UbRAw0joTS4f/xUfcSq8/4sc3it6Y8O/Yf yPl1IvpFjeGOoKbsUS2jBfyGZ8QnS+++wU0BF7951C/AuFHU2Pew9YB03CPA7Z4XOOU+ GTbshb/F97qUgIj0g0akveEomQcJ5ywAUVVdL7pNBog/XBqqqnRll4UGE10Il4+f+D4w nifslzHIsP1lxRQ3gkBAyG/xavWjgVC9YwgS/Bwx5Fw1ds6yny/sKH9XNTwa8N3luJEK F5WXhrsxNEVFT+tusYDpPf7nUi6ehdFfd82cogEPcCKGPIU141iPmKBQxvNMjD9kwdbr HxlQ== X-Received: by 10.205.45.130 with SMTP id uk2mr8555406bkb.68.1369379879610; Fri, 24 May 2013 00:17:59 -0700 (PDT) Received: from [192.168.43.3] ([212.5.158.176]) by mx.google.com with ESMTPSA id tc9sm4015838bkb.18.2013.05.24.00.17.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 00:17:58 -0700 (PDT) Message-ID: <519F1424.8020803@jitsi.org> Date: Fri, 24 May 2013 10:17:56 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> In-Reply-To: <519E9131.2080400@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnHk+wQtIRoXEdkRiQi0bRzk8xJRFpPdcAtrLsUr2fswgqDTzhSXhOZ5upSuWmQpvuDnOzL Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 07:18:11 -0000 On 24.05.13, 00:59, Paul Kyzivat wrote: > IMO the "before the O/A completes" issues are separate from the "after > the O/A completes" issues. I'm still not convinced that the "before the > O/A completes" issues are important. (We have reliable 183 responses to > deal with it.) But I'm ok with Cullen using PT to solve that problem if > he thinks he needs to. I wasn't referring to "before the O/A completes" situations. If your peer does not support fancy-RFC m-line matching nor does it provide SSRCs, you have to be able to fall back to PT demuxing. Therefore, all your offers have to accommodate for that possibility unless you know that the offer is going to someone who also supports other mechanisms. Emil -- https://jitsi.org From christer.holmberg@ericsson.com Fri May 24 01:25:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C84621F8EA6 for ; Fri, 24 May 2013 01:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGZSyxZCKgmc for ; Fri, 24 May 2013 01:24:54 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DF0DC21F8CB4 for ; Fri, 24 May 2013 01:24:53 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-7b-519f23d47451 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AB.A2.06701.4D32F915; Fri, 24 May 2013 10:24:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Fri, 24 May 2013 10:24:51 +0200 From: Christer Holmberg To: "Dale R. Worley" , Paul Kyzivat Thread-Topic: [MMUSIC] When a bundle offer is forked Thread-Index: AQHOV9u/fklHpYO4tka0o0wHa47jypkTW/u2gACjmhA= Date: Fri, 24 May 2013 08:24:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C377609@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> <201305232206.r4NM6l5C5338062@shell01.TheWorld.com> In-Reply-To: <201305232206.r4NM6l5C5338062@shell01.TheWorld.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+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre4V5fmBBk33JSymLn/MYrFiwwFW i5cnyhyYPf6+/8DkMXn/V2aPJUt+MgUwR3HZpKTmZJalFunbJXBlfNu3jb2gm79i8apO5gbG yTxdjJwcEgImEleeXWeFsMUkLtxbz9bFyMUhJHCYUWLX++dQzhJGiXf/VrJ0MXJwsAlYSHT/ 0wZpEBEIlNjWdZoVJMwsoC5xdXEQSFhYwFji36J5LBAlJhJ/2nuZIGwrifZbDYwgNouAqsTi BU1MIK28Ar4S5+dYQGzazSYxb911dpAaTgEHiZMLjoLVMwLd9v3UGrA5zALiEreezGeCuFlA Ysme88wQtqjEy8f/wM6REFCUWN4vB1GuI7Fg9yc2CFtbYtnC12DlvAKCEidnPmGZwCg2C8nU WUhaZiFpmYWkZQEjyypG9tzEzJz0cvNNjMCIObjlt8EOxk33xQ4xSnOwKInz9mlPDRQSSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXAuISlo1dFwfHOm/3T51VUsPcE57X6X/8mczLWpIzZrWCd 6R2pOV1bnXf731999LX0ivkdX0U1+55HVtdGrrpZxnRmo8bLhcHz3j1clxbcdHRlubzD1IvW 8/vn9J5oXXnTaT7/92kZT73vT14ayXJittppb993uQzi3x/urFJ8bct44fS8OQ5P1yixFGck GmoxFxUnAgDSAp5zZgIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 08:25:02 -0000 Hi, I agree with Dale. Each early dialog is handled separately. >From a standards perspective, I don't think we need to say much about forki= ng in BUNDLE, other than maybe some general words that it may happen. Then, whether it becomes tricky to implement, e.g. if one early leg uses BU= NDLE and another doesn't, is another issue. But, as SIP has mechanisms to t= erminate early dialogs you don't like etc, I see this as a pure implementat= ion issue. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Dale R. Worley Sent: 24. toukokuuta 2013 1:07 To: Paul Kyzivat Cc: mmusic@ietf.org Subject: Re: [MMUSIC] When a bundle offer is forked > From: Paul Kyzivat >=20 > On 5/23/13 6:35 AM, Emil Ivov wrote: >=20 > > In case a bundle offer gets forked and various answers ... >=20 > I trimmed everything else out of Emil's reply, and changed to subject,=20 > because this is a whole different can of worms! >=20 > I think we must acknowledge that this *can* happen, though it is a low=20 > probability event. It raises all sorts of ugly issues. A few: Is this actually complicated? That is, worse than is already the case in S= IP... My understanding is that in SIP (and this must be a SIP situation), each fo= rk proceeds with completely independent state from all other forks. The fo= rks happen to share sending/receiving ports, but the received packets can b= e demultiplexed to the correct fork based on their sending addresses. Of c= ourse, there are a range of obnoxious situations where you receive packets = before you receive a SIP response (SDP answer) that describes them, but tha= t is true in non-bundled SIP as well. Dale _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From kevindempsey70@gmail.com Fri May 24 01:40:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1A721F9619 for ; Fri, 24 May 2013 01:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.291 X-Spam-Level: X-Spam-Status: No, score=-3.291 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXF4K-52RAuq for ; Fri, 24 May 2013 01:40:18 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40D21F9588 for ; Fri, 24 May 2013 01:40:17 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id v10so4397255lbd.34 for ; Fri, 24 May 2013 01:40:17 -0700 (PDT) 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=20lDw8SwRHSsAIx09ShTggB5zAfGTd7XCQnHEUV4nFs=; b=Q38veJqBl7+MosRn+hnq1xGNbxOlodKwv3XeWUCIseD9VGbjVRwvSx/aOjncmDyAyf cmFCLTI2uyPHwlbxL1yTwutpuxMus2zd3+HNqpyyIuuFBeZDHBXgBkAg6t7v3KEZOVIp PO3L1FilmXeCWnbpWG00agm2gRwlRqZ94CBbnp9PO8eLCMtbVj8W6LQaX6/Y23VnGB7y EcryXaTKiC1GGRQFZW00UustYcWXUfPog8iHc0/gAeS34kDsux8eiYsE3m3X1ptkyfrh aWsQVw8Y5/WQePTgknRZFxEiW3Rk7YjUBjdx2Urxg++/Ss1lIC6jhqmFvVUkPQtS21u5 2BDw== MIME-Version: 1.0 X-Received: by 10.152.120.104 with SMTP id lb8mr8392262lab.11.1369384817066; Fri, 24 May 2013 01:40:17 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Fri, 24 May 2013 01:40:16 -0700 (PDT) In-Reply-To: <519F1424.8020803@jitsi.org> References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> Date: Fri, 24 May 2013 09:40:16 +0100 Message-ID: From: Kevin Dempsey To: Emil Ivov Content-Type: multipart/alternative; boundary=089e011766e795063204dd72bf58 Cc: mmusic , Paul Kyzivat Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 08:40:22 -0000 --089e011766e795063204dd72bf58 Content-Type: text/plain; charset=ISO-8859-1 Isn't the onus on the answerer to ensure the demux is possible, since it is accepting the bundle. Therefore if it doesn't support signalling SSRCs or an offerred 'fancy-RFC m-line matching' method, it must only send PTs that are tied to a single m-line. On 24 May 2013 08:17, Emil Ivov wrote: > On 24.05.13, 00:59, Paul Kyzivat wrote: > > IMO the "before the O/A completes" issues are separate from the "after > > the O/A completes" issues. I'm still not convinced that the "before the > > O/A completes" issues are important. (We have reliable 183 responses to > > deal with it.) But I'm ok with Cullen using PT to solve that problem if > > he thinks he needs to. > > I wasn't referring to "before the O/A completes" situations. If your > peer does not support fancy-RFC m-line matching nor does it provide > SSRCs, you have to be able to fall back to PT demuxing. > > Therefore, all your offers have to accommodate for that possibility > unless you know that the offer is going to someone who also supports > other mechanisms. > > Emil > > -- > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --089e011766e795063204dd72bf58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Isn't the onus on the answerer to ensure the demux is = possible, since it is accepting the bundle. Therefore if it doesn't sup= port signalling SSRCs or an offerred 'fancy-RFC m-line matching' me= thod, it must only send PTs that are tied to a single m-line.


On 24 May 201= 3 08:17, Emil Ivov <emcho@jitsi.org> wrote:
On 24.05.13, 00:59, Paul Kyzivat wrote:
> IMO the "before the O/A completes" issues are separate from = the "after
> the O/A completes" issues. I'm still not convinced that the &= quot;before the
> O/A completes" issues are important. (We have reliable 183 respon= ses to
> deal with it.) But I'm ok with Cullen using PT to solve that probl= em if
> he thinks he needs to.

I wasn't referring to "before the O/A completes" situat= ions. If your
peer does not support fancy-RFC m-line matching nor does it provide
SSRCs, you have to be able to fall back to PT demuxing.

Therefore, all your offers have to accommodate for that possibility
unless you know that the offer is going to someone who also supports
other mechanisms.

Emil

--
https://jitsi.org
_____________________= __________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--089e011766e795063204dd72bf58-- From emil@sip-communicator.org Fri May 24 01:59:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6B521F96C9 for ; Fri, 24 May 2013 01:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msL-eLctFLVl for ; Fri, 24 May 2013 01:59:11 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4736D21F968D for ; Fri, 24 May 2013 01:59:10 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id my13so2395986bkb.19 for ; Fri, 24 May 2013 01:59:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=cYWFThU9nVnBNUjCqYZbS7cxA/DcQA8fPwNTD+O0Qhc=; b=AsHrRdFXXoCU6HcJ2ozhsj39JO7CzWD+VKlsLZjboV5VbWnPx0PS1gHnhscIZFIN44 wz2BlrdExWoQ/YRydkFHA9B0klQISqyWCsJVsJS2v8ItlAEzOwQAlC10+Riy21186owU 2Mq4Td7+lO49XHUY+pXOhXT6CABB/9azr5pTlpWjPstOb777wSWB4coB/2dxwnRTSmU3 5BDEzCOfniatD+5+lFHJWrI6V2Yliq2za3YV2LPLtPs0yMeD9sR0AGLPZ4ePofK200w3 JutJPmXjhz2yxe7ObM1nmnpHFIdeTVBvmJKIZnguUzxF53G1IpnhEv7l/MST2gstv8Ui 1XFQ== X-Received: by 10.205.103.67 with SMTP id dh3mr8727342bkc.19.1369385949950; Fri, 24 May 2013 01:59:09 -0700 (PDT) Received: from [192.168.43.3] ([212.5.158.176]) by mx.google.com with ESMTPSA id tc9sm4116303bkb.18.2013.05.24.01.59.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 01:59:09 -0700 (PDT) Message-ID: <519F2BD8.8060803@jitsi.org> Date: Fri, 24 May 2013 11:59:04 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kevin Dempsey References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm3Kg+S0IWu0QfOxi/bF3yQQrr5Auav/d21a279GtnTp8s2kKZVDPZVovfnRrpZntJRGTvG Cc: mmusic , Paul Kyzivat Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 08:59:14 -0000 On 24.05.13, 11:40, Kevin Dempsey wrote: > Isn't the onus on the answerer to ensure the demux is possible, since it > is accepting the bundle. Therefore if it doesn't support signalling > SSRCs or an offerred 'fancy-RFC m-line matching' method, it must only > send PTs that are tied to a single m-line. PTs are defined by the offerer. The answerer cannot change them for the offerer-bound direction (even if it could request different values for the packets that it, the answerer, is going to receive). Emil > > > On 24 May 2013 08:17, Emil Ivov > wrote: > > On 24.05.13, 00:59, Paul Kyzivat wrote: > > IMO the "before the O/A completes" issues are separate from the "after > > the O/A completes" issues. I'm still not convinced that the > "before the > > O/A completes" issues are important. (We have reliable 183 > responses to > > deal with it.) But I'm ok with Cullen using PT to solve that > problem if > > he thinks he needs to. > > I wasn't referring to "before the O/A completes" situations. If your > peer does not support fancy-RFC m-line matching nor does it provide > SSRCs, you have to be able to fall back to PT demuxing. > > Therefore, all your offers have to accommodate for that possibility > unless you know that the offer is going to someone who also supports > other mechanisms. > > Emil > > -- > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- https://jitsi.org From kevindempsey70@gmail.com Fri May 24 02:03:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DD721F9681 for ; Fri, 24 May 2013 02:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4SIJEQfChNc for ; Fri, 24 May 2013 02:02:59 -0700 (PDT) Received: from mail-la0-x243.google.com (mail-la0-x243.google.com [IPv6:2a00:1450:4010:c03::243]) by ietfa.amsl.com (Postfix) with ESMTP id 324E821F968D for ; Fri, 24 May 2013 02:02:56 -0700 (PDT) Received: by mail-la0-f67.google.com with SMTP id fq12so1083459lab.6 for ; Fri, 24 May 2013 02:02:55 -0700 (PDT) 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=v0bcmk8aYoFaCKgjydPxpHBezfhvn+RjDvz7b5In7gw=; b=NgJqzvmwSAbmwboe8DlX5VkeGM8owUyNdJGbfhj/8iFd85UNY6c3qHpTsQTvVuvaBF 62f7fPXpk4aHPlyfay9v1K2w9tWpmaZt1jZTDYJpTxQ+Aq9tk3QCnzoZb0pa6NSw2QvT rPGAuv0OSgcqPaXyuSo8VF313jJ0dQJN5MSHmOqt9JksyxbI5qDBGlBRh/0oPpAAgsu6 mIGpfJPBgWLHibdz8o2aH5gc6XdZlonMlajg+QoI9giSFNRRp1lzE3ZWKSfRrPcq6WLM 4/4c+cw0tcbutIHCW7k4NUjWVy5m/MTP5ltZJvbk66Oj/qvt4CtY1GSlagpGjIE9A4os KdSQ== MIME-Version: 1.0 X-Received: by 10.112.6.6 with SMTP id w6mr8314292lbw.123.1369386175802; Fri, 24 May 2013 02:02:55 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Fri, 24 May 2013 02:02:55 -0700 (PDT) In-Reply-To: <519F2BD8.8060803@jitsi.org> References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> <519F2BD8.8060803@jitsi.org> Date: Fri, 24 May 2013 10:02:55 +0100 Message-ID: From: Kevin Dempsey To: Emil Ivov Content-Type: multipart/alternative; boundary=14dae93d973691b3d304dd7310ce Cc: mmusic , Paul Kyzivat Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:03:00 -0000 --14dae93d973691b3d304dd7310ce Content-Type: text/plain; charset=ISO-8859-1 I didn't say anything about changing the PTs. The answerer decides what it codecs it will use from the ones listed in the offer. If it doesn't support any other mechanism to allow demux then it must choose codecs that have PTs on only one m-line, or not accept the BUNDLE. On 24 May 2013 09:59, Emil Ivov wrote: > On 24.05.13, 11:40, Kevin Dempsey wrote: > > Isn't the onus on the answerer to ensure the demux is possible, since it > > is accepting the bundle. Therefore if it doesn't support signalling > > SSRCs or an offerred 'fancy-RFC m-line matching' method, it must only > > send PTs that are tied to a single m-line. > > PTs are defined by the offerer. The answerer cannot change them for the > offerer-bound direction (even if it could request different values for > the packets that it, the answerer, is going to receive). > > Emil > > > > > > > > On 24 May 2013 08:17, Emil Ivov > > wrote: > > > > On 24.05.13, 00:59, Paul Kyzivat wrote: > > > IMO the "before the O/A completes" issues are separate from the > "after > > > the O/A completes" issues. I'm still not convinced that the > > "before the > > > O/A completes" issues are important. (We have reliable 183 > > responses to > > > deal with it.) But I'm ok with Cullen using PT to solve that > > problem if > > > he thinks he needs to. > > > > I wasn't referring to "before the O/A completes" situations. If your > > peer does not support fancy-RFC m-line matching nor does it provide > > SSRCs, you have to be able to fall back to PT demuxing. > > > > Therefore, all your offers have to accommodate for that possibility > > unless you know that the offer is going to someone who also supports > > other mechanisms. > > > > Emil > > > > -- > > https://jitsi.org > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > -- > https://jitsi.org > --14dae93d973691b3d304dd7310ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I didn't say anything about changing the PTs. The answ= erer decides what it codecs it will use from the ones listed in the offer. = If it doesn't support any other mechanism to allow demux then it must c= hoose codecs that have PTs on only one m-line, or not accept the BUNDLE.


On 24 May 201= 3 09:59, Emil Ivov <emcho@jitsi.org> wrote:
On 24.05.13, 11:40, Kevin Dempsey wrote:
> Isn't the onus on the answerer to ensure the demux is possible, si= nce it
> is accepting the bundle. Therefore if it doesn't support signallin= g
> SSRCs or an offerred 'fancy-RFC m-line matching' method, it mu= st only
> send PTs that are tied to a single m-line.

PTs are defined by the offerer. The answerer cannot change them for t= he
offerer-bound direction (even if it could request different values for
the packets that it, the answerer, is going to receive).

Emil


>
>
> On 24 May 2013 08:17, Emil Ivov <emcho@jitsi.org
> <mailto:= emcho@jitsi.org>> wrote:
>
> =A0 =A0 On 24.05.13, 00:59, Paul Kyzivat wrote:
> =A0 =A0 > IMO the "before the O/A completes" issues are s= eparate from the "after
> =A0 =A0 > the O/A completes" issues. I'm still not convinc= ed that the
> =A0 =A0 "before the
> =A0 =A0 > O/A completes" issues are important. (We have reliab= le 183
> =A0 =A0 responses to
> =A0 =A0 > deal with it.) But I'm ok with Cullen using PT to sol= ve that
> =A0 =A0 problem if
> =A0 =A0 > he thinks he needs to.
>
> =A0 =A0 I wasn't referring to "before the O/A completes"= situations. If your
> =A0 =A0 peer does not support fancy-RFC m-line matching nor does it pr= ovide
> =A0 =A0 SSRCs, you have to be able to fall back to PT demuxing.
>
> =A0 =A0 Therefore, all your offers have to accommodate for that possib= ility
> =A0 =A0 unless you know that the offer is going to someone who also su= pports
> =A0 =A0 other mechanisms.
>
> =A0 =A0 Emil
>
> =A0 =A0 --
> =A0 =A0 https://jitsi.= org
> =A0 =A0 _______________________________________________
> =A0 =A0 mmusic mailing list
> =A0 =A0 mmusic@ietf.org &= lt;mailto:mmusic@ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/mmusic
>
>

--
https://jitsi.org

--14dae93d973691b3d304dd7310ce-- From emil@sip-communicator.org Fri May 24 02:15:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9654B21F8B07 for ; Fri, 24 May 2013 02:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xQNTDfH40TE for ; Fri, 24 May 2013 02:15:01 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA0A21F89E2 for ; Fri, 24 May 2013 02:14:56 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id jf20so883183bkc.7 for ; Fri, 24 May 2013 02:14:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=PpRI5+ZSz2NAAFbYAiCWBVR3ZPL8GZ5akFRjTdjfOoY=; b=TwJM9kmVyx7K97+KhIm8qOu8NI2s/U7wwyJ+bJUcI3r4OAiMIcoxdwk03mKTPVAQ3r maDOjjvE7nLbk8Ye2v1s4Olo+opFEUa1wwKz5oFkizdLXCSDXFWuuW7at67vyFXM/Olh iuIpIUR3/t7Xvf7BsREQ88ScaOb3sghoaJXvJbRdUCWUv9otDJLdCWJw7Z/lzzckPj47 kgNRonayILejh8XfNvSHxS1hETTj5GN4NEjsOo7jPZh6LWvLwoQc2uO3k2NNGC2PrGZO wEgVLoG5GRLXZYNxUnOJe3NZ5ZDZozyZMOzI5XmdJIxWLriuGYCMCLhWaasXFfhJONnG 69OA== X-Received: by 10.204.57.13 with SMTP id a13mr8953607bkh.63.1369386896037; Fri, 24 May 2013 02:14:56 -0700 (PDT) Received: from [192.168.43.3] ([212.5.158.176]) by mx.google.com with ESMTPSA id b12sm4142026bkz.0.2013.05.24.02.14.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 02:14:55 -0700 (PDT) Message-ID: <519F2F8B.5080004@jitsi.org> Date: Fri, 24 May 2013 12:14:51 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kevin Dempsey References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> <519F2BD8.8060803@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkDxXl6AQxY9rKDUPy74NqeUmPfZY9N0StSXmFUEmrZhoL+Hzn0NI85AwY8lSoiVhM4aqoo Cc: mmusic , Paul Kyzivat Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:15:02 -0000 On 24.05.13, 12:02, Kevin Dempsey wrote: > I didn't say anything about changing the PTs. Sorry, I misunderstood. > The answerer decides what > it codecs it will use from the ones listed in the offer. If it doesn't > support any other mechanism to allow demux then it must choose codecs > that have PTs on only one m-line, or not accept the BUNDLE. Matching packets to m= lines is the concern of the receiving party. So is the mechanism that it uses. What you are suggesting is for the answerer to basically say: "It seems to me that you won't be able to demux these two payloads so I will not send them to you because I know better". In the same time the offerer may be planning on using a demux technique that the answerer simply isn't aware of. For example (and this is really just to make a point, so please don't assume I am suggesting something like this in general) if 101 is mapped to both telephone-event and VP8, demuxing can be easily made without any other knowledge of SSRC or header extensions. Cheers, Emil > > > On 24 May 2013 09:59, Emil Ivov > wrote: > > On 24.05.13, 11:40, Kevin Dempsey wrote: > > Isn't the onus on the answerer to ensure the demux is possible, > since it > > is accepting the bundle. Therefore if it doesn't support signalling > > SSRCs or an offerred 'fancy-RFC m-line matching' method, it must only > > send PTs that are tied to a single m-line. > > PTs are defined by the offerer. The answerer cannot change them for the > offerer-bound direction (even if it could request different values for > the packets that it, the answerer, is going to receive). > > Emil > > > > > > > > On 24 May 2013 08:17, Emil Ivov > > >> wrote: > > > > On 24.05.13, 00:59, Paul Kyzivat wrote: > > > IMO the "before the O/A completes" issues are separate from > the "after > > > the O/A completes" issues. I'm still not convinced that the > > "before the > > > O/A completes" issues are important. (We have reliable 183 > > responses to > > > deal with it.) But I'm ok with Cullen using PT to solve that > > problem if > > > he thinks he needs to. > > > > I wasn't referring to "before the O/A completes" situations. > If your > > peer does not support fancy-RFC m-line matching nor does it > provide > > SSRCs, you have to be able to fall back to PT demuxing. > > > > Therefore, all your offers have to accommodate for that > possibility > > unless you know that the offer is going to someone who also > supports > > other mechanisms. > > > > Emil > > > > -- > > https://jitsi.org > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > -- > https://jitsi.org > > -- https://jitsi.org From christer.holmberg@ericsson.com Fri May 24 03:05:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A609E21F9610 for ; Fri, 24 May 2013 03:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.105 X-Spam-Level: X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXP8Ed3V7nXy for ; Fri, 24 May 2013 03:05:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ABFFB21F8BC0 for ; Fri, 24 May 2013 03:05:46 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-66-519f3b790756 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 49.4F.28930.97B3F915; Fri, 24 May 2013 12:05:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Fri, 24 May 2013 12:05:44 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: 3GPP RTP header extension Thread-Index: Ac5YY467f6iD3KE+RZKtUYPDcgGk6w== Date: Fri, 24 May 2013 10:05:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C377766@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C377766ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+JvrW6l9fxAg9PLNCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKs7W9gKXktXbPp4hKmB8aJEFyMnh4SAicTX69vZIGwxiQv3 1oPZQgKHGSV+95V2MXIB2UsYJe5tuwWU4OBgE7CQ6P6nDVIjIqAu8XVvDzNIWFhASeLHbnWY 8L3VZ1lAwiICehJPuzJAwiwCqhJbbj0Hm84r4Ctx5cRcJhCbEWjr91NrwGxmAXGJW0/mM0Fc IyCxZM95ZghbVOLl43+sICMlBBQllvfLQZTnS3x/NpURYqSgxMmZT1gmMArNQjJpFpKyWUjK IOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG9tzEzJz0csNNjMBwP7jlt+4OxlPnRA4x SnOwKInz9mpPDRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6HbkXbZI0ZpuV9M9wc09v18m FjQu2f9vW1OC95yfVnfrmM7me7Tc/6XhmMov7HdLQqH4bUzC3sOZNbkv/wfUPfl/0VksdIHN k7n3ToiknT6u9+tE1osnS22+5GhZTzVxV6xdI++x95jfq9j7estXdoXKvA05wSBX8+7rglnx J/h2TN3bxPVQUomlOCPRUIu5qDgRABt90m5FAgAA Subject: [MMUSIC] 3GPP RTP header extension X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 10:05:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C377766ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In the virtual interim meeting yesterday, I was requested to look into the = RTP header extension(s) defined by 3GPP. 3GPP SA4 has defined a header extension for "Coordination of Video Orientat= ion" purpose (may be of interest for CLUE btw, but that's a separate story)= . The length of the extension is 1 byte. For more information, see section 7.4.5 of 3GPP TS 24.114 :) http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-c10.zip Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C377766ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In the virtual interim meeting yesterday, I was requ= ested to look into the RTP header extension(s) defined by 3GPP.<= /p>

 

3GPP SA4 has defined a header extension for “C= oordination of Video Orientation” purpose (may be of interest for CLU= E btw, but that’s a separate story). The length of the extension is 1= byte.

 

For more information, see section 7.4.5 of 3GPP TS 2= 4.114 :)

 

http://www.3gpp.org/ftp/Specs/archive/26_serie= s/26.114/26114-c10.zip

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C377766ESESSMB209erics_-- From gonzalo.camarillo@ericsson.com Fri May 24 03:21:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9937321F960F for ; Fri, 24 May 2013 03:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.053 X-Spam-Level: X-Spam-Status: No, score=-106.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+0EDZUdzD-6 for ; Fri, 24 May 2013 03:21:45 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 47A3321F96B7 for ; Fri, 24 May 2013 03:21:40 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-f8-519f3f339f58 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BC.08.06701.33F3F915; Fri, 24 May 2013 12:21:39 +0200 (CEST) Received: from [131.160.36.24] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 24 May 2013 12:21:38 +0200 Message-ID: <519F3F32.5010908@ericsson.com> Date: Fri, 24 May 2013 13:21:38 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Magnus Westerlund References: <20130521192043.28957.35761.idtracker@ietfa.amsl.com> <519DD209.3010100@ericsson.com> In-Reply-To: <519DD209.3010100@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3VtfYfn6gwbWb0hZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpOlK1kKJgpWfLuwgr2B8TxvFyMnh4SAicSThhNMELaYxIV7 69m6GLk4hAROMUpsfj6dEcJZzSgx/dIJ5i5GDg5eAW2J3c9lQEwWAVWJ9acDQXrZBCwktty6 zwJiiwpEScxZ94ANxOYVEJQ4OfMJWFxEwEzi4YT9YHFmAXWJnt8tzCC2sECdxMa9x1hBbCGB RInZXZPA7uEU0JE4fnYy1G2SEltetLND9OpJTLnawghhy0tsfzuHGaJXW2L5sxaWCYxCs5Cs noWkZRaSlgWMzKsY2XMTM3PSy803MQKD8uCW3wY7GDfdFzvEKM3BoiTO26c9NVBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDI7v1RJZbj5411ks5Zp/aIXP1zsZP1zanBy3mY7p178ihSUka 67dJTT3554OeU8HrHfNK11ze2V4edPlM10xWrh7trz3Slxs/fFBcmDwvp8hpbry7yK5dZre/ yR7odL3k8XryatPzF9bsv7zTpmKZyPJo1i0P+SdvjIhY27Ul91hPmn7vVaXi1GwlluKMREMt 5qLiRABiDQ/oGAIAAA== Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Last Call: (Real Time Streaming Protocol 2.0 (RTSP)) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 10:21:50 -0000 Thanks for the heads up, Magnus. Gonzalo On 23/05/2013 11:23 AM, Magnus Westerlund wrote: > WG and AD, > > We authors have received private feedback about some editorial issues. > We intended to address these at the end of the IETF last call. So don't > be surprised by yet another revision. > > Cheers > > Magnus > > On 2013-05-21 21:20, The IESG wrote: >> >> The IESG has received a request from the Multiparty Multimedia Session >> Control WG (mmusic) to consider the following document: >> - 'Real Time Streaming Protocol 2.0 (RTSP)' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-06-04. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> 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-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). >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ballot/ >> >> >> The following IPR Declarations may be related to this I-D: >> >> http://datatracker.ietf.org/ipr/2028/ >> http://datatracker.ietf.org/ipr/1189/ >> >> >> >> >> > > From christer.holmberg@ericsson.com Fri May 24 03:28:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1A421F8EA4 for ; Fri, 24 May 2013 03:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.808 X-Spam-Level: X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd7sLrdnipwI for ; Fri, 24 May 2013 03:28:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9841521F8EFE for ; Fri, 24 May 2013 03:28:37 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-d1-519f40d45a96 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A1.7A.31782.4D04F915; Fri, 24 May 2013 12:28:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Fri, 24 May 2013 12:28:35 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between Thread-Index: Ac5YZ89eNSNKdC6FQhCoA7qw0p8XLA== Date: Fri, 24 May 2013 10:28:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3777C9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3777C9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvre4Vh/mBBkeeK1tMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGduWX2QpuKhasWUVVwPjUYUuRg4OCQETibfbxbsYOYFMMYkL 99azdTFycQgJHGaUuHv2OyOEs4RR4tG1dhaQBjYBC4nuf9ogDSIC6hJf9/Ywg9jCAmESx27s Z4eIR0s8nHIHytaTOLFuGiOIzSKgKvHrx102EJtXwFdiRv8PMJsRaPH3U2uYQGxmAXGJW0/m M0EcJCCxZM95ZghbVOLl43+sEDcrSizvl4Moz5eY2f6OFWKkoMTJmU9YJjAKzUIyaRaSsllI yiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HKjTYzAgD+45bfqDsY750QO MUpzsCiJ8/ZqTw0UEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKiwPmbjsr+OmwSdTntbtN/d 9DV5scTvW6Kf37gmPy+bW39P04PPfOKxl2cv7kqz3rznmZDkkWcPGsp/7W2eVl7VNvfRvvtf rYtnOvza7FkzaerBUrmnvNvnJTRaft3Qc6++9tjnRmVZsXlbdwn8S7JUlNcS2/a11TDk4s0N bu3G92XDb+go9i5XYinOSDTUYi4qTgQAg1Hpc0YCAAA= Subject: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 10:28:44 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3777C9ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the interim yesterday, we agreed that an answerer MUST always include id= entical ports* (usage of port zero within a bundle is a separate topic) for= all m- lines within an bundle group. If the answerer wants to use different ports* for some/all m- lines, it MUS= T NOT include those m- lines in a bundle group (if they already are in a bu= ndle group, a separate offer is needed to remove them). WHAT IT MEANS: There is no way for an answerer to tell that the offerer, fo= r certain m- lines, can use the same port*, eventhough the answer will use = separate ports*. I will work on some actual text proposal later, but please indicate if you = OBJECT to this approach in general. Regards, Christer NOTE: "port" =3D port:address combination - we are working on coming up wit= h better terminology :) --_000_7594FB04B1934943A5C02806D1A2204B1C3777C9ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

At the interim yesterday, we agreed that an answerer= MUST always include identical ports* (usage of port zero within a bundle i= s a separate topic) for all m- lines within an bundle group.

 

If the answerer wants to use different ports* for so= me/all m- lines, it MUST NOT include those m- lines in a bundle group (if t= hey already are in a bundle group, a separate offer is needed to remove the= m).

 

WHAT IT MEANS: There is no way for an answerer to te= ll that the offerer, for certain m- lines, can use the same port*, eventhou= gh the answer will use separate ports*.

 

I will work on some actual text proposal later, but = please indicate if you OBJECT to this approach in general.

 

Regards,

 

Christer

 

NOTE: “port” =3D port:address combinatio= n – we are working on coming up with better terminology J

 

 

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C3777C9ESESSMB209erics_-- From christer.holmberg@ericsson.com Fri May 24 05:32:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7319F21F9260 for ; Fri, 24 May 2013 05:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0Z7zb8O7LZg for ; Fri, 24 May 2013 05:32:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5931D21F918C for ; Fri, 24 May 2013 05:32:39 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-9a-519f5de65592 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 39.BD.06701.6ED5F915; Fri, 24 May 2013 14:32:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Fri, 24 May 2013 14:32:37 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE DECISSION: SDP Answer Restrictions Thread-Index: Ac5YdJNWNYfYqobOTueV815jNgS21w== Date: Fri, 24 May 2013 12:32:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C377967ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvre6z2PmBBj2rpCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIm/9rAXLPetWLD/HGMD4xenLkZODgkBE4nX0zYxQdhiEhfu rWfrYuTiEBI4zCjR+vIfG0hCSGAJo0RDv0AXIwcHm4CFRPc/bZCwiIC6xNe9PcwgtrCAkcSh vofsEHFzibWbZrFC2HoSJ/9OBLNZBFQl/vU8ZwSxeQV8JTqaHoH1MgLt/X5qDdgNzALiEree zIe6R0BiyZ7zzBC2qMTLx/9YQU6QEFCUWN4vB1GeL/GwfRUzxEhBiZMzn7BMYBSahWTSLCRl s5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWM7LmJmTnp5eabGIEhf3DLb4MdjJvu ix1ilOZgURLn7dOeGigkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcSVH6UN9flspr3tX4uxf TQyq9XD41GnfrWM7NfhSy+s/U+Mq5/UXdaYee1O0c45I566nOl0Td/5/+K/y6vJdj9Me3eY9 Ka/sVh1wq/zSVpG3qQu6PdVFfifPniwfPvdQ7cLj9wx2qKb+mcxzoJbd8fws2wiWni+SVcej O0yM5JzVvv34v3ePhBJLcUaioRZzUXEiAFYbal5HAgAA Subject: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 12:32:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C377967ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the interim meeting yesterday, we agreed on some restrictions regarding = creating SDP answers containing bundle group(s). Note that the restrictions 1-3 are simply alignments with RFC 5888, and are= listed simply for clarification purpose. Restrictions 4 is BUNDLE specific= . Restriction 5 is also alignment with RFC 5888, as m- lines with port zero= are not allowed within groups, but we will need some clarification text sa= ying that a new offer will have to be sent in order to remove a stream (eit= her from a bundle group, or completely from the session). (Note that the text below is not necessarily the wording that will go into = the draft) In an SDP answer: 1) a BUNDLE group MUST NOT be created, unless it was included in the a= ssociated offer 2) an m- line MUST NOT be added to a BUNDLE group, unless it was inclu= ded in a BUNDLE group in the associated offer 3) an m- line MUST NOT be added to another BUNDLE group than the group= in which was included in the associated offer 4) an m- line MUST NOT be removed from a BUNDLE group if, in the assoc= iated offer, an identical port number was indicated for all m- lines in a B= UNDLE group 5) an m- line MUST NOT be rejected if, in the associated offer, an ide= ntical port number was indicated for all m- lines in a BUNDLE group Note that there is also a discussion regarding bundle offers, e.g. when res= trictions when adding new m- lines to a bundle. Based on the outcome of tha= t, there may be some additional answer restrictions, e.g. regarding the cha= nge of bundle transport parameters. But, let's deal with that in the offer = thread. So, if anyone OBJECTS to the restrictions above, please indicate so. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C377967ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

At the interim meeting yesterday, we agreed on some = restrictions regarding creating SDP answers containing bundle group(s).

 

Note that the restrictions 1-3 are simply alignments= with RFC 5888, and are listed simply for clarification purpose. Restrictio= ns 4 is BUNDLE specific. Restriction 5 is also alignment with RFC 5888, as = m- lines with port zero are not allowed within groups, but we will need some clarification text saying that a new = offer will have to be sent in order to remove a stream (either from a bundl= e group, or completely from the session).

 

(Note that the text below is not necessarily the wor= ding that will go into the draft)

 

In an SDP answer:

1)      a BUNDLE group MUST NOT be created, unless it was i= ncluded in the associated offer

2)      an m- line MUST NOT be added to a BUNDLE group, unl= ess it was included in a BUNDLE group in the associated offer

3)      an m- line MUST NOT be added to another BUNDLE grou= p than the group in which was included in the associated offer

4)      an m- line MUST NOT be removed from a BUNDLE group = if, in the associated offer, an identical port number was indicated for all= m- lines in a BUNDLE group

5)      an m- line MUST NOT be rejected if, in the associat= ed offer, an identical port number was indicated for all m- lines in a BUND= LE group

 

 

Note that there is also a discussion regarding bundl= e offers, e.g. when restrictions when adding new m- lines to a bundle. Base= d on the outcome of that, there may be some additional answer restrictions,= e.g. regarding the change of bundle transport parameters. But, let’s deal with that in the offer thread.=

 

So, if anyone OBJECTS to the restrictions above, ple= ase indicate so.

 

Regards,

 

Christer

 

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C377967ESESSMB209erics_-- From christer.holmberg@ericsson.com Fri May 24 05:39:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB06421F943A for ; Fri, 24 May 2013 05:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.069 X-Spam-Level: X-Spam-Status: No, score=-5.069 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFlacL7JxENX for ; Fri, 24 May 2013 05:39:29 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F097421F93F4 for ; Fri, 24 May 2013 05:39:25 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-b5-519f5f7cb766 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6B.5F.31782.C7F5F915; Fri, 24 May 2013 14:39:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Fri, 24 May 2013 14:39:24 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE ALMOST DECISSION: BUNDLE PORT Thread-Index: Ac5Yevnd5lghFfM/QmuiU1fEkjXC+Q== Date: Fri, 24 May 2013 12:39:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C37797EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+JvrW5t/PxAg3XXWCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIkfb7EWbFKp+PetmbmBcZ18FyMnh4SAicTlW2/YIWwxiQv3 1rN1MXJxCAkcZpS43vGLpYuRA8hZwijx2hfEZBOwkOj+pw1SLiKgLvF1bw8ziC0soCtxYsVb Zoi4kcSnFU+hbD2Jcy0zwMazCKhKXN2xmBVkDK+Ar8Tf5mqQMCPQ1u+n1jCB2MwC4hK3nsxn grhGQGLJnvPMELaoxMvH/8BaJQQUJZb3y0GU50uc+P+PDcTmFRCUODnzCcsERqFZSCbNQlI2 C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XInpuYmZNebrSJERjuB7f8Vt3BeOec yCFGaQ4WJXHeXu2pgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYFyrOaOT+HMdusrHj+kpZ zmmt7m3h7F0tNqbLf1kHvPOs6ZF4rv2heNmL6WFR7m1x15kXvczfFndvpvc3mSkS2VrK7i9X WBl/V395bLmIe8FmO5krO//taRa4vauE/W8gw4dDPU+FN4Tbvft/YuG1b1d0u/65bLhcVO3V vOah/c0za5VtmsIuKbEUZyQaajEXFScCAEYZ3gpFAgAA Subject: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 12:39:35 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C37797EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the interim yesterday, we agreed to use the SDP BUNDLE group attribute t= o indicate on which port bundled media will be sent. In an SDP offer, the o= rder of the attribute mid values can be used by the offerer to indicate a "= wish", but the first attribute mid value in the answer indicates where the = answerer will eventually send bundled media. The main usage of this is the "initial offer", when each m- line within a b= undle group has a different port value. So far so good. The reason I say "almost decision" is because we have started a new discuss= ion regarding updated offers, adding new m- lines etc. We need to make sure= that the order-to-mid-values semantics also apply to those, and what restr= ictions there are when adding m- lines. But, for now, if you OBJECT to the general principle of using the SDP group= attribute mid value order for indicating the port where media will be sent= , please indicate so. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C37797EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

At the interim yesterday, we agreed to use the SDP B= UNDLE group attribute to indicate on which port bundled media will be sent.= In an SDP offer, the order of the attribute mid values can be used by the = offerer to indicate a “wish”, but the first attribute mid value in the answer indicates where the answerer w= ill eventually send bundled media.

 

The main usage of this is the “initial offer&#= 8221;, when each m- line within a bundle group has a different port value.<= o:p>

 

So far so good.

 

The reason I say “almost decision” is be= cause we have started a new discussion regarding updated offers, adding new= m- lines etc. We need to make sure that the order-to-mid-values semantics = also apply to those, and what restrictions there are when adding m- lines.

 

But, for now, if you OBJECT to the general principle= of using the SDP group attribute mid value order for indicating the port w= here media will be sent, please indicate so.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C37797EESESSMB209erics_-- From pkyzivat@alum.mit.edu Fri May 24 07:16:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342E521F8F43 for ; Fri, 24 May 2013 07:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H61iGFjNU9sj for ; Fri, 24 May 2013 07:16:20 -0700 (PDT) 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 B1B2121F8F20 for ; Fri, 24 May 2013 07:16:20 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta15.westchester.pa.mail.comcast.net with comcast id fnMQ1l0060QuhwU5FqGLgH; Fri, 24 May 2013 14:16:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id fqGK1l01T3ZTu2S3NqGLF2; Fri, 24 May 2013 14:16:20 +0000 Message-ID: <519F7633.1010902@alum.mit.edu> Date: Fri, 24 May 2013 10:16:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> <519F2BD8.8060803@jitsi.org> <519F2F8B.5080004@jitsi.org> In-Reply-To: <519F2F8B.5080004@jitsi.org> 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=1369404980; bh=nN7JlXQu8TBe+IDUb//Ld/Et+9YKMSHsaRI9Q73WKvM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VWD+/3TdJpu7IqWJL/FWDR0jFBsIduvXgMbtBm9RNFbGKsOnM69epn1BfE4Bkhr1J diseZlRRD79I4R1cs9r4hGtuU0VRRuHwLAqIJhjligR9vbGZNpeDZdL3cCz+UBscCu dAOe7JiEEF2Jc8eFoJlZxYZ3E4QFT2sOv119qu0sgqlj+AGqxYJE14XSh5H2YQu3AC GZLYTSFNHgYdkPY9pOiCSFlycu+LiAFKJmXHN5neKeSLr9XRKqeRXNCoxoj2Ua0PCx A7I6cqBYwwhwz64VycsYseromSj8QURDoPMCCfUdYcmKBRai2Yh7lCPP/CpuyjJxOW IqJfqp5KdZKGA== Cc: mmusic Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 14:16:25 -0000 On 5/24/13 5:14 AM, Emil Ivov wrote: > On 24.05.13, 12:02, Kevin Dempsey wrote: >> I didn't say anything about changing the PTs. > > Sorry, I misunderstood. > >> The answerer decides what >> it codecs it will use from the ones listed in the offer. If it doesn't >> support any other mechanism to allow demux then it must choose codecs >> that have PTs on only one m-line, or not accept the BUNDLE. > > Matching packets to m= lines is the concern of the receiving party. So > is the mechanism that it uses. What you are suggesting is for the > answerer to basically say: "It seems to me that you won't be able to > demux these two payloads so I will not send them to you because I know > better". > > In the same time the offerer may be planning on using a demux technique > that the answerer simply isn't aware of. For example (and this is really > just to make a point, so please don't assume I am suggesting something > like this in general) if 101 is mapped to both telephone-event and VP8, > demuxing can be easily made without any other knowledge of SSRC or > header extensions. ISTM that after the O/A exchange both sides need to have a common understanding that their communications will be understandable. If the combination of the offer and answer aren't sufficient for each side to encode what it sends in a way that it knows can be demuxed according in accord with the O/A, then that offer should be incorrect. IMO injecting "magic" into this isn't helpful. Thanks, Paul > Cheers, > Emil > > >> >> >> On 24 May 2013 09:59, Emil Ivov > > wrote: >> >> On 24.05.13, 11:40, Kevin Dempsey wrote: >> > Isn't the onus on the answerer to ensure the demux is possible, >> since it >> > is accepting the bundle. Therefore if it doesn't support signalling >> > SSRCs or an offerred 'fancy-RFC m-line matching' method, it must only >> > send PTs that are tied to a single m-line. >> >> PTs are defined by the offerer. The answerer cannot change them for the >> offerer-bound direction (even if it could request different values for >> the packets that it, the answerer, is going to receive). >> >> Emil >> >> >> > >> > >> > On 24 May 2013 08:17, Emil Ivov > >> > >> wrote: >> > >> > On 24.05.13, 00:59, Paul Kyzivat wrote: >> > > IMO the "before the O/A completes" issues are separate from >> the "after >> > > the O/A completes" issues. I'm still not convinced that the >> > "before the >> > > O/A completes" issues are important. (We have reliable 183 >> > responses to >> > > deal with it.) But I'm ok with Cullen using PT to solve that >> > problem if >> > > he thinks he needs to. >> > >> > I wasn't referring to "before the O/A completes" situations. >> If your >> > peer does not support fancy-RFC m-line matching nor does it >> provide >> > SSRCs, you have to be able to fall back to PT demuxing. >> > >> > Therefore, all your offers have to accommodate for that >> possibility >> > unless you know that the offer is going to someone who also >> supports >> > other mechanisms. >> > >> > Emil >> > >> > -- >> > https://jitsi.org >> > _______________________________________________ >> > mmusic mailing list >> > mmusic@ietf.org >> > >> > https://www.ietf.org/mailman/listinfo/mmusic >> > >> > >> >> -- >> https://jitsi.org >> >> > From pkyzivat@alum.mit.edu Fri May 24 07:23:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB5C21F90E0 for ; Fri, 24 May 2013 07:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVbChuLAtrJ5 for ; Fri, 24 May 2013 07:23:40 -0700 (PDT) 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 D57E521F8E06 for ; Fri, 24 May 2013 07:23:39 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id fmNz1l0011YDfWL53qPcZE; Fri, 24 May 2013 14:23:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id fqPb1l0113ZTu2S3gqPbKn; Fri, 24 May 2013 14:23:36 +0000 Message-ID: <519F77E6.50802@alum.mit.edu> Date: Fri, 24 May 2013 10:23:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <519E6265.4090102@alum.mit.edu> <519E8B58.9030604@alum.mit.edu> In-Reply-To: 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=1369405416; bh=VMO3mTPjYZxmkAus8hyXEJkNkSqsXMGuUjcAAniaaM0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dtkWZY+ShcVUyOtNfAU3kTW0Qvvbo4BESQXcCEM826LwuH+9d8twigiQ/Ozz5GLLq mYCO5dAUH31/ZOqSw1m4vueT8L8IZSQC3xzQwoSsTjNuntjLKrPBJ6n3ZvEjUHPlBo WrTaBVMSrdlrFb1TuZvVhWbdmqMjaSz81jhRXecKecZgfMQm46nqsFM08MLXC0m8j0 CTDV6grBhcbSVhlp75twCigUAvglT8VLrawkq8S8BTIEgUp7+YpjwU/O5GC0mN8W6z XG4z0ajFdtdmsCLf32ZDOPyBZzfTjhIzAXgBC5A9JKEpOPCcJJ2D5ow0DV9DvIwUrM fh8qk4TOYCSlg== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 14:23:48 -0000 On 5/23/13 8:17 PM, Martin Thomson wrote: > On 23 May 2013 14:34, Paul Kyzivat wrote: >> Or, you can view it as layered. Where the ssrc maps to an early stage of the >> pipeline (selected by ssrc) that does the codec processing, and then a >> different stage of the pipeline (selected by capture id from the header >> extension) that switches the decoded output to a particular rendering >> device. > > That is what I would do for that case. At the layer I'm concerned > about, this is still the same stream. The fact that someone > downstream might use other information to wiggle that around doesn't > concern me greatly. But it has an impact on what is signaled. If I intend to use capture-id to associate with an m-line then I don't need to signal the SSRCs. The SSRCs may still be used to demux to a decoder, but for that they don't need to be known in advance. This is important for plan A. Thanks, Paul From pkyzivat@alum.mit.edu Fri May 24 07:36:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C49921F89B0 for ; Fri, 24 May 2013 07:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_47=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5DFaId+lzSI for ; Fri, 24 May 2013 07:36:17 -0700 (PDT) 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 7EB6A21F8E3C for ; Fri, 24 May 2013 07:36:17 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta04.westchester.pa.mail.comcast.net with comcast id fnBg1l0021c6gX854qcHbK; Fri, 24 May 2013 14:36:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id fqcG1l0193ZTu2S3jqcGEV; Fri, 24 May 2013 14:36:17 +0000 Message-ID: <519F7ADF.1010909@alum.mit.edu> Date: Fri, 24 May 2013 10:36:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3777C9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3777C9@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=1369406177; bh=0kG9xB+EeYwaUfh9MC0B8SDU0xeih1OUPF7gboukV14=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F611quSol8M6/DnwqenrHeJJusys3IHRugBVlHmCxIcP8pfgnYbPJ5CBGI+Xybgsk b2/yHeWwXzVRew5y/NfW0iNNzpJyTjvoShA2CYc9DTHSrvWLX47EEa5P7R7nroBhah +8WIcGhTP3CjA9XpR8GVEESZADl53lWntDJYb3+iQ3aC3uz89J8eHjEga+NGd3Jlxk 9zVRkwllXFeVsMtlBJolrk6V8bnH0ilDrTZCuqelaBawGA5pHwOCHo8vK7y1M+F+kV avGCnCFRqw3RthWMpd5zkolRv6qzoE2hG5+i0uYj4cuVhKBFxG/zLyAxSwUlPSINDO ZMyNjCQKBOqaQ== Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 14:36:22 -0000 I agree with the sense of what you state below. I have some nits with the words you use. On 5/24/13 6:28 AM, Christer Holmberg wrote: > Hi, > > At the interim yesterday, we agreed that an answerer MUST always include > identical ports* (usage of port zero within a bundle is a separate > topic) for all m- lines within an bundle group. > > If the answerer wants to use different ports* for some/all m- lines, it > MUST NOT include those m- lines in a bundle group OK so far. But: > (if they already are > in a bundle group, a separate offer is needed to remove them). This depends on what you mean by "already in a bundle group". Certainly they are already in a bundle group in the offer, so presumably that is not what you mean. I presume you mean that they were already in a bundle group in the prior O/A. I think this can be stated more clearly. How about: The answer to an offer containing a bundle group may remove an m-line from the bundle group if (and only if) the address/port of the m-line in the offer is distinct from the address/port of all the other m-lines in the offered bundle group. When doing so it must supply a unique address/port for that m-line in the answer. Thanks, Paul > WHAT IT MEANS: There is no way for an answerer to tell that the offerer, > for certain m- lines, can use the same port*, eventhough the answer will > use separate ports*. > > I will work on some actual text proposal later, but please indicate if > you OBJECT to this approach in general. > > Regards, > > Christer > > NOTE: “port” = port:address combination – we are working on coming up > with better terminology J > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From kevindempsey70@gmail.com Fri May 24 07:39:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647F021F8624 for ; Fri, 24 May 2013 07:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNiFACIepkUt for ; Fri, 24 May 2013 07:39:56 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AAFF121F8616 for ; Fri, 24 May 2013 07:39:55 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id er20so4468039lab.5 for ; Fri, 24 May 2013 07:39:54 -0700 (PDT) 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=6faadDVIycTCQp1ocLs0V525J+RtUts0TTMKFtFfgw8=; b=Jpcp3G/Iz7If0kUWzVznraD+lKZreV5zqATEYn6XkBsmuws7531skRaUFO0/R58yCR AKAA95TkS4rlrlKsiRpkQjtgvNYNI79MNZAnQhUsKo8Ie3vYUdEw85Mdxo2YfHj1rL61 cKTkBcK89P0R3R2Wbs3pf8uLQ+HPi7dlairgZvZss2BAZqbn06malI6jwgMjsc8wzegU NvJppHSQaanRfbsKG5o65HJbRFNaUaCWKuzC3KIR+POa1OBQ+uPPNSpsuljKg41zzApH s8+zv1BH0o/RyYzHr08b0gd4CwmDWAX0oHOzfxSFLxYdygv9x7fSd4BwzdTYIw5gvdd3 wvkQ== MIME-Version: 1.0 X-Received: by 10.152.26.41 with SMTP id i9mr9009936lag.12.1369406394251; Fri, 24 May 2013 07:39:54 -0700 (PDT) Received: by 10.114.0.139 with HTTP; Fri, 24 May 2013 07:39:54 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> Date: Fri, 24 May 2013 15:39:54 +0100 Message-ID: From: Kevin Dempsey To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0158bde8aec0ca04dd77c543 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 14:39:57 -0000 --089e0158bde8aec0ca04dd77c543 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Can someone please explain why a m-line can be rejected when the port numbers are different, but not if all the port numbers are the same? On 24 May 2013 13:32, Christer Holmberg wro= te: > Hi,**** > > ** ** > > At the interim meeting yesterday, we agreed on some restrictions regardin= g > creating SDP answers containing bundle group(s).**** > > ** ** > > Note that the restrictions 1-3 are simply alignments with RFC 5888, and > are listed simply for clarification purpose. Restrictions 4 is BUNDLE > specific. Restriction 5 is also alignment with RFC 5888, as m- lines with > port zero are not allowed within groups, but we will need some > clarification text saying that a new offer will have to be sent in order = to > remove a stream (either from a bundle group, or completely from the > session).**** > > ** ** > > (Note that the text below is not necessarily the wording that will go int= o > the draft)**** > > ** ** > > In an SDP answer:**** > > **1) **a BUNDLE group MUST NOT be created, unless it was included in > the associated offer**** > > **2) **an m- line MUST NOT be added to a BUNDLE group, unless it was > included in a BUNDLE group in the associated offer**** > > **3) **an m- line MUST NOT be added to another BUNDLE group than the > group in which was included in the associated offer**** > > **4) **an m- line MUST NOT be removed from a BUNDLE group if, in the > associated offer, an identical port number was indicated for all m- lines > in a BUNDLE group**** > > **5) **an m- line MUST NOT be rejected if, in the associated offer, > an identical port number was indicated for all m- lines in a BUNDLE group= * > *** > > ** ** > > ** ** > > Note that there is also a discussion regarding bundle offers, e.g. when > restrictions when adding new m- lines to a bundle. Based on the outcome o= f > that, there may be some additional answer restrictions, e.g. regarding th= e > change of bundle transport parameters. But, let=92s deal with that in the > offer thread.**** > > ** ** > > So, if anyone OBJECTS to the restrictions above, please indicate so.**** > > ** ** > > Regards,**** > > ** ** > > Christer**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e0158bde8aec0ca04dd77c543 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Can someone please explain why a m-line can be rejected wh= en the port numbers are different, but not if all the port numbers are the = same?


On= 24 May 2013 13:32, Christer Holmberg <christer.holmberg@eric= sson.com> wrote:

Hi,

=A0

At the interim meeting yesterday, we agreed on some = restrictions regarding creating SDP answers containing bundle group(s).<= /u>

=A0

Note that the restrictions 1-3 are simply alignments= with RFC 5888, and are listed simply for clarification purpose. Restrictio= ns 4 is BUNDLE specific. Restriction 5 is also alignment with RFC 5888, as = m- lines with port zero are not allowed within groups, but we will need some clarification text saying that a new = offer will have to be sent in order to remove a stream (either from a bundl= e group, or completely from the session).

=A0

(Note that the text below is not necessarily the wor= ding that will go into the draft)

=A0

In an SDP answer:

1)=A0= =A0=A0=A0=A0 a BUNDLE group MUST NOT be created, unless it was incl= uded in the associated offer

2)=A0= =A0=A0=A0=A0 an m- line MUST NOT be added to a BUNDLE group, unless= it was included in a BUNDLE group in the associated offer

3)=A0= =A0=A0=A0=A0 an m- line MUST NOT be added to another BUNDLE group t= han the group in which was included in the associated offer

4)=A0= =A0=A0=A0=A0 an m- line MUST NOT be removed from a BUNDLE group if,= in the associated offer, an identical port number was indicated for all m-= lines in a BUNDLE group

5)=A0= =A0=A0=A0=A0 an m- line MUST NOT be rejected if, in the associated = offer, an identical port number was indicated for all m- lines in a BUNDLE = group

=A0

=A0

Note that there is also a discussion regarding bundl= e offers, e.g. when restrictions when adding new m- lines to a bundle. Base= d on the outcome of that, there may be some additional answer restrictions,= e.g. regarding the change of bundle transport parameters. But, let=92s deal with that in the offer thread.<= /u>

=A0

So, if anyone OBJECTS to the restrictions above, ple= ase indicate so.

=A0

Regards,

=A0

Christer

=A0

=A0

=A0

=A0

=A0


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


--089e0158bde8aec0ca04dd77c543-- From emcho@sip-communicator.org Fri May 24 07:40:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A1521F90AC for ; Fri, 24 May 2013 07:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrHgV3Laix9I for ; Fri, 24 May 2013 07:40:26 -0700 (PDT) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id DA13221F8624 for ; Fri, 24 May 2013 07:40:26 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa10so4345463pad.5 for ; Fri, 24 May 2013 07:40:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=r2n1yeoh1Dmd2XMZRfZNRs/nV6DhtA8aCB9m1lsqZfM=; b=H9Nfhs7zhgnQeP1JxKvMA3sE0YG49sm3aFPmYSWIvofzBi+2n1BiPHoy2RQ6zl38DQ v7TseuRPbeBZcRmz2DH+bbekc9p1iHNjlzAlnruaN3Zs2AOLxBTF7AEB4/gBq+yGopTO HKb7mvakYohLSxaY517wMX8di5+WyCeroD7lNBYRBaepGQ84fnPgr8RhwsHkKkRmT1A/ Qs6+bL+oEdrBrmzSUfSq9dWfsOv8nvK2rvi1kC0wK1KbSu33FkY9doeoHXKYpOVxiMf+ cd0DPvzfFr/oEHR4goGePaF+o1VuiyIUNjYPI69Fote3WxW4jWpHD45OVbcl+W+XNAyt OtYw== X-Received: by 10.68.197.195 with SMTP id iw3mr17977507pbc.177.1369406426396; Fri, 24 May 2013 07:40:26 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by mx.google.com with ESMTPSA id cc15sm17750167pac.1.2013.05.24.07.40.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 07:40:26 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id 10so4228393pdi.17 for ; Fri, 24 May 2013 07:40:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.221.201 with SMTP id qg9mr9529350pbc.87.1369406425514; Fri, 24 May 2013 07:40:25 -0700 (PDT) Received: by 10.66.89.234 with HTTP; Fri, 24 May 2013 07:40:25 -0700 (PDT) Received: by 10.66.89.234 with HTTP; Fri, 24 May 2013 07:40:25 -0700 (PDT) In-Reply-To: <519F7633.1010902@alum.mit.edu> References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> <519F2BD8.8060803@jitsi.org> <519F2F8B.5080004@jitsi.org> <519F7633.1010902@alum.mit.edu> Date: Fri, 24 May 2013 17:40:25 +0300 Message-ID: From: Emil Ivov To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8ff243378be59004dd77c7f0 X-Gm-Message-State: ALoCoQnPBEs3cliklcIBas/7lijpIrJ9bjCrhYXUGHSdS548QU+J/1SN2DHOgbd71TMGLz8SgzQg Cc: mmusic Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 14:40:44 -0000 --e89a8ff243378be59004dd77c7f0 Content-Type: text/plain; charset=ISO-8859-1 On May 24, 2013 5:16 PM, "Paul Kyzivat" wrote: > > On 5/24/13 5:14 AM, Emil Ivov wrote: >> >> On 24.05.13, 12:02, Kevin Dempsey wrote: >>> >>> I didn't say anything about changing the PTs. >> >> >> Sorry, I misunderstood. >> >>> The answerer decides what >>> it codecs it will use from the ones listed in the offer. If it doesn't >>> support any other mechanism to allow demux then it must choose codecs >>> that have PTs on only one m-line, or not accept the BUNDLE. >> >> >> Matching packets to m= lines is the concern of the receiving party. So >> is the mechanism that it uses. What you are suggesting is for the >> answerer to basically say: "It seems to me that you won't be able to >> demux these two payloads so I will not send them to you because I know >> better". >> >> In the same time the offerer may be planning on using a demux technique >> that the answerer simply isn't aware of. For example (and this is really >> just to make a point, so please don't assume I am suggesting something >> like this in general) if 101 is mapped to both telephone-event and VP8, >> demuxing can be easily made without any other knowledge of SSRC or >> header extensions. > > > ISTM that after the O/A exchange both sides need to have a common > understanding that their communications will be understandable. I assume this means you agree that an offerer has to make sure at least one of the demuxing mechanisms it supports will be understood by the answerer. Emil --sent from my mobile > > If the combination of the offer and answer aren't sufficient for each side to encode what it sends in a way that it knows can be demuxed according in accord with the O/A, then that offer should be incorrect. > > IMO injecting "magic" into this isn't helpful. > > Thanks, > Paul > > >> Cheers, >> Emil >> >> >>> >>> >>> On 24 May 2013 09:59, Emil Ivov >> > wrote: >>> >>> On 24.05.13, 11:40, Kevin Dempsey wrote: >>> > Isn't the onus on the answerer to ensure the demux is possible, >>> since it >>> > is accepting the bundle. Therefore if it doesn't support signalling >>> > SSRCs or an offerred 'fancy-RFC m-line matching' method, it must only >>> > send PTs that are tied to a single m-line. >>> >>> PTs are defined by the offerer. The answerer cannot change them for the >>> offerer-bound direction (even if it could request different values for >>> the packets that it, the answerer, is going to receive). >>> >>> Emil >>> >>> >>> > >>> > >>> > On 24 May 2013 08:17, Emil Ivov >> >>> > >> wrote: >>> > >>> > On 24.05.13, 00:59, Paul Kyzivat wrote: >>> > > IMO the "before the O/A completes" issues are separate from >>> the "after >>> > > the O/A completes" issues. I'm still not convinced that the >>> > "before the >>> > > O/A completes" issues are important. (We have reliable 183 >>> > responses to >>> > > deal with it.) But I'm ok with Cullen using PT to solve that >>> > problem if >>> > > he thinks he needs to. >>> > >>> > I wasn't referring to "before the O/A completes" situations. >>> If your >>> > peer does not support fancy-RFC m-line matching nor does it >>> provide >>> > SSRCs, you have to be able to fall back to PT demuxing. >>> > >>> > Therefore, all your offers have to accommodate for that >>> possibility >>> > unless you know that the offer is going to someone who also >>> supports >>> > other mechanisms. >>> > >>> > Emil >>> > >>> > -- >>> > https://jitsi.org >>> > _______________________________________________ >>> > mmusic mailing list >>> > mmusic@ietf.org >>> > >>> > https://www.ietf.org/mailman/listinfo/mmusic >>> > >>> > >>> >>> -- >>> https://jitsi.org >>> >>> >> > --e89a8ff243378be59004dd77c7f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On May 24, 2013 5:16 PM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:
>
> On 5/24/13 5:14 AM, Emil Ivov wrote:
>>
>> On 24.05.13, 12:02, Kevin Dempsey wrote:
>>>
>>> I didn't say anything about changing the PTs.
>>
>>
>> Sorry, I misunderstood.
>>
>>> The answerer decides what
>>> it codecs it will use from the ones listed in the offer. If it= doesn't
>>> support any other mechanism to allow demux then it must choose= codecs
>>> that have PTs on only one m-line, or not accept the BUNDLE. >>
>>
>> Matching packets to m=3D lines is the concern of the receiving par= ty. So
>> is the mechanism that it uses. What you are suggesting is for the<= br> >> answerer to basically say: "It seems to me that you won't= be able to
>> demux these two payloads so I will not send them to you because I = know
>> better".
>>
>> In the same time the offerer may be planning on using a demux tech= nique
>> that the answerer simply isn't aware of. For example (and this= is really
>> just to make a point, so please don't assume I am suggesting s= omething
>> like this in general) if 101 is mapped to both telephone-event and= VP8,
>> demuxing can be easily made without any other knowledge of SSRC or=
>> header extensions.
>
>
> ISTM that after the O/A exchange both sides need to have a common
> understanding that their communications will be understandable.

I assume this means you agree that an offerer has to make su= re at least one of the demuxing mechanisms it supports will be understood b= y the answerer.

Emil

--sent from my mobile
>
> If the combination of the offer and answer aren't sufficient for e= ach side to encode what it sends in a way that it knows can be demuxed acco= rding in accord with the O/A, then that offer should be incorrect.
>
> IMO injecting "magic" into this isn't helpful.
>
> =A0 =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 =A0 Paul
>
>
>> Cheers,
>> Emil
>>
>>
>>>
>>>
>>> On 24 May 2013 09:59, Emil Ivov <emcho@jitsi.org
>>> <mailto:emcho@jitsi.org<= /a>>> wrote:
>>>
>>> =A0 =A0 =A0On 24.05.13, 11:40, Kevin Dempsey wrote:
>>> =A0 =A0 =A0> Isn't the onus on the answerer to ensure t= he demux is possible,
>>> =A0 =A0 =A0since it
>>> =A0 =A0 =A0> is accepting the bundle. Therefore if it doesn= 't support signalling
>>> =A0 =A0 =A0> SSRCs or an offerred 'fancy-RFC m-line mat= ching' method, it must only
>>> =A0 =A0 =A0> send PTs that are tied to a single m-line.
>>>
>>> =A0 =A0 =A0PTs are defined by the offerer. The answerer cannot= change them for the
>>> =A0 =A0 =A0offerer-bound direction (even if it could request d= ifferent values for
>>> =A0 =A0 =A0the packets that it, the answerer, is going to rece= ive).
>>>
>>> =A0 =A0 =A0Emil
>>>
>>>
>>> =A0 =A0 =A0>
>>> =A0 =A0 =A0>
>>> =A0 =A0 =A0> On 24 May 2013 08:17, Emil Ivov <emcho@jitsi.org
>>> =A0 =A0 =A0<mailto:emcho= @jitsi.org>
>>> =A0 =A0 =A0> <mailto:= emcho@jitsi.org <mailto:emcho@jit= si.org>>> wrote:
>>> =A0 =A0 =A0>
>>> =A0 =A0 =A0> =A0 =A0 On 24.05.13, 00:59, Paul Kyzivat wrote= :
>>> =A0 =A0 =A0> =A0 =A0 > IMO the "before the O/A comp= letes" issues are separate from
>>> =A0 =A0 =A0the "after
>>> =A0 =A0 =A0> =A0 =A0 > the O/A completes" issues. I= 'm still not convinced that the
>>> =A0 =A0 =A0> =A0 =A0 "before the
>>> =A0 =A0 =A0> =A0 =A0 > O/A completes" issues are im= portant. (We have reliable 183
>>> =A0 =A0 =A0> =A0 =A0 responses to
>>> =A0 =A0 =A0> =A0 =A0 > deal with it.) But I'm ok wit= h Cullen using PT to solve that
>>> =A0 =A0 =A0> =A0 =A0 problem if
>>> =A0 =A0 =A0> =A0 =A0 > he thinks he needs to.
>>> =A0 =A0 =A0>
>>> =A0 =A0 =A0> =A0 =A0 I wasn't referring to "before= the O/A completes" situations.
>>> =A0 =A0 =A0If your
>>> =A0 =A0 =A0> =A0 =A0 peer does not support fancy-RFC m-line= matching nor does it
>>> =A0 =A0 =A0provide
>>> =A0 =A0 =A0> =A0 =A0 SSRCs, you have to be able to fall bac= k to PT demuxing.
>>> =A0 =A0 =A0>
>>> =A0 =A0 =A0> =A0 =A0 Therefore, all your offers have to acc= ommodate for that
>>> =A0 =A0 =A0possibility
>>> =A0 =A0 =A0> =A0 =A0 unless you know that the offer is goin= g to someone who also
>>> =A0 =A0 =A0supports
>>> =A0 =A0 =A0> =A0 =A0 other mechanisms.
>>> =A0 =A0 =A0>
>>> =A0 =A0 =A0> =A0 =A0 Emil
>>> =A0 =A0 =A0>
>>> =A0 =A0 =A0> =A0 =A0 --
>>> =A0 =A0 =A0> =A0 =A0 https://= jitsi.org
>>> =A0 =A0 =A0> =A0 =A0 ______________________________________= _________
>>> =A0 =A0 =A0> =A0 =A0 mmusic mailing list
>>> =A0 =A0 =A0> =A0 =A0 mmu= sic@ietf.org <mailto:mmusic@ietf.= org>
>>> =A0 =A0 =A0<mailto:mmusi= c@ietf.org <mailto:mmusic@ietf.or= g>>
>>> =A0 =A0 =A0> =A0 =A0 https://www.ietf.org/mailman/listinfo/mmusic
>>> =A0 =A0 =A0>
>>> =A0 =A0 =A0>
>>>
>>> =A0 =A0 =A0--
>>> =A0 =A0 =A0https://jitsi.org=
>>>
>>>
>>
>

--e89a8ff243378be59004dd77c7f0-- From pkyzivat@alum.mit.edu Fri May 24 07:41:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C2521F9362 for ; Fri, 24 May 2013 07:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9pwBO4Zy7iH for ; Fri, 24 May 2013 07:41:02 -0700 (PDT) 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 460AE21F9349 for ; Fri, 24 May 2013 07:41:02 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta15.westchester.pa.mail.comcast.net with comcast id fnXA1l00327AodY5Fqh17t; Fri, 24 May 2013 14:41:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id fqh11l00s3ZTu2S3fqh1eJ; Fri, 24 May 2013 14:41:01 +0000 Message-ID: <519F7BFC.2040008@alum.mit.edu> Date: Fri, 24 May 2013 10:41:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C377967@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=1369406461; bh=eAVgRn0MRRF6arhWP55C2FnCe/OB3a4bb4srYLNWeas=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=J/BwTPk9zpU2+sTx6X5MoshKYJbbbuPjgV7YiREfiFRMAXAtWiJaNI19qdoR/9gwV 82yDLWq2JS9ASg+knf3lJL+C12oDNfP6uj3mswYEN+IxIR2YmD8o8vHv0HRv0EJXYO LRAR654uIBCTnA7xWC9r8zLAaMMfnYdSMkxUPMnsu+554yf6hCf02SQlUWgLx2IwdO pJL6+jOJ6+2/t3Sn70IfLqiGncc/B/47IHX6bOA8Tc91ZDDnk9VFEMxJwkFMdZW1p+ A/WeFq/hjxXHWzx3bTLaBgb1OWu1CRl8Q9tans/qyB6D7ujk7qVl3fDSb4PyzXjbX6 EQE6xVZ+dWXXA== Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 14:41:07 -0000 I object to (5) below (see inline). Otherwise these seem ok to me. Thanks, Paul On 5/24/13 8:32 AM, Christer Holmberg wrote: > Hi, > > At the interim meeting yesterday, we agreed on some restrictions > regarding creating SDP answers containing bundle group(s). > > Note that the restrictions 1-3 are simply alignments with RFC 5888, and > are listed simply for clarification purpose. Restrictions 4 is BUNDLE > specific. Restriction 5 is also alignment with RFC 5888, as m- lines > with port zero are not allowed within groups, but we will need some > clarification text saying that a new offer will have to be sent in order > to remove a stream (either from a bundle group, or completely from the > session). > > (Note that the text below is not necessarily the wording that will go > into the draft) > > In an SDP answer: > > 1)a BUNDLE group MUST NOT be created, unless it was included in the > associated offer > > 2)an m- line MUST NOT be added to a BUNDLE group, unless it was included > in a BUNDLE group in the associated offer > > 3)an m- line MUST NOT be added to another BUNDLE group than the group in > which was included in the associated offer > > 4)an m- line MUST NOT be removed from a BUNDLE group if, in the > associated offer, an identical port number was indicated for all m- > lines in a BUNDLE group > > 5)an m- line MUST NOT be rejected if, in the associated offer, an > identical port number was indicated for all m- lines in a BUNDLE group Where did (5) come from? And what is the justification for it? I can see no good reason to impose this restriction. > Note that there is also a discussion regarding bundle offers, e.g. when > restrictions when adding new m- lines to a bundle. Based on the outcome > of that, there may be some additional answer restrictions, e.g. > regarding the change of bundle transport parameters. But, let’s deal > with that in the offer thread. > > So, if anyone OBJECTS to the restrictions above, please indicate so. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Fri May 24 07:49:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDEA21F919D for ; Fri, 24 May 2013 07:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbXrGPZs00Dt for ; Fri, 24 May 2013 07:49:17 -0700 (PDT) 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 65FF121F93C4 for ; Fri, 24 May 2013 07:49:17 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id fnhJ1l0041uE5Es54qpGiz; Fri, 24 May 2013 14:49:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id fqpG1l00D3ZTu2S3cqpGJX; Fri, 24 May 2013 14:49:16 +0000 Message-ID: <519F7DEB.2010809@alum.mit.edu> Date: Fri, 24 May 2013 10:49:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37797E@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=1369406956; bh=0mwqstoH5XmvAkcI4kRSX/ndp0Fiwqzqh4dtaKDcnYg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MHrpHij61axdPFuu+vc+SxzAdonl+oKK36P4vu6CCNyAktiM2tz7mToSV0hyFbFdj QvnR6GkSdrUluF21dhm4jb7JhP6xVDZp+V/cBKB/WTLxqSjG6arC3ikRCtJm/zDbi6 JGKw2VbMO+p5AUYCna1woma1h/THZmfjaRWdAumIC8nT2yBIfj6rGNHi6z7Ut/4oc/ K4K/c7BssqSYNsfC+qfKt0HcbNdJ2UpGev47kWddnefsP6aM7oaLwbR864gJsxrJxA IwN403g+ryElTWMht7deA4IHYCW46J7NronP2rH49xxZ34+Odg+7a5jOUqTfJNzKPW vYVyURxMooX9Q== Subject: Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 14:49:22 -0000 On 5/24/13 8:39 AM, Christer Holmberg wrote: > Hi, > > At the interim yesterday, we agreed to use the SDP BUNDLE group > attribute to indicate on which port bundled media will be sent. In an > SDP offer, the order of the attribute mid values can be used by the > offerer to indicate a “wish”, but the first attribute mid value in the > answer indicates where the answerer will eventually send bundled media. This could be interpreted to mean the first a=mid value in the SDP. I'm sure you mean "the first mid value in the a=group:bundle" line. Or perhaps "the first mid value in the bundle group" - assuming there is a definition that "bundle group" means an a=group:bundle line. This can be "future proofed" by saying that the first mid value in the bundle group in the answer that references an m-line with non-zero port value. I realize this adds nothing unless 5888 is revised to permit m-lines with zero port in a bundle group. But at least it will be ready for that, and harms nothing. Thanks, Paul > The main usage of this is the “initial offer”, when each m- line within > a bundle group has a different port value. > > So far so good. > > The reason I say “almost decision” is because we have started a new > discussion regarding updated offers, adding new m- lines etc. We need to > make sure that the order-to-mid-values semantics also apply to those, > and what restrictions there are when adding m- lines. > > But, for now, if you OBJECT to the general principle of using the SDP > group attribute mid value order for indicating the port where media will > be sent, please indicate so. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Fri May 24 07:57:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF121F93BF for ; Fri, 24 May 2013 07:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.526 X-Spam-Level: X-Spam-Status: No, score=0.526 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_OBFU_RESULTING=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wz3dArtnhglg for ; Fri, 24 May 2013 07:57:34 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 1A90621F8EF7 for ; Fri, 24 May 2013 07:57:33 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id fnPZ1l0020QuhwU5CqxZwK; Fri, 24 May 2013 14:57:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id fqxZ1l00Z3ZTu2S3NqxZuR; Fri, 24 May 2013 14:57:33 +0000 Message-ID: <519F7FDC.2070001@alum.mit.edu> Date: Fri, 24 May 2013 10:57:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> <519F2BD8.8060803@jitsi.org> <519F2F8B.5080004@jitsi.org> <519F7633.1010902@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=1369407453; bh=7gDBQDerjTbF2Z57/i+/VAOWMVrutwp3IO71OKaeQVQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oBPLbupajWyJ9l++YKuTxY25tq6JofYa1DNJbfkitxRsN7eYDPp/XRwFQbUlch8C3 OgkNgAFh3LeFuGCLeCbuPa0nPCy7iVqRcf+dE0ynoYuArC4lClWCQrRN22fsf0x2cU W5IPsJgU2fpVuECaOWc9qjbX4fnXWuTz4nxfnmxOn9DxRrnPsI7Jc+3rNZBq5SPqxc uDSxkUOMB/wjhiCdx4DXtt6RsKceCAicjW15Fo44r/rVzOtG1+BD9ebi1u4Zl2HWk3 vqL08LcNQjXhJQVmqyuqyyU0DaPVuImlynDaUZBB9IXovVlmX33tofigRP3Jf5ULfN QVZzP9ZlGW6zg== Cc: mmusic Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 14:57:40 -0000 On 5/24/13 10:40 AM, Emil Ivov wrote: > On May 24, 2013 5:16 PM, "Paul Kyzivat" > wrote: > > > > On 5/24/13 5:14 AM, Emil Ivov wrote: > >> > >> On 24.05.13, 12:02, Kevin Dempsey wrote: > >>> > >>> I didn't say anything about changing the PTs. > >> > >> > >> Sorry, I misunderstood. > >> > >>> The answerer decides what > >>> it codecs it will use from the ones listed in the offer. If it doesn't > >>> support any other mechanism to allow demux then it must choose codecs > >>> that have PTs on only one m-line, or not accept the BUNDLE. > >> > >> > >> Matching packets to m= lines is the concern of the receiving party. So > >> is the mechanism that it uses. What you are suggesting is for the > >> answerer to basically say: "It seems to me that you won't be able to > >> demux these two payloads so I will not send them to you because I know > >> better". > >> > >> In the same time the offerer may be planning on using a demux technique > >> that the answerer simply isn't aware of. For example (and this is really > >> just to make a point, so please don't assume I am suggesting something > >> like this in general) if 101 is mapped to both telephone-event and VP8, > >> demuxing can be easily made without any other knowledge of SSRC or > >> header extensions. > > > > > > ISTM that after the O/A exchange both sides need to have a common > > understanding that their communications will be understandable. > > I assume this means you agree that an offerer has to make sure at least > one of the demuxing mechanisms it supports will be understood by the > answerer. No. But the offerer had better ensure that there is some way to answer that meets the requirements. Then it becomes a requirement on the answerer to answer in a way that makes the communication unambiguous. If it can't do that while bundling then it must remove the bundle, or remove some m-lines from the bundle, or reject some of the m-lines in the bundle, so that the resullting answer constructs an unambiguous communication. If the intent is to rely on "magic" then that can be achieved by using fewer m-lines in the bundle, in a way that dumps more streams/flows into the same m-line. So this is really only an issue for plan A. Thanks, Paul From emcho@sip-communicator.org Fri May 24 08:04:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC0421F8B04 for ; Fri, 24 May 2013 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_RESULTING=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLC9PzVr7dvM for ; Fri, 24 May 2013 08:03:55 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 30D6121F8A74 for ; Fri, 24 May 2013 08:03:55 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj3so4391556pad.29 for ; Fri, 24 May 2013 08:03:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VmwhdEroVXudixFRaDJGrSQTSl/Cbsv43wiJIBkqdCM=; b=jtEuwkPINefE56Dmfg2yke1KwQgNMw9/a30NBSEIK+5i28JplKcFLijMXHfakjFS1Y CG4BDwrmnYsafoeDZQg6A9EUlvzqoAsQEtTIHZNqIczPPR+Hz2sEd2cagYgv3s3ZRNs9 GPwLzElvt+vzr4e6DBxNOLiTx9A+QoOShXlOYu+nqc7XxG60LVchtJdgjK5xkL6tc+of /W3nQGhVNTgbm2lsd8Pxi7eq6PSz/QccWKj93wYJul3Sh2xFqenkPWpH6K9A/iKpFSr/ JFHmyGDHgCRihHce35DuXQdT1i9wd1JwbY+DMCXH7UpF2KhomJ2EcRRgVsRk1ECVzmUE bBNg== X-Received: by 10.68.184.100 with SMTP id et4mr18006506pbc.48.1369407834842; Fri, 24 May 2013 08:03:54 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by mx.google.com with ESMTPSA id 10sm16552913pbm.0.2013.05.24.08.03.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 08:03:54 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp6so4386257pab.35 for ; Fri, 24 May 2013 08:03:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.171.36 with SMTP id ar4mr17863784pbc.195.1369407833567; Fri, 24 May 2013 08:03:53 -0700 (PDT) Received: by 10.66.89.234 with HTTP; Fri, 24 May 2013 08:03:53 -0700 (PDT) Received: by 10.66.89.234 with HTTP; Fri, 24 May 2013 08:03:53 -0700 (PDT) In-Reply-To: <519F7FDC.2070001@alum.mit.edu> References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> <519F2BD8.8060803@jitsi.org> <519F2F8B.5080004@jitsi.org> <519F7633.1010902@alum.mit.edu> <519F7FDC.2070001@alum.mit.edu> Date: Fri, 24 May 2013 18:03:53 +0300 Message-ID: From: Emil Ivov To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b86f6d2790cec04dd781ba9 X-Gm-Message-State: ALoCoQl+Koo8LCKeq/gpJzoNUZdqEcQ9sFiuGnhfVWfgTN/kVfC/vVIsrHD968pa3/CACJu03YAh Cc: mmusic Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 15:04:12 -0000 --047d7b86f6d2790cec04dd781ba9 Content-Type: text/plain; charset=ISO-8859-1 Paul, This looks very much like what I suggested initially in my response to Cullen, so I am not sure why you sound as if you are disagreeing. Emil --sent from my mobile On May 24, 2013 5:57 PM, "Paul Kyzivat" wrote: > On 5/24/13 10:40 AM, Emil Ivov wrote: > >> On May 24, 2013 5:16 PM, "Paul Kyzivat" > **> wrote: >> > >> > On 5/24/13 5:14 AM, Emil Ivov wrote: >> >> >> >> On 24.05.13, 12:02, Kevin Dempsey wrote: >> >>> >> >>> I didn't say anything about changing the PTs. >> >> >> >> >> >> Sorry, I misunderstood. >> >> >> >>> The answerer decides what >> >>> it codecs it will use from the ones listed in the offer. If it >> doesn't >> >>> support any other mechanism to allow demux then it must choose codecs >> >>> that have PTs on only one m-line, or not accept the BUNDLE. >> >> >> >> >> >> Matching packets to m= lines is the concern of the receiving party. So >> >> is the mechanism that it uses. What you are suggesting is for the >> >> answerer to basically say: "It seems to me that you won't be able to >> >> demux these two payloads so I will not send them to you because I know >> >> better". >> >> >> >> In the same time the offerer may be planning on using a demux >> technique >> >> that the answerer simply isn't aware of. For example (and this is >> really >> >> just to make a point, so please don't assume I am suggesting something >> >> like this in general) if 101 is mapped to both telephone-event and >> VP8, >> >> demuxing can be easily made without any other knowledge of SSRC or >> >> header extensions. >> > >> > >> > ISTM that after the O/A exchange both sides need to have a common >> > understanding that their communications will be understandable. >> >> I assume this means you agree that an offerer has to make sure at least >> one of the demuxing mechanisms it supports will be understood by the >> answerer. >> > > No. But the offerer had better ensure that there is some way to answer > that meets the requirements. > > Then it becomes a requirement on the answerer to answer in a way that > makes the communication unambiguous. If it can't do that while bundling > then it must remove the bundle, or remove some m-lines from the bundle, or > reject some of the m-lines in the bundle, so that the resullting answer > constructs an unambiguous communication. > > If the intent is to rely on "magic" then that can be achieved by using > fewer m-lines in the bundle, in a way that dumps more streams/flows into > the same m-line. So this is really only an issue for plan A. > > Thanks, > Paul > > --047d7b86f6d2790cec04dd781ba9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Paul,

This looks very much like what I suggested initially in my r= esponse to Cullen, so I am not sure why you sound as if you are disagreeing= .

Emil

--sent from my mobile

On May 24, 2013 5:57 PM, "Paul Kyzivat"= ; <pkyzivat@alum.mit.edu>= ; wrote:
On 5/24/13 10:40 AM, Emil Ivov wrote:
On May 24, 2013 5:16 PM, "Paul Kyzivat" <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:
=A0>
=A0> On 5/24/13 5:14 AM, Emil Ivov wrote:
=A0>>
=A0>> On 24.05.13, 12:02, Kevin Dempsey wrote:
=A0>>>
=A0>>> I didn't say anything about changing the PTs.
=A0>>
=A0>>
=A0>> Sorry, I misunderstood.
=A0>>
=A0>>> The answerer decides what
=A0>>> it codecs it will use from the ones listed in the offer. If= it doesn't
=A0>>> support any other mechanism to allow demux then it must cho= ose codecs
=A0>>> that have PTs on only one m-line, or not accept the BUNDLE.=
=A0>>
=A0>>
=A0>> Matching packets to m=3D lines is the concern of the receiving = party. So
=A0>> is the mechanism that it uses. What you are suggesting is for t= he
=A0>> answerer to basically say: "It seems to me that you won= 9;t be able to
=A0>> demux these two payloads so I will not send them to you because= I know
=A0>> better".
=A0>>
=A0>> In the same time the offerer may be planning on using a demux t= echnique
=A0>> that the answerer simply isn't aware of. For example (and t= his is really
=A0>> just to make a point, so please don't assume I am suggestin= g something
=A0>> like this in general) if 101 is mapped to both telephone-event = and VP8,
=A0>> demuxing can be easily made without any other knowledge of SSRC= or
=A0>> header extensions.
=A0>
=A0>
=A0> ISTM that after the O/A exchange both sides need to have a common =A0> understanding that their communications will be understandable.

I assume this means you agree that an offerer has to make sure at least
one of the demuxing mechanisms it supports will be understood by the
answerer.

No. But the offerer had better ensure that there is some way to answer that= meets the requirements.

Then it becomes a requirement on the answerer to answer in a way that makes= the communication unambiguous. If it can't do that while bundling then= it must remove the bundle, or remove some m-lines from the bundle, or reje= ct some of the m-lines in the bundle, so that the resullting answer constru= cts an unambiguous communication.

If the intent is to rely on "magic" then that can be achieved by = using fewer m-lines in the bundle, in a way that dumps more streams/flows i= nto the same m-line. So this is really only an issue for plan A.

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

--047d7b86f6d2790cec04dd781ba9-- From pkyzivat@alum.mit.edu Fri May 24 08:11:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CEC21F86BB for ; Fri, 24 May 2013 08:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogmoie3jNio7 for ; Fri, 24 May 2013 08:11:28 -0700 (PDT) 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 9CE7C21F855F for ; Fri, 24 May 2013 08:11:22 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id foZD1l0011c6gX853rBJwH; Fri, 24 May 2013 15:11:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id frBJ1l00h3ZTu2S3jrBJSr; Fri, 24 May 2013 15:11:18 +0000 Message-ID: <519F8315.2090103@alum.mit.edu> Date: Fri, 24 May 2013 11:11:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Dale R. Worley" References: <519E5F54.3000806@alum.mit.edu> <201305232207.r4NM7Tlv5329814@shell01.TheWorld.com> In-Reply-To: <201305232207.r4NM7Tlv5329814@shell01.TheWorld.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=1369408278; bh=t73CNW5fY64Di5/6dlSzlZKzeZy+qVmewz3cVa/hs3U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qvopjmEcHRTUyKb2G5UerhqzIZ3kdUgu0siY6CJZstpeUtFqsO8v/ixm6NhyQIsHl YboiSqLvrAOvtNQWvheb/IAJCNRlYp3xfwmznfBWJU/sjbw6c2H5wHh6TzawPioOMM W1t7f+rKR2YIrxwxtXFDB7m5SEsJg9NlYbgy1thCcaYKWE64izF+nQdmLig5XdDUL+ 5xoMRX8Dzs1Se0HbdQV3avsuBvhbC+L4E/S+d6wJjPjC0KIuUArRemLD0l8dliYkLh PQUF42IzJHPAxWtFEcTt5BJFKLJdx9W3zeD1cGs7sqdm9xND5shokgRHX1zlNoPBxs HL226/UJGsQng== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 15:11:34 -0000 On 5/23/13 6:07 PM, Dale R. Worley wrote: >> From: Paul Kyzivat >> >> IMO the following should obviously be a truism. I want to know if all agree. >> >> If an O/A exchange negotiates a bundle with multiple m-lines, >> then attributes in those m-lines and the associated media sections must >> provide sufficient information to associate each incoming packet on the >> 5-tuple to exactly *one* of those m-lines. > > I agree. I think there are non-legacy situations where this need may > be relaxed, but all interoperation in legacy situations seems to > require discerning the appropriate m= line so information in the SDP > section can be used to identify the particular application processing > stream. ??? There aren't any legacy interoperation situations for bundle. >> [...] receiving packets that don't match any of the m-lines. I >> think we ought to address that, by defining some syntax to specify what >> to do with packets that don't match any m-line. This might be to specify >> one m-line as the default, or that packets that don't match be discarded. > > I think that discarding them is the only workable approach. There's > no reason to assume that sending them to a default m= line would allow > the upper level of demultiplexing to succeed. My thought was that the receiver could signal a "default m-line". This would need to be done for each classification criterion. E.g., a=ssrc:* ... would identify the m-line that should be used for otherwise unspecified ssrc values. a=new-header-extension:* would identify the m-line to use for packets carrying no header extension or an undeclared value. Any packet that still can't be classified after including such wildcards would be discarded. I don't think such wildcarding makes any sense for PT. Thanks, Paul From pkyzivat@alum.mit.edu Fri May 24 08:24:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC1621F89E2 for ; Fri, 24 May 2013 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.536 X-Spam-Level: X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_OBFU_RESULTING=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2zgKA8toz4R for ; Fri, 24 May 2013 08:24:04 -0700 (PDT) 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 F03B121F8540 for ; Fri, 24 May 2013 08:24:03 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id fnJX1l0051swQuc51rQ3gZ; Fri, 24 May 2013 15:24:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id frQ21l01Q3ZTu2S3brQ2lx; Fri, 24 May 2013 15:24:03 +0000 Message-ID: <519F8611.7000802@alum.mit.edu> Date: Fri, 24 May 2013 11:24:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> <519F2BD8.8060803@jitsi.org> <519F2F8B.5080004@jitsi.org> <519F7633.1010902@alum.mit.edu> <519F7FDC.2070001@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=1369409043; bh=MIWlvUGkhzyWV9uLiUtE5fkIG/YUkOzqq7vjAN9PGDo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ahsCvhBLmKxv7WQbZFr4LDpSiXHMnPvySrdeRWZHdvoKIZKgEmwyhAl/ToikBAov7 SKbTOb4qXTctaNYqV7QC/eotIFt54BiYF2D/RBEtBgIRiX/yMzvJPf6i5DPDQXsC3Y YOPvwtZxLwcuTxcEZsuzu0QqNl+gvKny0Pc2muxk/Avjw5Fk2ZyLYbxgmBFElEDEgW Xa7T5M7HEaBhQy0yB+pAQ50AnNur9ZcenkzbrXiixenmRUjwTN7avjcCl+GpHXRP3w OTWsRIW6dNOCKwdN/tjpNbN5C8/FDKCLY2KuybXHJCDvo0JKlj7pFkK0VZsbBiXU4s zGBvuUMiTC+rQ== Cc: mmusic Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 15:24:10 -0000 On 5/24/13 11:03 AM, Emil Ivov wrote: > Paul, > > This looks very much like what I suggested initially in my response to > Cullen, so I am not sure why you sound as if you are disagreeing. Looking back, there is some similarity, but still some difference. IIUC you are saying that the if the offerer doesn't know the capabilities of the answerer then it must construct the offer so that any possible answer that accepts the bundle will allow proper association to the correct m-line. And I am not saying that. I am saying that the offer may indeed depend on the answer supporting some mechanism specified in the offer in order to make the association unique. If the answerer doesn't recognize that mechanism (and so ignores it) it should be able then to recognize that the answer it would construct will not provide uniqueness. It then needs to fix that, by refusing the bundle, or refusing some of the m-lines, or whatever. Thanks, Paul > Emil > > --sent from my mobile > > On May 24, 2013 5:57 PM, "Paul Kyzivat" > wrote: > > On 5/24/13 10:40 AM, Emil Ivov wrote: > > On May 24, 2013 5:16 PM, "Paul Kyzivat" > >__> > wrote: > > > > On 5/24/13 5:14 AM, Emil Ivov wrote: > >> > >> On 24.05.13, 12:02, Kevin Dempsey wrote: > >>> > >>> I didn't say anything about changing the PTs. > >> > >> > >> Sorry, I misunderstood. > >> > >>> The answerer decides what > >>> it codecs it will use from the ones listed in the offer. > If it doesn't > >>> support any other mechanism to allow demux then it must > choose codecs > >>> that have PTs on only one m-line, or not accept the BUNDLE. > >> > >> > >> Matching packets to m= lines is the concern of the > receiving party. So > >> is the mechanism that it uses. What you are suggesting is > for the > >> answerer to basically say: "It seems to me that you won't > be able to > >> demux these two payloads so I will not send them to you > because I know > >> better". > >> > >> In the same time the offerer may be planning on using a > demux technique > >> that the answerer simply isn't aware of. For example (and > this is really > >> just to make a point, so please don't assume I am > suggesting something > >> like this in general) if 101 is mapped to both > telephone-event and VP8, > >> demuxing can be easily made without any other knowledge of > SSRC or > >> header extensions. > > > > > > ISTM that after the O/A exchange both sides need to have a > common > > understanding that their communications will be understandable. > > I assume this means you agree that an offerer has to make sure > at least > one of the demuxing mechanisms it supports will be understood by the > answerer. > > > No. But the offerer had better ensure that there is some way to > answer that meets the requirements. > > Then it becomes a requirement on the answerer to answer in a way > that makes the communication unambiguous. If it can't do that while > bundling then it must remove the bundle, or remove some m-lines from > the bundle, or reject some of the m-lines in the bundle, so that the > resullting answer constructs an unambiguous communication. > > If the intent is to rely on "magic" then that can be achieved by > using fewer m-lines in the bundle, in a way that dumps more > streams/flows into the same m-line. So this is really only an issue > for plan A. > > Thanks, > Paul > From martin.thomson@gmail.com Fri May 24 11:14:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFF021F8E8F for ; Fri, 24 May 2013 11:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.378 X-Spam-Level: X-Spam-Status: No, score=-4.378 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY5wWY9yX6Z9 for ; Fri, 24 May 2013 11:14:54 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 560F721F8E49 for ; Fri, 24 May 2013 11:14:53 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id o10so4912506lbi.22 for ; Fri, 24 May 2013 11:14:52 -0700 (PDT) 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=U3NP7JVTlKMbsrGdySKy1eKpNdLzOIBNxEMty1DXP3I=; b=PvdgmQn091pu/iJ/zhNsxVkoWZjyQfrgnsFtYTTba6W5bR0g8S/p6MaDveSXWu79HT fgRFGuoP1obB6FXQZ7PNt51D4+QTD8rWkI8nAKwDasANFbypg+DXO/jgTwbDd1J7/NW8 jt7YD6lcyQh8iKwfYX2I1umPrpvO/iaOYvul9SGjAB4EzlGNnd6DDAgkcSMnPjx6dQKP 45nLlnCCRnyqpy843s3iwlOABWtFtVvWRVMR/sTsznHg6COnev8IH3OsBSiwQmik4x5C /0icsQp62w+NAdC2PnEMKk9YniqtLYl2gHpTu9RjZXT/mS5VvHypVOW+G2gRQOJ8C/VE gRrQ== MIME-Version: 1.0 X-Received: by 10.112.149.8 with SMTP id tw8mr9326240lbb.117.1369419292670; Fri, 24 May 2013 11:14:52 -0700 (PDT) Received: by 10.112.122.40 with HTTP; Fri, 24 May 2013 11:14:52 -0700 (PDT) In-Reply-To: <519F7ADF.1010909@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C3777C9@ESESSMB209.ericsson.se> <519F7ADF.1010909@alum.mit.edu> Date: Fri, 24 May 2013 11:14:52 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:14:59 -0000 On 24 May 2013 07:36, Paul Kyzivat wrote: > The answer to an offer containing a bundle group may remove an m-line from > the bundle group if (and only if) the address/port of the m-line in the > offer is distinct from the address/port of all the other m-lines in the > offered bundle group. When doing so it must supply a unique address/port for > that m-line in the answer. Yes. That addresses most concerns. It gets even better when you consider that there is an expectation that any bundled m-line is "fixed up" to include the same transport parameters, thus "sealing the deal". From suhasietf@gmail.com Fri May 24 14:47:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7C621F9649 for ; Fri, 24 May 2013 14:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxfMzg-yD4qu for ; Fri, 24 May 2013 14:47:22 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 296B911E80E2 for ; Fri, 24 May 2013 14:47:22 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bv4so160862qab.19 for ; Fri, 24 May 2013 14:47:21 -0700 (PDT) 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=Kbl/50jmr1lS+LTlABG2NFLjq3Ty8MEEjF0UJRg3Ces=; b=ya74uGghJM/8IEBzGVTVhZFKZRNlMdM2cItrqmKyg2AIl1BR1NG8W2/sXAbqFlHXRy AriKm6luJZWKOrfSDh4QRTn8Jm5acHZ+LYE3kP2QAhWBoHSoRH+aFwqCP21ITjlujwrm b733xx51/tyBl92n49+HT+oyKKlZEXcbXx51oF2zPYPlRK2XFV250Lz9RbvC66Lv+Uh3 +EDP3mnnApM3Ne0nrA2aG28+x+xEk6tDpnyYfHC4JODU8Hq4ZreS+DKaoIKZBpcCyXVR TUpMktPETe+DzWC8B6ERU9n/J/C1HQqIPWmy5DXJMv1fFhvTWAe/+WwqM1fIwmPo3oM0 BxDQ== MIME-Version: 1.0 X-Received: by 10.49.60.98 with SMTP id g2mr21014373qer.51.1369432041625; Fri, 24 May 2013 14:47:21 -0700 (PDT) Received: by 10.49.6.97 with HTTP; Fri, 24 May 2013 14:47:21 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> Date: Fri, 24 May 2013 14:47:21 -0700 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b62450c62b7bb04dd7dbe85 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 21:47:23 -0000 --047d7b62450c62b7bb04dd7dbe85 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christer Please find my comments in line. On Fri, May 24, 2013 at 5:32 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi,**** > > ** ** > > At the interim meeting yesterday, we agreed on some restrictions regardin= g > creating SDP answers containing bundle group(s).**** > > ** ** > > Note that the restrictions 1-3 are simply alignments with RFC 5888, and > are listed simply for clarification purpose. Restrictions 4 is BUNDLE > specific. Restriction 5 is also alignment with RFC 5888, as m- lines with > port zero are not allowed within groups, but we will need some > clarification text saying that a new offer will have to be sent in order = to > remove a stream (either from a bundle group, or completely from the > session).**** > > ** ** > > (Note that the text below is not necessarily the wording that will go int= o > the draft)**** > > ** ** > > In an SDP answer:**** > > **1) **a BUNDLE group MUST NOT be created, unless it was included in > the associated offer**** > > **2) **an m- line MUST NOT be added to a BUNDLE group, unless it was > included in a BUNDLE group in the associated offer**** > > **3) **an m- line MUST NOT be added to another BUNDLE group than the > group in which was included in the associated offer**** > > **4) **an m- line MUST NOT be removed from a BUNDLE group if, in the > associated offer, an identical port number was indicated for all m- lines > in a BUNDLE group**** > > ** > [Suhas] .. RFC5888 doesn't clarify what does removing means. Hence, I would be happy to see 4) If a m-line is removed ( not rejected) in the Answer, then the m-line should include a unique port that doesn't collide with port associated with any BUNDLE groups. 5) **an m- line MUST NOT be rejected if, in the associated offer, an > identical port number was indicated for all m- lines in a BUNDLE group***= * > > ** > [Suhas]. I agree with Paul here. Rejecting a m-line MUST be allowed by the answerer by setting port to zero and removing mid from the BUNDLE group attribute line. This is special case where BUNDLE should be satisfied if a) Either all the port are identical b) Ports in the BUNDLE group can be zero (if rejected). > ** > > ** ** > > Note that there is also a discussion regarding bundle offers, e.g. when > restrictions when adding new m- lines to a bundle. Based on the outcome o= f > that, there may be some additional answer restrictions, e.g. regarding th= e > change of bundle transport parameters. But, let=92s deal with that in the > offer thread. > [Suhas] Agreed. > So, if anyone OBJECTS to the restrictions above, please indicate so.**** > > ** ** > > Regards,**** > > ** ** > > Christer**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --047d7b62450c62b7bb04dd7dbe85 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christer
=A0
=A0 Please find my comments in line.

<= div class=3D"gmail_quote">On Fri, May 24, 2013 at 5:32 AM, Christer Holmber= g <christer.holmberg@ericsson.com> wrote:

Hi,

=A0

At the interim meeting yesterday, we agreed on some = restrictions regarding creating SDP answers containing bundle group(s).<= /u>

=A0

Note that the restrictions 1-3 are simply alignments= with RFC 5888, and are listed simply for clarification purpose. Restrictio= ns 4 is BUNDLE specific. Restriction 5 is also alignment with RFC 5888, as = m- lines with port zero are not allowed within groups, but we will need some clarification text saying that a new = offer will have to be sent in order to remove a stream (either from a bundl= e group, or completely from the session).

=A0

(Note that the text below is not necessarily the wor= ding that will go into the draft)

=A0

In an SDP answer:

1)=A0= =A0=A0=A0=A0 a BUNDLE group MUST NOT be created, unless it was incl= uded in the associated offer

2)=A0= =A0=A0=A0=A0 an m- line MUST NOT be added to a BUNDLE group, unless= it was included in a BUNDLE group in the associated offer

3)=A0= =A0=A0=A0=A0 an m- line MUST NOT be added to another BUNDLE group t= han the group in which was included in the associated offer

4)=A0= =A0=A0=A0=A0 an m- line MUST NOT be removed from a BUNDLE group if,= in the associated offer, an identical port number was indicated for all m-= lines in a BUNDLE group

=A0 [Suhas] =A0.. RFC= 5888 doesn't clarify what does removing means. Hence, I would be happy = to see 4)=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If a m-line is r= emoved ( not rejected) in the Answer, then the m-line should include a uniq= ue port that doesn't collide with port associated with any BUNDLE group= s.

5)=A0=A0=A0=A0=A0 an m- line MUST NOT be rejected if, in the associated = offer, an identical port number was indicated for all m- lines in a BUNDLE = group

=A0[Suhas].= I agree with Paul here. Rejecting a m-line MUST be allowed by the answerer= by setting port to zero and removing mid from the BUNDLE group attribute l= ine. This is special case where BUNDLE should be satisfied if
=A0 =A0 =A0 =A0 =A0 =A0 a) Either all the port are identical
=A0 =A0 =A0 =A0 =A0 =A0 b) Ports in the BUNDLE group can be zero (if rejec= ted).=A0

=A0

=A0

Note that there is also a discussion regarding bundl= e offers, e.g. when restrictions when adding new m- lines to a bundle. Base= d on the outcome of that, there may be some additional answer restrictions,= e.g. regarding the change of bundle transport parameters. But, let=92s deal with that in the offer thread.

=

=A0[Suhas] Agreed.=A0
=A0

So, if anyone OBJECTS to the restrictions above, ple= ase indicate so.

=A0

Regards,

=A0

Christer

=A0

=A0

=A0

=A0

=A0


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


--047d7b62450c62b7bb04dd7dbe85-- From suhasietf@gmail.com Fri May 24 14:48:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB20311E811F for ; Fri, 24 May 2013 14:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlX6YFETU3gs for ; Fri, 24 May 2013 14:48:53 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id CE4C321F9649 for ; Fri, 24 May 2013 14:48:52 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id bn16so161197qab.2 for ; Fri, 24 May 2013 14:48:52 -0700 (PDT) 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=JRTw87yETLWJQy1KhVAUVnewdodApf390FI9KxqYztY=; b=aj2TkRYK/9JK68Kw7Z9s0ec/VrcvDge5qV0zsY9YOzVHotNi4ubVrq3kJxmfqKugXR 5fuSAU769tzlQ0JNc6zA0ingPFqYMkMgnKvQkJbqk1WfMg/jonD/xP7TpC8UYIW9N5H7 yablCc4ImfiMoFlRWVncLQZVauCMughgw42YS+iBuG37S3B9+TNb2/Ax9Ki7j1xomtgg sRZA2iOVtvfcZEm0EZhp4H7qFYs8rB+f1MM0cBSe6cE3ewqSKbObCxkuPPCXg+A/SWuu FwigoIX5zGGucsjqv0or01uJwlmgdlyJ4BCWxfZecqRw5AmzlabUk8/yLoGIV3CS1UVZ Qr6A== MIME-Version: 1.0 X-Received: by 10.49.51.166 with SMTP id l6mr21130285qeo.4.1369432132240; Fri, 24 May 2013 14:48:52 -0700 (PDT) Received: by 10.49.6.97 with HTTP; Fri, 24 May 2013 14:48:52 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> Date: Fri, 24 May 2013 14:48:52 -0700 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bd6b0f6c96ab304dd7dc3ae Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 21:48:54 -0000 --047d7bd6b0f6c96ab304dd7dc3ae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Forgot to clarify the port zero below to say "pending on RFC5888 update" On Fri, May 24, 2013 at 2:47 PM, Suhas Nandakumar wrot= e: > Hi Christer > > Please find my comments in line. > > On Fri, May 24, 2013 at 5:32 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi,**** >> >> ** ** >> >> At the interim meeting yesterday, we agreed on some restrictions >> regarding creating SDP answers containing bundle group(s).**** >> >> ** ** >> >> Note that the restrictions 1-3 are simply alignments with RFC 5888, and >> are listed simply for clarification purpose. Restrictions 4 is BUNDLE >> specific. Restriction 5 is also alignment with RFC 5888, as m- lines wit= h >> port zero are not allowed within groups, but we will need some >> clarification text saying that a new offer will have to be sent in order= to >> remove a stream (either from a bundle group, or completely from the >> session).**** >> >> ** ** >> >> (Note that the text below is not necessarily the wording that will go >> into the draft)**** >> >> ** ** >> >> In an SDP answer:**** >> >> **1) **a BUNDLE group MUST NOT be created, unless it was included >> in the associated offer**** >> >> **2) **an m- line MUST NOT be added to a BUNDLE group, unless it >> was included in a BUNDLE group in the associated offer**** >> >> **3) **an m- line MUST NOT be added to another BUNDLE group than >> the group in which was included in the associated offer**** >> >> **4) **an m- line MUST NOT be removed from a BUNDLE group if, in >> the associated offer, an identical port number was indicated for all m- >> lines in a BUNDLE group**** >> >> ** >> > [Suhas] .. RFC5888 doesn't clarify what does removing means. Hence, I > would be happy to see 4) > If a m-line is removed ( not rejected) in the Answer, > then the m-line should include a unique port that doesn't collide with po= rt > associated with any BUNDLE groups. > > 5) **an m- line MUST NOT be rejected if, in the associated offer, an >> identical port number was indicated for all m- lines in a BUNDLE group**= * >> * >> >> ** >> > [Suhas]. I agree with Paul here. Rejecting a m-line MUST be allowed by > the answerer by setting port to zero and removing mid from the BUNDLE gro= up > attribute line. This is special case where BUNDLE should be satisfied if > a) Either all the port are identical > b) Ports in the BUNDLE group can be zero (if rejected). > >> ** >> >> ** ** >> >> Note that there is also a discussion regarding bundle offers, e.g. when >> restrictions when adding new m- lines to a bundle. Based on the outcome = of >> that, there may be some additional answer restrictions, e.g. regarding t= he >> change of bundle transport parameters. But, let=92s deal with that in th= e >> offer thread. >> > > [Suhas] Agreed. > > >> So, if anyone OBJECTS to the restrictions above, please indicate so.***= * >> >> ** ** >> >> Regards,**** >> >> ** ** >> >> Christer**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --047d7bd6b0f6c96ab304dd7dc3ae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Forgot to clarify the port zero below to say "pending on RFC5888 updat= e"

On Fri, May 24, 2013 at 2:47 PM, = Suhas Nandakumar <suhasietf@gmail.com> wrote:
Hi Christer
=A0
=A0 Please fin= d my comments in line.

= On Fri, May 24, 2013 at 5:32 AM, Christer Holmberg <christer.= holmberg@ericsson.com> wrote:

Hi,

=A0

At the interim meeting yesterday, we agreed on some = restrictions regarding creating SDP answers containing bundle group(s).<= /u>

=A0

Note that the restrictions 1-3 are simply alignments= with RFC 5888, and are listed simply for clarification purpose. Restrictio= ns 4 is BUNDLE specific. Restriction 5 is also alignment with RFC 5888, as = m- lines with port zero are not allowed within groups, but we will need some clarification text saying that a new = offer will have to be sent in order to remove a stream (either from a bundl= e group, or completely from the session).

=A0

(Note that the text below is not necessarily the wor= ding that will go into the draft)

=A0

In an SDP answer:

1)=A0= =A0=A0=A0=A0 a BUNDLE group MUST NOT be created, unless it was incl= uded in the associated offer

2)=A0= =A0=A0=A0=A0 an m- line MUST NOT be added to a BUNDLE group, unless= it was included in a BUNDLE group in the associated offer

3)=A0= =A0=A0=A0=A0 an m- line MUST NOT be added to another BUNDLE group t= han the group in which was included in the associated offer

4)=A0= =A0=A0=A0=A0 an m- line MUST NOT be removed from a BUNDLE group if,= in the associated offer, an identical port number was indicated for all m-= lines in a BUNDLE group

=A0 [Suhas] =A0= .. RFC5888 doesn't clarify what does removing means. Hence, I would be = happy to see 4)=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If a m-lin= e is removed ( not rejected) in the Answer, then the m-line should include = a unique port that doesn't collide with port associated with any BUNDLE= groups.

5)=A0=A0=A0=A0=A0 an m- line MUST NOT be rejected if, in the associated = offer, an identical port number was indicated for all m- lines in a BUNDLE = group

=A0[S= uhas]. I agree with Paul here. Rejecting a m-line MUST be allowed by the an= swerer by setting port to zero and removing mid from the BUNDLE group attri= bute line. This is special case where BUNDLE should be satisfied if
=A0 =A0 =A0 =A0 =A0 =A0 a) Either all the port are identical
=A0 =A0 =A0 =A0 =A0 =A0 b) Ports in the BUNDLE group can be zero (if rejec= ted).=A0

=A0

=A0

Note that there is also a discussion regarding bundl= e offers, e.g. when restrictions when adding new m- lines to a bundle. Base= d on the outcome of that, there may be some additional answer restrictions,= e.g. regarding the change of bundle transport parameters. But, let=92s deal with that in the offer thread.

=

=A0[Suhas] Agreed.=A0
=A0

So, if anyone OBJECTS to the restrictions above, ple= ase indicate so.

=A0

Regards,=

=A0

Christer

=A0

=A0

=A0

=A0

=A0


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



--047d7bd6b0f6c96ab304dd7dc3ae-- From suhasietf@gmail.com Fri May 24 15:12:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6277F21F8A74 for ; Fri, 24 May 2013 15:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlSl4IUxCyXA for ; Fri, 24 May 2013 15:12:02 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 15D9821F89FF for ; Fri, 24 May 2013 15:12:01 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id cz11so2913001qeb.15 for ; Fri, 24 May 2013 15:12:01 -0700 (PDT) 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=6OE0mWLtm+kXM+5zLVioCZk8K4S+gw/ICVF5FIUDvQY=; b=saKNm9PcbrjqS6H1bRetGf3VxD5hrfqqJ5Z5X5oV/OIa0OZwhfZMswpqJrvQ6V1cX2 iKPpjld7He4sIIKu2S4QqvACjemSHG175u0yv4WsvL3KXuYLeNC2ILjsrK/es+9yEUN5 /iG9y1eVEeMblZRoyHAki+5vB+6sJkR2sjxG2siox3oXjJpC65Iu1f0c7XNJSbS7lTvF MzBmSfJor7wId1JrBJVXzxq4mUmvHHjMZpZeuiRQX7Ab2dTJhfl82eo9xLVBYFU6krsJ gDJwUFfWeleOTtqBc85ZyhdVgbD3fkwcRCLXR+Qbah9Bc4+gUzfFFmvOpQk8JsZK20Wf 4gdg== MIME-Version: 1.0 X-Received: by 10.224.79.209 with SMTP id q17mr17932886qak.88.1369433521514; Fri, 24 May 2013 15:12:01 -0700 (PDT) Received: by 10.49.6.97 with HTTP; Fri, 24 May 2013 15:12:01 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3777C9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3777C9@ESESSMB209.ericsson.se> Date: Fri, 24 May 2013 15:12:01 -0700 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bf161769820eb04dd7e160d Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 22:12:06 -0000 --047d7bf161769820eb04dd7e160d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hey Christer This looks good ( including Paul's clarification and Martin's statement about Expectation of the following fixup to make intermediaries happy). Also few comments inline. On Fri, May 24, 2013 at 3:28 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi,**** > > ** ** > > At the interim yesterday, we agreed that an answerer MUST always include > identical ports* (usage of port zero within a bundle is a separate topic) > for all m- lines within an bundle group. **** > > ** > ** > > If the answerer wants to use different ports* for some/all m- lines, it > MUST NOT include those m- lines in a bundle group (if they already are in= a > bundle group, a separate offer is needed to remove them). > [Suhas] If the answerer wants to use different ports for "ALL" the m-lines then it is implicitly assumed that there was a Successful O/A exchange + Fixup and this Offer is a subsequent one. On the other hand, changing some ports in the Answer can even happen in the first ever BUNDLE O/A as well. Just wanted to clarify with the wordings. > > **** > > ** ** > > WHAT IT MEANS: There is no way for an answerer to tell that the offerer, > for certain m- lines, can use the same port*, eventhough the answer will > use separate ports*.**** > > ** ** > > I will work on some actual text proposal later, but please indicate if yo= u > OBJECT to this approach in general.**** > > ** ** > > Regards,**** > > ** ** > > Christer**** > > ** ** > > NOTE: =93port=94 =3D port:address combination =96 we are working on comin= g up with > better terminology J**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --047d7bf161769820eb04dd7e160d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hey Christer

=A0=A0=A0This looks good ( including Paul&#= 39;s clarification and Martin's statement about Expectation of the foll= owing fixup to make intermediaries happy).

Also fe= w comments inline.

On Fri, May 24, 2013 at 3:28 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

=A0

At the interim yesterday, we agreed that an answerer= MUST always include identical ports* (usage of port zero within a bundle i= s a separate topic) for all m- lines within an bundle group.

=A0=A0

If the answerer wants to use different ports* for so= me/all m- lines, it MUST NOT include those m- lines in a bundle group (if t= hey already are in a bundle group, a separate offer is needed to remove the= m).


[Suhas] If the answerer wants = to use different ports for "ALL" the m-lines then it is implicitl= y assumed that there was a Successful O/A exchange + Fixup and this Offer i= s a subsequent one.=A0
On the other hand, changing some ports in the Answer can even happen i= n the first ever BUNDLE O/A as well.
Just wanted to clarify with = the wordings.

=A0

=A0

WHAT IT MEANS: There is no way for an answerer to te= ll that the offerer, for certain m- lines, can use the same port*, eventhou= gh the answer will use separate ports*.

=A0

I will work on some actual text proposal later, but = please indicate if you OBJECT to this approach in general.

=A0

Regards,

=A0

Christer

=A0

NOTE: =93port=94 =3D port:address combination =96 we= are working on coming up with better terminology J

=A0

=A0

=A0

=A0

=A0

=A0


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


--047d7bf161769820eb04dd7e160d-- From suhasietf@gmail.com Fri May 24 16:00:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C88F11E8135 for ; Fri, 24 May 2013 16:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFCGXy6YjUm9 for ; Fri, 24 May 2013 16:00:51 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4702111E80A5 for ; Fri, 24 May 2013 16:00:51 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id l11so2663927qcy.23 for ; Fri, 24 May 2013 16:00:45 -0700 (PDT) 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=+yeh9Gh3qjqZVPkve9l1cTY9OuT4VywYP6U65itayQ0=; b=M8YwCBOBeGYabJE4vb3ZO71mRc0XZfR4X1P1JlneLyLJyFBJPIQ8dPRy7a5zQlD6aC 0Tfv9V38xYd01eZJx5hg1s6Ftb714Hz9V5cfcqvLfa0zB1mvuvg9e8jUNIbFcfAJ92Dz kpqY2Jorj73HdQXyUJcGPeD9CfOvPhVMmBX5JUpdbR10N09PrW32F88qmjgl/+pNMUZv BOPMhuNZlBoiChuCfuPim6TYAd7eJgQnaPMuqZwoQjzst0LsMVemywjXDWq2FgJoYqgd QczfN6jVKbe+JlwaxprhbiUE80lBLnyOktSwkCUMPaT9NCcWrlyaMx+yLh9tRBQiWu4E xAQw== MIME-Version: 1.0 X-Received: by 10.224.120.2 with SMTP id b2mr18274325qar.67.1369436445064; Fri, 24 May 2013 16:00:45 -0700 (PDT) Received: by 10.49.6.97 with HTTP; Fri, 24 May 2013 16:00:44 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> Date: Fri, 24 May 2013 16:00:44 -0700 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2d418d9dd0104dd7ec414 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 23:00:52 -0000 --001a11c2d418d9dd0104dd7ec414 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hey Christer This looks good to me. I personally feel this approach is agnostic of inclusions and exclusions of m=3Dlines in the subsequent session modifications "Eventually". Also this aligns with the current framework for categorizing SDP attributes with multiplexing. Cheers Suhas On Fri, May 24, 2013 at 5:39 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi,**** > > ** ** > > At the interim yesterday, we agreed to use the SDP BUNDLE group attribute > to indicate on which port bundled media will be sent. In an SDP offer, th= e > order of the attribute mid values can be used by the offerer to indicate = a > =93wish=94, but the first attribute mid value in the answer indicates whe= re the > answerer will eventually send bundled media.**** > > ** ** > > The main usage of this is the =93initial offer=94, when each m- line with= in a > bundle group has a different port value.**** > > ** ** > > So far so good.**** > > ** ** > > The reason I say =93almost decision=94 is because we have started a new > discussion regarding updated offers, adding new m- lines etc. We need to > make sure that the order-to-mid-values semantics also apply to those, and > what restrictions there are when adding m- lines.**** > > ** ** > > But, for now, if you OBJECT to the general principle of using the SDP > group attribute mid value order for indicating the port where media will = be > sent, please indicate so.**** > > ** ** > > Regards,**** > > ** ** > > Christer**** > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a11c2d418d9dd0104dd7ec414 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hey Christer

=A0 =A0This looks good to me. I personally = feel this approach is agnostic of inclusions and exclusions of m=3Dlines in= =A0the subsequent session modifications "Eventually".=A0
Also this aligns with the current framework for categorizing SDP=A0attri= butes=A0with multiplexing.

Cheers
Suhas

On Fri, May 24, 2013 at 5:39 AM, Christer Holmberg <= christe= r.holmberg@ericsson.com> wrote:

Hi,

=A0

At the interim yesterday, we agreed to use the SDP B= UNDLE group attribute to indicate on which port bundled media will be sent.= In an SDP offer, the order of the attribute mid values can be used by the = offerer to indicate a =93wish=94, but the first attribute mid value in the answer indicates where the answerer w= ill eventually send bundled media.

=A0

The main usage of this is the =93initial offer=94, w= hen each m- line within a bundle group has a different port value.

=A0

So far so good.

=A0

The reason I say =93almost decision=94 is because we= have started a new discussion regarding updated offers, adding new m- line= s etc. We need to make sure that the order-to-mid-values semantics also app= ly to those, and what restrictions there are when adding m- lines.

=A0

But, for now, if you OBJECT to the general principle= of using the SDP group attribute mid value order for indicating the port w= here media will be sent, please indicate so.

=A0

Regards,

=A0

Christer


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


--001a11c2d418d9dd0104dd7ec414-- From bernard_aboba@hotmail.com Fri May 24 17:18:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B4B11E8141 for ; Fri, 24 May 2013 17:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULe7Tm3D3eLn for ; Fri, 24 May 2013 17:18:30 -0700 (PDT) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6D72711E8143 for ; Fri, 24 May 2013 17:18:27 -0700 (PDT) Received: from BLU403-EAS112 ([65.55.116.73]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 May 2013 17:18:27 -0700 X-EIP: [JcVfHe9imPBubZTNsPPa5d0+PTwIVEDD] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-DC08A938-3DF9-4F2F-BFA6-D43680B18BB1" Content-Transfer-Encoding: 7bit References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Fri, 24 May 2013 13:01:37 -0700 To: mmusic@ietf.org X-OriginalArrivalTime: 25 May 2013 00:18:27.0046 (UTC) FILETIME=[6081D060:01CE58DD] Cc: Christer Holmberg Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 00:18:37 -0000 --Apple-Mail-DC08A938-3DF9-4F2F-BFA6-D43680B18BB1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBPbiBGcmksIE1heSAzLCAyMDEzIGF0IDU6NTMgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4gSGksDQo+PiANCj4+ICANCj4+ IA0KPj4gSW4gb3JkZXIgdG8gdHJ5IHRvIGNsb3NlIGlzc3VlcyBvbiBCVU5ETEUsIGJhc2VkIG9u IHRoZSBkaXNjdXNzaW9ucyB3ZeKAmXZlIGhhZCwgSSBpbnRlbmQgdG8gdXBkYXRlIHRoZSBCVU5E TEUgZHJhZnQgYmFzZWQgb24gdGhlIGZvbGxvd2luZyBhc3N1bXB0aW9uczoNCj4+IA0KPj4gIA0K Pj4gDQo+PiAxLiAgICAgICBXZSBtYW5kYXRlIHVzYWdlIG9mIHJ0Y3AtbXV4IHdoZW4gQlVORExF IGlzIHVzZWQuDQo+PiANCg0KW0JBXSBBZ3JlZWQuDQo+PiAyLiAgICAgICBTRFAgbS0gbGluZXMg d2l0aCBhIHplcm8gcG9ydCB2YWx1ZSBNVVNUIE5PVCBiZSBwdXQgaW5zaWRlIGEgQlVORExFIGdy b3VwIChub3QgaW4gYW4gb2ZmZXIsIG5vciBpbiBhbiBhbnN3ZXIpLiBUaGVyZSB3aWxsIGJlIGEg bm90ZSBpbmRpY2F0aW5nIHRoYXQsIGR1ZSB0byB0aGlzLCB0aGUgbnVtYmVyIG9mIG0tIGxpbmVz IGFzc29jaWF0ZWQgd2l0aCBhIEJVTkRMRSBncm91cCBtYXkgZGlmZmVyIGJldHdlZW4gdGhlIG9m ZmVyIGFuZCB0aGUgYXNzb2NpYXRlZCBhbnN3ZXIuIFRoZXJlIHdpbGwgYWxzbyBiZSBhIG5vdGUg aW5kaWNhdGluZyB0aGF0IHRoaXMgaXMgZHVlIHRvIFJGQyA1ODg4LCBpbiBjYXNlIHBlb3BsZSBs YXRlciBzdGFydCB0byB3b25kZXIgd2hlcmUgdGhlIOKAnE1VU1QgTk9U4oCdIGNvbWVzIGZyb20u DQo+PiANCltCQV0gRGlzYWdyZWUuIA== --Apple-Mail-DC08A938-3DF9-4F2F-BFA6-D43680B18BB1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxkaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiBGcmksIE1heSAzLCAyMDEzIGF0IDU6NTMgQU0sIENocmlzdGVyIEhvbG1i ZXJnIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQoNCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KDQoNCg0KDQoNCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkZJIj5IaSw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJGSSI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SW4gb3JkZXIgdG8gdHJ5IHRvIGNsb3NlIGlzc3VlcyBvbiBCVU5E TEUsIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyB3ZeKAmXZlIGhhZCwgSSBpbnRlbmQgdG8gdXBk YXRlIHRoZSBCVU5ETEUgZHJhZnQgYmFzZWQgb24gdGhlIGZvbGxvd2luZyBhc3N1bXB0aW9uczo8 dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9wPg0KPHA+PHU+PC91PjxzcGFuPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PHU+PC91PldlIG1hbmRhdGUgdXNhZ2Ugb2YgcnRjcC1tdXggd2hl biBCVU5ETEUgaXMgdXNlZDx1Pi48L3U+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rp dj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+W0JBXSBBZ3JlZWQuPGJy PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+PGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8cD48 dT48L3U+PHNwYW4+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48dT48L3U+U0RQIG0tIGxpbmVzIHdpdGggYSB6ZXJvIHBvcnQgdmFsdWUgTVVTVCBOT1Qg YmUgcHV0IGluc2lkZSBhIEJVTkRMRSBncm91cCAobm90IGluIGFuIG9mZmVyLCBub3IgaW4gYW4g YW5zd2VyKS4gVGhlcmUgd2lsbCBiZSBhIG5vdGUgaW5kaWNhdGluZyB0aGF0LCBkdWUgdG8gdGhp cywgdGhlIG51bWJlciBvZiBtLSBsaW5lcyBhc3NvY2lhdGVkIHdpdGggYSBCVU5ETEUgZ3JvdXAg bWF5IGRpZmZlciBiZXR3ZWVuDQogdGhlIG9mZmVyIGFuZCB0aGUgYXNzb2NpYXRlZCBhbnN3ZXIu IFRoZXJlIHdpbGwgYWxzbyBiZSBhIG5vdGUgaW5kaWNhdGluZyB0aGF0IHRoaXMgaXMgZHVlIHRv IFJGQyA1ODg4LCBpbiBjYXNlIHBlb3BsZSBsYXRlciBzdGFydCB0byB3b25kZXIgd2hlcmUgdGhl IOKAnE1VU1QgTk9U4oCdIGNvbWVzIGZyb20uPC9wPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48 L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj5bQkFdIERpc2FncmVlLiZuYnNwOzwvZGl2PjwvYm9keT48 L2h0bWw+ --Apple-Mail-DC08A938-3DF9-4F2F-BFA6-D43680B18BB1-- From bernard_aboba@hotmail.com Fri May 24 17:18:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9A21E8095 for ; Fri, 24 May 2013 17:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.362 X-Spam-Level: X-Spam-Status: No, score=-101.362 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR7iXs06ShCB for ; Fri, 24 May 2013 17:18:42 -0700 (PDT) Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by ietfa.amsl.com (Postfix) with ESMTP id 87D9611E812D for ; Fri, 24 May 2013 17:18:38 -0700 (PDT) Received: from BLU403-EAS112 ([65.55.111.71]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 May 2013 17:18:38 -0700 X-EIP: [8Vjm1JD5sQgJdJ6uRntYzxxQYv8IJhSE] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <519E5F54.3000806@alum.mit.edu> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <519E5F54.3000806@alum.mit.edu> Date: Fri, 24 May 2013 12:34:50 -0700 To: Paul Kyzivat X-OriginalArrivalTime: 25 May 2013 00:18:38.0218 (UTC) FILETIME=[672A86A0:01CE58DD] Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 00:18:47 -0000 On May 23, 2013, at 11:50, "Paul Kyzivat" wrote: > After all the discussion in the meeting today, I thought it would be good t= o unwind all the indenting and start a new thread on one issue that is part o= f the "demux" problem: >=20 > IMO the following should obviously be a truism. I want to know if all agre= e. >=20 > If an O/A exchange negotiates a bundle with multiple m-lines, > then attributes in those m-lines and the associated media sections must pr= ovide sufficient information to associate each incoming packet on the 5-tupl= e to exactly *one* of those m-lines. [BA] I would argue that this statement needs to be true for *both* RTP and R= TCP packets. > (If it doesn't, then there was no point in including those m-lines in the b= undle.) >=20 > For instance a=3Dssrc, if unique to one m-line, can bind packets with that= SSRC to the m-line. [BA] That is only necessary for RTP (and RTCP) if the PT is not unique to an= m line; otherwise PT demux is sufficient for RTP. For RTCP the situation i= s more complicated. If we only need to bind RTCP packets from RTP senders, w= e can build an SSRC to PT to m line table dynamically, based on SSRCs and PT= s seen in RTP packets. However if we get a RR from a source that has not ye= t sent, we can't map it to an m line without a=3Dssrc if BUNDLE is in use. =20= > If a property such as SSRC is used this way, then there is the possibility= of receiving packets that don't match any of the m-lines. I think we ought t= o address that, by defining some syntax to specify what to do with packets t= hat don't match any m-line. This might be to specify one m-line as the defau= lt, or that packets that don't match be discarded. [BA] I do not believe that a default m line makes sense for RTCP packets tha= t can't be bound to an m line. Discard, while undesirable, seems like the o= nly option. However this could create problems in diagnostics in some cases.= From partha@parthasarathi.co.in Sun May 26 03:58:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D789221F8EAF for ; Sun, 26 May 2013 03:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XQvXAiWVKBQ for ; Sun, 26 May 2013 03:58:28 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.233]) by ietfa.amsl.com (Postfix) with ESMTP id 37E9E21F8F33 for ; Sun, 26 May 2013 03:58:25 -0700 (PDT) Received: from userPC (unknown [122.179.102.212]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 19C2C3E670C; Sun, 26 May 2013 10:58:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1369565905; bh=dV+TtrVnFM/gcXfSuQicZMuW0Km14e2suDW+MlA6e+g=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jcLHWNeCTrmjDqXdg7yLq64rJo2HgTZaK0jyfF1NTjpHTiMzVGhPXP8gjT8kV3Iyv KvxPZM9yabJS7eYtWds9c5b2BHkp8P5di7VABVYekvw/Ubeoc1PPNln7BHOVLmES5g NVC+PhVSb208wQvhf90kzI2VT11P4V5pw9avISyU= From: "Parthasarathi R" To: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , "'Dale R. Worley'" References: <20130520161935.17435.91264.idtracker@ietfa.amsl.com> <002801ce564b$51e52230$f5af6690$@co.in> <201305230204.r4N247r25245471@shell01.TheWorld.com> <007601ce57e1$b15a5b30$140f1190$@co.in> <201305232207.r4NM7nFn5297137@shell01.TheWorld.com> In-Reply-To: Date: Sun, 26 May 2013 16:28:16 +0530 Message-ID: <004b01ce59ff$f17ff330$d47fd990$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOWAIBpBvYmClCD0e8SeThOrsMVpkTu0owgAOK3vA= Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0201.51A1EAD1.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: "'Cullen Jennings \(fluffy\)'" , mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 10:58:32 -0000 Dale, Thanks for the closure. Cullen & all, Hope the below proposed text is fine with you. The text will be added in the next revision for both g729 annnexb & g723 annexa in case there is no objection for an week. BTW, it is the only one update pending in this draft and there is no other open item. Thanks Partha > -----Original Message----- > From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Friday, May 24, 2013 9:50 AM > To: Dale R. Worley; Parthasarathi R > Cc: Cullen Jennings (fluffy); mmusic@ietf.org > Subject: RE: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729- > 01.txt > > |Since the annexb attribute is part of the (original) registration of > |audio/g729, any endpoint that implements that media type understands > |the annexb attribute. If the answer does not include the annexb > |attribute, the answerer knows that it has implied the default > |"annexb=yes". > > Thank you for the clarifying text. We'll include it in the next > revision of the draft. > > Muthu > > |-----Original Message----- > |From: Dale R. Worley [mailto:worley@ariadne.com] > |Sent: Friday, May 24, 2013 3:38 AM > |To: Parthasarathi R > |Cc: Cullen Jennings (fluffy); mmusic@ietf.org; Muthu Arul Mozhi > Perumal (mperumal) > |Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729- > 01.txt > | > |> From: "Parthasarathi R" > |> > |> If the answerer supports RFC3551, then the answerer has to support > RFC3555 > |> for annexb parameter. Annexb value default value is "Yes" in RFC > 3555 as per > |> RFC 3551. RFC 4856 obsoletes RFC 3555 without changing "annexb" > related > |> requirement. Please let me know any reason that you wish to change > AnnexB > |> parameter default value now. > | > |Sorry, my mistake, I didn't realize that "annexb" is not an extension > |of audio/g729, it's defined in the base specification: > | > |RFC 4856 section 2.1.9 > | > | Registration of Media Type audio/G729 > | > | Type name: audio > | Subtype name: G729 > | Optional parameters: > | [...] > | annexb: indicates that Annex B, voice activity detection, is > | used or preferred. Permissible values are "yes" and "no" > | (without the quotes); "yes" is implied if this parameter is > | omitted. > | > |So the answer to Cullen's query is: > | > |> From: "Cullen Jennings (fluffy)" > |> > |> What happens when an endpoint that understands the anexb attribute > |> sends and offer to an endpoint that does not understand or implement > |> the anexb attribute ? > | > |Since the annexb attribute is part of the (original) registration of > |audio/g729, any endpoint that implements that media type understands > |the annexb attribute. If the answer does not include the annexb > |attribute, the answerer knows that it has implied the default > |"annexb=yes". > | > |Dale From partha@parthasarathi.co.in Sun May 26 05:00:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE5B21F8551 for ; Sun, 26 May 2013 05:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf2s32Hopq4F for ; Sun, 26 May 2013 05:00:39 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9561321F9019 for ; Sun, 26 May 2013 05:00:39 -0700 (PDT) Received: from userPC (unknown [122.179.102.212]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 028EA3E60CE; Sun, 26 May 2013 12:00:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1369569639; bh=b9kn9D9F+EjHAjwuJbPSIre5BNK3f8rfFKvU3KAjDqY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZgwViSMx+Pjs810+XEym4vmEfm/YMomv65hFP1JgIGG41wHrtTSPUk5hKT3tTXDQ6 CHtluyfsExjemxXGuQ7uOnPwMhVQ6gCJOvr95+7u1dlRllMOuzvHchMAZVZSzO+6v+ m9AChcCj3O1HRge3jvHoweuga9nItV+Tq4+BdP3A= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Dale R. Worley'" , "'Paul Kyzivat'" References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> <201305232206.r4NM6l5C5338062@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C377609@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C377609@ESESSMB209.ericsson.se> Date: Sun, 26 May 2013 17:30:30 +0530 Message-ID: <004d01ce5a08$a3193720$e94ba560$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOV9u/fklHpYO4tka0o0wHa47jypkTW/u2gACjmhCAA1ChYA== Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0205.51A1F967.0035, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 12:00:44 -0000 Dale/Christer, Forking has to be seen with the RTP role (endpoint, translator, mixer) as the offer/answer exchange varies drastically for each RTP role. SIP forking with RTP endpoint issues are explained as part of Sec 3.1 of RFC 3960. One of the complexity introduced as part of BUNDLE is to have two offer/answer before consolidating. The offer/answer interaction between SIP forking with RTP endpoint and BUNDLE has to be mentioned. I'll explain with the SIP serial forking with RTP endpoint scenario for more clarity 1) INVITE with SDP having BUNDLE offer and different port in each m-line is send out from UAC 2) 183 with SDP and BUNDLE support is received from UAS1 3) UPDATE with SDP having BUNDLE offer and single port in each m-line is send towards UAS1 after completing PRACK & 200 4) 183 with SDP and BUNDLE support is received from UAS2 Here at Step 4, it is not possible for UAC to "mute" UAS1 as one another OFFER is initiated already at Step 3 and BUNDLE forces to "mute" the answer UAS2. This limitation has to be mentioned as part of BUNDLE. Please let me know your opinion on this. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Friday, May 24, 2013 1:55 PM > To: Dale R. Worley; Paul Kyzivat > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] When a bundle offer is forked > > Hi, > > I agree with Dale. Each early dialog is handled separately. > > From a standards perspective, I don't think we need to say much about > forking in BUNDLE, other than maybe some general words that it may > happen. > > Then, whether it becomes tricky to implement, e.g. if one early leg > uses BUNDLE and another doesn't, is another issue. But, as SIP has > mechanisms to terminate early dialogs you don't like etc, I see this as > a pure implementation issue. > > Regards, > > Christer > > > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Dale R. Worley > Sent: 24. toukokuuta 2013 1:07 > To: Paul Kyzivat > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] When a bundle offer is forked > > > From: Paul Kyzivat > > > > On 5/23/13 6:35 AM, Emil Ivov wrote: > > > > > In case a bundle offer gets forked and various answers ... > > > > I trimmed everything else out of Emil's reply, and changed to > subject, > > because this is a whole different can of worms! > > > > I think we must acknowledge that this *can* happen, though it is a > low > > probability event. It raises all sorts of ugly issues. A few: > > Is this actually complicated? That is, worse than is already the case > in SIP... > > My understanding is that in SIP (and this must be a SIP situation), > each fork proceeds with completely independent state from all other > forks. The forks happen to share sending/receiving ports, but the > received packets can be demultiplexed to the correct fork based on > their sending addresses. Of course, there are a range of obnoxious > situations where you receive packets before you receive a SIP response > (SDP answer) that describes them, but that is true in non-bundled SIP > as well. > > Dale > _______________________________________________ > 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 Sun May 26 15:07:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B9821F92F5 for ; Sun, 26 May 2013 15:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv7wiqpqvTkt for ; Sun, 26 May 2013 15:07:08 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E82D221F92EB for ; Sun, 26 May 2013 15:07:07 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-72-51a2878a96cd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EB.A6.28930.A8782A15; Mon, 27 May 2013 00:07:06 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Mon, 27 May 2013 00:07:04 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CDE252885; Mon, 27 May 2013 01:07:03 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4B2A15430F; Mon, 27 May 2013 01:07:02 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ECCE153313; Mon, 27 May 2013 01:07:01 +0300 (EEST) Message-ID: <51A28787.3090709@ericsson.com> Date: Mon, 27 May 2013 01:07:03 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: draft-ietf-mmusic-rtsp-nat@tools.ietf.org References: <519638D5.9030301@cisco.com> In-Reply-To: <519638D5.9030301@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvrW5X+6JAgymr9S3a3xxhspi6/DGL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXxY2IHa8F91or1q5awNjDuZOli5OSQEDCR aD34nhnCFpO4cG89WxcjF4eQwClGiZdzmxkhnA2MEof3nWCFcHYzSky73wZVto5R4nXPbBYI ZwWjRO/0S4wgw3gFtCUapm9hBbFZBFQlPl7ZB7aETcBe4uaE6+wgtqhAssSB/nZWiHpBiZMz n4AdJSKgKzGrsZUNxGYWkJGYcbaRqYuRg0NYwFli05ockLCQgIbEgfeP2EDCnAKaErf/RkNU 20pcmHOdBcKWl9j+dg7Ua2oSV89tYoZoVZW4+u8V4wRG0VlIFs9C0j4LSfsCRuZVjOy5iZk5 6eWGmxiBYX9wy2/dHYynzokcYpTmYFES5+3VnhooJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gdEq7bf7xC2z2V6Xdn9r1Hn+euLr4/s3e4UJH/x8xNSoJct7hYa+du1/45u+XNu6DsUaT0iX m7rmsEF+RePsM4UO83k6vs6JqdvE8JAhcfazG1+ZVogyTlQK6Ftwm/lT0ImJq4Var74y9JCu mbSwa+Wab/82MZtNaAlpuXygfBbDSfFv7hP19zspsRRnJBpqMRcVJwIA5HXUdEkCAAA= Cc: mmusic Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 22:07:19 -0000 Hi, Here's a few editorial things worth considering fixing. 3. Solution Overview 9. When the client has concluded its connectivity checks, including promoting candidates, and has correspondingly received the s/promoting candidates/nominating candidate pairs/ (using "promoting/promoted" also later in the document) 4.2. ICE Candidate Transport Header Parameter : [...] It MUST start at 1 and MUST increment by 1 for each component of a particular candidate s/of a particular candidate/of a particular media stream/ In section 6.4 you talk about "SO" connection types; makes sense to expand that into "Simultaneous Open". Cheers, Ari (as individual) From ari.keranen@ericsson.com Sun May 26 15:42:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3426921F8F11 for ; Sun, 26 May 2013 15:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.48 X-Spam-Level: X-Spam-Status: No, score=-5.48 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DEq8Xm36HQJ for ; Sun, 26 May 2013 15:42:24 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4733E21F92B7 for ; Sun, 26 May 2013 15:42:24 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-5d-51a28fce6c95 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6B.81.06701.ECF82A15; Mon, 27 May 2013 00:42:22 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 27 May 2013 00:42:22 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E9D682885; Mon, 27 May 2013 01:42:21 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 646D55430F; Mon, 27 May 2013 01:42:20 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E760D53313; Mon, 27 May 2013 01:42:19 +0300 (EEST) Message-ID: <51A28FCC.9010401@ericsson.com> Date: Mon, 27 May 2013 01:42:20 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: draft-ietf-mmusic-sdp-g723-g729@tools.ietf.org References: <20130520161935.17435.91264.idtracker@ietfa.amsl.com> In-Reply-To: <20130520161935.17435.91264.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvre65/kWBBu8fylr0nljAaDF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj46I/jAXbWSr+bDzJ1sC4lLmLkZNDQsBE ovVVK5QtJnHh3nq2LkYuDiGBU4wS8+5eYYRwNjBKLNh5lBXC2c0oMWNhJwtIi5DAOkaJj22K EPYKRokTj41AbF4BbYnpB/rAalgEVCWubrjPDmKzCdhL3JxwHcwWFUiWONDfzgpRLyhxcuYT sHoRASOJzrX/2EBsZgEZiRlnG5lAbGEBD4kzk54wQexylHjaMhXsbE4BJ4nJ+w+wQ9TbSlyY c50FwpaX2P52DtRrahJXz21ihugFuuffK8YJjKKzkKyehaR9FpL2BYzMqxjZcxMzc9LLzTcx AsP+4JbfBjsYN90XO8QozcGiJM7bpz01UEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj6ZQ5 NfFfEo0/n15/YPvtjQmHnvf2szWWbxfSXd5XcmfKK9GljityFwpN0l206BVrAOvXaPV1uxbv e+h5hLvA+ICs7fvbckxT3ESPz/xoFKrjnJYU0v2n684kjl1ZM2XtwwuNnm/7kcPaellGX0Pq +bxJj/IMp1ZK3GpznuxQq2rf6tTvtvaqEktxRqKhFnNRcSIARMGfK0kCAAA= Cc: mmusic Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 22:42:31 -0000 Hi, There seems to be one (recurring) typo in the examples: 4.1. Offer with G279 annexb=yes and answer with G279 annexb=no [Offer with G279 annexb=yes] s/G279/G729/g (same in the sections 4.2 & 4.3) Also, the following sentence in section 3 seems a bit hard to parse: Based on the above, it is best to not use comfort noise frames if the SDP offer or answer indicates no support for it. Maybe rather say "[...] offer or answer indicates that comfort noise is not supported", if that's what you mean. Cheers, Ari From christer.holmberg@ericsson.com Mon May 27 01:14:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC68421F90F1 for ; Mon, 27 May 2013 01:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWs0owP3IU4i for ; Mon, 27 May 2013 01:14:03 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBCB21F90EF for ; Mon, 27 May 2013 01:14:02 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-60-51a315c956d8 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B0.74.31782.9C513A15; Mon, 27 May 2013 10:14:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Mon, 27 May 2013 10:14:00 +0200 From: Christer Holmberg To: Parthasarathi R , "'Dale R. Worley'" , 'Paul Kyzivat' Thread-Topic: [MMUSIC] When a bundle offer is forked Thread-Index: AQHOV9u/fklHpYO4tka0o0wHa47jypkTW/u2gACjmhCAA1ChYIABY7Gg Date: Mon, 27 May 2013 08:14:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37943B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> <201305232206.r4NM6l5C5338062@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C377609@ESESSMB209.ericsson.se> <004d01ce5a08$a3193720$e94ba560$@co.in> In-Reply-To: <004d01ce5a08$a3193720$e94ba560$@co.in> 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+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvre5J0cWBBo0TBCymLn/MYjH5Ux+r xYoNB1gtXp4oc2Dx+Pv+A5PH5P1fmT2WLPnJ5PFh/hf2AJYoLpuU1JzMstQifbsErow7e+QL euQr7ndMZGtg/CfRxcjBISFgItHXIdzFyAlkiklcuLeerYuRi0NI4DCjxKG9C9lAEkICSxgl 3rRJgtSzCVhIdP/TBgmLCDQzSrSuswIJMwuoS1xdHAQSFhYwlvi3aB4LRImJxJ/2XiYI203i /eYWZhCbRUBVou/AVlYQm1fAV+LWt3nMEGtXskusuL8GbC0nUPPZpjlggxiBbvt+ag3YIGYB cYlbT+YzQdwsILFkz3lmCFtU4uXjf6wQbylKLO+XgyjXkViw+xMbhK0tsWzha2aIvYISJ2c+ YZnAKDYLydRZSFpmIWmZhaRlASPLKkb23MTMnPRyo02MwAg6uOW36g7GO+dEDjFKc7AoifPq 8S4OFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCYu5X9q6K3cvGTnyteRn7dMT397csca039 GCaLlb1H3kxWqJf8pz65WefwRrUf357f7O2yr3B7NP/tyePZMfvVYzl+vWwLmhBqLbTtuI/8 3pTNhut2izEcOxB+yizk3Grp/W9nLd6lUO7vOuPU4VqN/rp/r9mU5iYmvy0+F5KVt/eD08u9 55U0lFiKMxINtZiLihMBchipI24CAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 08:14:09 -0000 Hi, >Forking has to be seen with the RTP role (endpoint, translator, mixer) as = the offer/answer exchange varies drastically for each RTP role. SIP=20 >forking with RTP endpoint issues are explained as part of Sec 3.1 of RFC 3= 960. One of the complexity introduced as part of BUNDLE is to have=20 >two offer/answer before consolidating. The offer/answer interaction betwee= n SIP forking with RTP endpoint and BUNDLE has to be mentioned. I'll explai= n with the SIP serial forking with RTP endpoint scenario for more clarity > >1) INVITE with SDP having BUNDLE offer and different port in each m-line i= s send out from UAC >2) 183 with SDP and BUNDLE support is received from UAS1 >3) UPDATE with SDP having BUNDLE offer and single port in each m-line is s= end towards UAS1 after completing PRACK & 200 >4) 183 with SDP and BUNDLE support is received from UAS2 > >Here at Step 4, it is not possible for UAC to "mute" UAS1 as one another O= FFER is initiated already at Step 3 and BUNDLE forces to "mute" the answer= =20 >UAS2. This limitation has to be mentioned as part of BUNDLE. Please let me= know your opinion on this. I don't understand. The UAC can: 1) wait for the UPDATE answer from UAS1, and then send a new "mute" UPDATE;= or 2) send a BYE to UAS1, and terminate the whole early dialog. Also, BUNDLE is not the only SIP/SDP mechanism which uses multiple Offer/An= swer transactions. Regards, Christer > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Christer Holmberg > Sent: Friday, May 24, 2013 1:55 PM > To: Dale R. Worley; Paul Kyzivat > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] When a bundle offer is forked >=20 > Hi, >=20 > I agree with Dale. Each early dialog is handled separately. >=20 > From a standards perspective, I don't think we need to say much about=20 > forking in BUNDLE, other than maybe some general words that it may=20 > happen. >=20 > Then, whether it becomes tricky to implement, e.g. if one early leg=20 > uses BUNDLE and another doesn't, is another issue. But, as SIP has=20 > mechanisms to terminate early dialogs you don't like etc, I see this=20 > as a pure implementation issue. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Dale R. Worley > Sent: 24. toukokuuta 2013 1:07 > To: Paul Kyzivat > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] When a bundle offer is forked >=20 > > From: Paul Kyzivat > > > > On 5/23/13 6:35 AM, Emil Ivov wrote: > > > > > In case a bundle offer gets forked and various answers ... > > > > I trimmed everything else out of Emil's reply, and changed to > subject, > > because this is a whole different can of worms! > > > > I think we must acknowledge that this *can* happen, though it is a > low > > probability event. It raises all sorts of ugly issues. A few: >=20 > Is this actually complicated? That is, worse than is already the case=20 > in SIP... >=20 > My understanding is that in SIP (and this must be a SIP situation),=20 > each fork proceeds with completely independent state from all other=20 > forks. The forks happen to share sending/receiving ports, but the=20 > received packets can be demultiplexed to the correct fork based on=20 > their sending addresses. Of course, there are a range of obnoxious=20 > situations where you receive packets before you receive a SIP response=20 > (SDP answer) that describes them, but that is true in non-bundled SIP=20 > as well. >=20 > Dale > _______________________________________________ > 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 Mon May 27 02:19:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E441A21F9003 for ; Mon, 27 May 2013 02:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1hj3SowfoUA for ; Mon, 27 May 2013 02:19:31 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACF721F8FDC for ; Mon, 27 May 2013 02:19:30 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-77-51a32521d8e8 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 29.67.06701.12523A15; Mon, 27 May 2013 11:19:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Mon, 27 May 2013 11:19:28 +0200 From: Christer Holmberg To: Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE Weekly Summary: Assumptions Thread-Index: Ac5H/Rv/zjNZSPPjTceQWRJyHaV9rQPf2J+AAEsPWIAAhJd7cA== Date: Mon, 27 May 2013 09:19:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3794D1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C36B485@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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvra6i6uJAg5d/tSz2L7nMbDF1+WMW ByaPxz1n2DyWLPnJFMAUxWWTkpqTWZZapG+XwJXR+bmDreAfZ8X648vYGhjvcHYxcnJICJhI LJ6/nhnCFpO4cG89G4gtJHCYUWJVM08XIxeQvYRRYsuyzUBFHBxsAhYS3f+0QWpEBEIk5qzY ywRiCwOFPxxazAJSIiJgKbH6vhdEiZNEw+95bCBhFgFViQcb7UDCvAK+Ei1X37FAbDrOKLH2 qgeIzSlgK9FypAnsAkaga76fWgM2nVlAXOLWk/lMEFcKSCzZcx7qYlGJl4//sYKMlxBQlFje LwdiMgtoSqzfpQ/RqSgxpfshO8RWQYmTM5+wTGAUnYVk6CyEjllIOmYh6VjAyLKKkT03MTMn vdx8EyMw/A9u+W2wg3HTfbFDjNIcLErivPq8iwOFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MHI2uV65ofDkS/DGY/aFE5KPX83ZGjnr3eKiqUkzOwqEG1e9Tz9jdHN6Te8Ojmn+J/oms8xc 23Pid5jj39gnDK6eZkYdemYepn396i78c+Qy9BZ+LXz13uHYd3XO6Hu7k5ilQ+Z7PeEUeOWi ojJVf84TPpPli5LEzxhP6v928WTyzfZpXt8nbFFiKc5INNRiLipOBAAwjZvATQIAAA== Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 09:19:38 -0000 SGksDQoNCj5JbiBvcmRlciB0byB0cnkgdG8gY2xvc2UgaXNzdWVzIG9uIEJVTkRMRSwgYmFzZWQg b24gdGhlIGRpc2N1c3Npb25zIHdl4oCZdmUgaGFkLCBJIGludGVuZCB0byB1cGRhdGUgdGhlIEJV TkRMRSBkcmFmdCBiYXNlZCBvbiB0aGUgZm9sbG93aW5nIGFzc3VtcHRpb25zOg0KPg0KPjEuwqDC oMKgwqDCoMKgIFdlIG1hbmRhdGUgdXNhZ2Ugb2YgcnRjcC1tdXggd2hlbiBCVU5ETEUgaXMgdXNl ZC4NCj4NCj5bQkFdIEFncmVlZC4NCj4NCj4yLsKgwqDCoMKgwqDCoCBTRFAgbS0gbGluZXMgd2l0 aCBhIHplcm8gcG9ydCB2YWx1ZSBNVVNUIE5PVCBiZSBwdXQgaW5zaWRlIGEgQlVORExFIGdyb3Vw IChub3QgaW4gYW4gb2ZmZXIsIG5vciBpbiBhbiBhbnN3ZXIpLiBUaGVyZSB3aWxsIGJlIGEgbm90 ZSBpbmRpY2F0aW5nIHRoYXQsIA0KPmR1ZSB0byB0aGlzLCB0aGUgbnVtYmVyIG9mIG0tIGxpbmVz IGFzc29jaWF0ZWQgd2l0aCBhIEJVTkRMRSBncm91cCBtYXkgZGlmZmVyIGJldHdlZW4gdGhlIG9m ZmVyIGFuZCB0aGUgYXNzb2NpYXRlZCBhbnN3ZXIuIFRoZXJlIHdpbGwgYWxzbyBiZSBhIG5vdGUg DQo+aW5kaWNhdGluZyB0aGF0IHRoaXMgaXMgZHVlIHRvIFJGQyA1ODg4LCBpbiBjYXNlIHBlb3Bs ZSBsYXRlciBzdGFydCB0byB3b25kZXIgd2hlcmUgdGhlIOKAnE1VU1QgTk9U4oCdIGNvbWVzIGZy b20uDQo+DQo+W0JBXSBEaXNhZ3JlZS7CoA0KDQpJbiBjYXNlIHlvdSBnaXZlIHRoZSBpbmZvcm1h dGlvbiBpbiBhbm90aGVyIGUtbWFpbCwgeW91IGRvbid0IGhhdmUgdG8gcmVwbHkgdG8gdGhpcyBl LW1haWwsIGJ1dCBvdGhlcndpc2U6IGRvIHlvdSBkaXNhZ3JlZSB0byBmb3JiaWRkaW5nIHBvcnQg emVybyBpbiBidW5kbGUgb2ZmZXJzLCBidW5kbGUgYW5zd2Vycywgb3IgYm90aD8gOikNCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg== From internet-drafts@ietf.org Mon May 27 02:25:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E23B21F8A68; Mon, 27 May 2013 02:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYsLMwF33XQx; Mon, 27 May 2013 02:25:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA44221F90AC; Mon, 27 May 2013 02:25:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130527092547.25610.18890.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2013 02:25:47 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 09:25:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : The Evaluation of Different Network Address Translator (= NAT) Traversal Techniques for Media Controlled by Real-time Streaming Proto= col (RTSP) Author(s) : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-08.txt Pages : 40 Date : 2013-05-27 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 on 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 relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0. 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-evaluation-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Mon May 27 02:27:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F9821F9347 for ; Mon, 27 May 2013 02:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.91 X-Spam-Level: X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[AWL=-1.338, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+FksVF4kCIO for ; Mon, 27 May 2013 02:27:26 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 01C8921F913E for ; Mon, 27 May 2013 02:27:25 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-05-51a326fc5c7b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A6.03.31782.CF623A15; Mon, 27 May 2013 11:27:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Mon, 27 May 2013 11:27:24 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Thread-Index: Ac5Yevnd5lghFfM/QmuiU1fEkjXC+QAAh7mAAI+mEfA= Date: Mon, 27 May 2013 09:27:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3794F5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> <519F7DEB.2010809@alum.mit.edu> In-Reply-To: <519F7DEB.2010809@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvre5ftcWBBndWclpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGlz0mBdOEKn4c8WxgPMbXxcjJISFgIvFn SQMjhC0mceHeerYuRi4OIYHDjBJnrj5gB0kICSxhlOj6ldHFyMHBJmAh0f1PGyQsIuAr8ezx bTYQW1jASmL6kmmsEHFriRvT2xlBykWA4u++2oCEWQRUJbruzgIr5wVq3b3uDRvE9HyJdbs/ sYGUcwroSHydBDaFEeia76fWMIHYzALiEreezGeCuFJAYsme88wQtqjEy8f/WEFaJQQUJZb3 y0GU60gsAJsIYmtLLFv4mhliq6DEyZlPWCYwis5CMnUWkpZZSFpmIWlZwMiyipE9NzEzJ73c aBMjMPwPbvmtuoPxzjmRQ4zSHCxK4rx6vIsDhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTA2 8H2dtnR9249fZtKuDU7L5DO3bb959nD6ixndT/butTaTe9K6VWaP9RQT2f1bvl6bm6BdGLBe w/PkxSk7Qm25sy+sf3b766NinXUJFwXvJd5qZEry4E1ds2DZ87PiOjU8CSv/vzgVGMZ5hvlq eoyExiTeeYat+2dWhBx3a7nA6rCFoc7y7/4wJZbijERDLeai4kQAfkUSFU0CAAA= Subject: Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 09:27:36 -0000 Hi, >> At the interim yesterday, we agreed to use the SDP BUNDLE group=20 >> attribute to indicate on which port bundled media will be sent. In an=20 >> SDP offer, the order of the attribute mid values can be used by the=20 >> offerer to indicate a "wish", but the first attribute mid value in the=20 >> answer indicates where the answerer will eventually send bundled media. > >This could be interpreted to mean the first a=3Dmid value in the SDP. >I'm sure you mean "the first mid value in the a=3Dgroup:bundle" line. Yes. >Or perhaps "the first mid value in the bundle group" - assuming there is a= definition that "bundle group" means an a=3Dgroup:bundle line. In the draft "bundle group" means (or, at least is supposed to mean :) the = bundle grouped m- lines, and in general I think it is better to explicitly = mention the line/attribute. > This can be "future proofed" by saying that the first mid value in the bu= ndle group in the answer that references an m-line with non-zero=20 > port value. I realize this adds nothing unless 5888 is revised to permit = m-lines with zero port in a bundle group. But at least it will be ready for= that, and harms nothing. I agree, but suggest a little different wording: by saying the first mid va= lue in the group attribute MUST NOT represent a port zero m- line. Regards, Christer > The main usage of this is the "initial offer", when each m- line=20 > within a bundle group has a different port value. > > So far so good. > > The reason I say "almost decision" is because we have started a new=20 > discussion regarding updated offers, adding new m- lines etc. We need=20 > to make sure that the order-to-mid-values semantics also apply to=20 > those, and what restrictions there are when adding m- lines. > > But, for now, if you OBJECT to the general principle of using the SDP=20 > group attribute mid value order for indicating the port where media=20 > will be sent, please indicate so. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Mon May 27 02:30:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E81321F90AC for ; Mon, 27 May 2013 02:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bib5Wwg+5NWq for ; Mon, 27 May 2013 02:29:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5D94E21F8FB3 for ; Mon, 27 May 2013 02:29:53 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-3b-51a327909ec4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0E.59.06701.09723A15; Mon, 27 May 2013 11:29:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 27 May 2013 11:29:52 +0200 Message-ID: <51A3278D.8060402@ericsson.com> Date: Mon, 27 May 2013 11:29:49 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= References: <518BB81A.8090608@cisco.com> <51965190.10900@ericsson.com> <519E2BF8.7040500@ericsson.com> <519E58D1.6080600@ericsson.com> In-Reply-To: <519E58D1.6080600@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Vnei+uJAg1VnOC3u9r5gspi6/DGL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxfuYd9oKDQhXzP/QwNTC+4uti5OSQEDCR OHzlMyuELSZx4d56NhBbSOAUo8TKawIQ9nJGiSfXtEFsXgFtiY1XJzN3MXJwsAioSlzabgIS ZhOwkLj5oxGsVVQgWOLI9s0sEOWCEidnPgGzRQRsJeZcXcsOYjMLhEr8ubgGrF5YwE+i79BO pi5GLqBVbYwSt/bvYwJJcAroSByac5UF4jZJiS0v2qGa9SSmXG1hhLDlJZq3zmaGuFNboqGp g3UCo9AsJLtnIWmZhaRlASPzKkb23MTMnPRy802MwEA9uOW3wQ7GTffFDjFKc7AoifPq8y4O FBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBomHDWyp1vXY3UaVZLf/9nG/8sZC1/rh71e+7z /ZoX+qSXLzHnVhTntlLZ/Tsya8lizu67BwvdtXKzk+N81pSLpJxZG7/1KuNflTVifElPL387 tdmq6nDL8fPhayrXdjGuZ3KxvrwregHvxaW2RxfsCL6+cWnOT2sO5exv0565n7HcPqn2h5yV EktxRqKhFnNRcSIA90geJCICAAA= Cc: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 09:30:00 -0000 Hi, Sorry for missing the other changes. I think I gotten all the lock down changed now. This has resulted in some significant changes in the text for TURN relays, including a server implementation requirement. I recommend that people do take a look at the diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-08 Cheers Magnus On 2013-05-23 19:58, Ari Keränen wrote: > On 5/23/13 5:47 PM, Magnus Westerlund wrote: >> On 2013-05-17 17:49, Ari Keränen wrote: >> >>> >>> >>> 4.9.1. [TURN] Introduction >>> >>> On the external side this is >>> limited to the source address/port pair of the first packet arriving >>> on the binding. After the first packet has arrived the mapping is >>> "locked down" to that address. Packets from any other source on >>> this >>> address will be discarded. >>> >>> This doesn't sound right. This behavior was changed (eventually into >>> using permissions) somewhere back in draft-rosenberg-midcom-turn-06. See >>> http://tools.ietf.org/html/rfc5766#section-2.3 for up-to-date behavior. >>> Check also steps 5 & 7 in the next section and section 4.9.4 for more >>> lock down text. >> >> I changed this to: >> >> To prevent DoS attacks on either recipient, the packets forwarded are >> restricted to the specific source address. On the client side it is >> restricted to the source setting up the allocation. On the external side >> this is limited to the source address/port pair that have been given >> permission by the TURN client creating the allocation. Packets from any >> other source on this address will be discarded. >> >> I will shortly submit an updated draft. > > Looks good to me. However, also the following sections had some "lock > down" text that should be updated (see details on my original mail above). > > > Cheers, > Ari > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Mon May 27 02:58:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B155121F90FD; Mon, 27 May 2013 02:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5KMHcFHt9NW; Mon, 27 May 2013 02:58:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F9421F901A; Mon, 27 May 2013 02:58:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130527095808.15080.93977.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2013 02:58:08 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-16.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 09:58:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : A Network Address Translator (NAT) Traversal mechanism f= or media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : Jeff Goldberg Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-16.txt Pages : 32 Date : 2013-05-27 Abstract: This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Mon May 27 02:59:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B215021F92EB for ; Mon, 27 May 2013 02:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYKlfCWcgFJH for ; Mon, 27 May 2013 02:59:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1703921F90FD for ; Mon, 27 May 2013 02:59:38 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-df-51a32e89fcb1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0D.62.28930.98E23A15; Mon, 27 May 2013 11:59:37 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 27 May 2013 11:59:37 +0200 Message-ID: <51A32E8B.7030909@ericsson.com> Date: Mon, 27 May 2013 11:59:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= References: <519638D5.9030301@cisco.com> <51A28787.3090709@ericsson.com> In-Reply-To: <51A28787.3090709@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3VrdTb3Ggwe/P/Bbtb44wWUxd/pjF gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mo4uu0bU8EW7oqby2azNzD+4ehi5OCQEDCR WPWtvIuRE8gUk7hwbz1bFyMXh5DAKUaJJx/Ps0M4yxkldv+7yQpSxSugLbHqTAM7SDOLgKrE nj3aIGE2AQuJmz8a2UBsUYFgiSPbN7NAlAtKnJz5BMwWEbCVmHN1LTuIzSzgLnH00HdmkDHC As4Sm9bkgISFBDwkHh66BjaGU0BH4tHeG6wQt0lKbHnRDtWqJzHlagsjhC0v0bx1NjNEr7ZE Q1MH6wRGoVlINs9C0jILScsCRuZVjOy5iZk56eWGmxiBYXpwy2/dHYynzokcYpTmYFES59Xj XRwoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZEtmeMS836ma1HW2o2NJg3rfm7ndPQRLmea XHJqQeuHllu10p/C3+1UusnvHTKVoyd+lbC1pELKueLPems5D56TSV3+w7TUZEf56YPxZ9rP 3Fi3/ap79MzzR79m7ZwR+eLoeY3s0owl3b15d+IjrshNZFnd25168eBuB9W4OZmzE7SdT96Y +0SJpTgj0VCLuag4EQA5MCpdIQIAAA== Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 09:59:44 -0000 Hi Ari, Thanks for these fixes. I have implemented them: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-16 Cheers Magnus On 2013-05-27 00:07, Ari Keränen wrote: > Hi, > > Here's a few editorial things worth considering fixing. > > > 3. Solution Overview > > 9. When the client has concluded its connectivity checks, including > promoting candidates, and has correspondingly received the > > s/promoting candidates/nominating candidate pairs/ > (using "promoting/promoted" also later in the document) > > > 4.2. ICE Candidate Transport Header Parameter > > : [...] > It MUST start at 1 and MUST increment by 1 for each component > of a particular candidate > > s/of a particular candidate/of a particular media stream/ > > > In section 6.4 you talk about "SO" connection types; makes sense to > expand that into "Simultaneous Open". > > > Cheers, > Ari (as individual) > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From christer.holmberg@ericsson.com Mon May 27 03:01:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCC821F90FD for ; Mon, 27 May 2013 03:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.503 X-Spam-Level: X-Spam-Status: No, score=-5.503 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8GX80lyBaCj for ; Mon, 27 May 2013 03:01:08 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E1E3F21F8A14 for ; Mon, 27 May 2013 03:01:04 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-78-51a32edf0f63 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9C.5F.06701.FDE23A15; Mon, 27 May 2013 12:01:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Mon, 27 May 2013 12:01:03 +0200 From: Christer Holmberg To: Bernard Aboba , Paul Kyzivat Thread-Topic: [MMUSIC] Associating packets with m-lines in a bundle Thread-Index: AQHOV+Zp6PDmzKY1kEezzTQcDF/35ZkUmi8AgAQ21sA= Date: Mon, 27 May 2013 10:01:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C379542@ESESSMB209.ericsson.se> References: <519E5F54.3000806@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre4DvcWBBuv/M1nsX3KZ2WLq8scs Fis2HGB1YPb4+/4Dk8fjnjNsHkuW/GQKYI7isklJzcksSy3St0vgylhwaidTwV/hio2futkb GJ/zdzFyckgImEis3XSXFcIWk7hwbz1bFyMXh5DAYUaJfy/PMUM4SxglXizrZOli5OBgE7CQ 6P6nDdIgIhAqcXTXBLBmZgEViVenL4PZwgJOEhP617FA1DhLXJz4mhXCtpLYtfIp2BgWAVWJ fRtsQcK8Ar4Sly4sYQQJCwnESSw5pQkS5hSwlTjYsIYRxGYEOu37qTVMEJvEJW49mc8EcbKA xJI955khbFGJl4//sYKMkRBQlFjeLwdRriOxYPcnNghbW2LZwtfMEFsFJU7OfMIygVFsFpKp s5C0zELSMgtJywJGllWM7LmJmTnp5eabGIERc3DLb4MdjJvuix1ilOZgURLn1eddHCgkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qB0SFusdMro9frr0W/PpIulJ13vePMM4/1wZfn1u/MeJ04 J2nbjActV81OdDjkylSf4wzqcZ85dWLEb4YZOkG83yca7J323XX5KoFfXCXHwjL/M3/1c+A3 +ZJ1JdnLN/H5LZ+/C1oFNoW8CuKdm9snz5TgKl7vXhV9e/Wbwp9LU90i56T0nzVpVGIpzkg0 1GIuKk4EAN65ENJmAgAA Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 10:01:13 -0000 Hi, I am skeptical towards specifying a default m- line as well, as the media t= ype may not even match :) Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: 24. toukokuuta 2013 22:35 To: Paul Kyzivat Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle On May 23, 2013, at 11:50, "Paul Kyzivat" wrote: > After all the discussion in the meeting today, I thought it would be good= to unwind all the indenting and start a new thread on one issue that is pa= rt of the "demux" problem: >=20 > IMO the following should obviously be a truism. I want to know if all agr= ee. >=20 > If an O/A exchange negotiates a bundle with multiple m-lines, then=20 > attributes in those m-lines and the associated media sections must provid= e sufficient information to associate each incoming packet on the 5-tuple t= o exactly *one* of those m-lines. [BA] I would argue that this statement needs to be true for *both* RTP and = RTCP packets. > (If it doesn't, then there was no point in including those m-lines in=20 > the bundle.) >=20 > For instance a=3Dssrc, if unique to one m-line, can bind packets with tha= t SSRC to the m-line. [BA] That is only necessary for RTP (and RTCP) if the PT is not unique to a= n m line; otherwise PT demux is sufficient for RTP. For RTCP the situation= is more complicated. If we only need to bind RTCP packets from RTP senders= , we can build an SSRC to PT to m line table dynamically, based on SSRCs an= d PTs seen in RTP packets. However if we get a RR from a source that has n= ot yet sent, we can't map it to an m line without a=3Dssrc if BUNDLE is in = use. =20 > If a property such as SSRC is used this way, then there is the possibilit= y of receiving packets that don't match any of the m-lines. I think we ough= t to address that, by defining some syntax to specify what to do with packe= ts that don't match any m-line. This might be to specify one m-line as the = default, or that packets that don't match be discarded. [BA] I do not believe that a default m line makes sense for RTCP packets th= at can't be bound to an m line. Discard, while undesirable, seems like the= only option. However this could create problems in diagnostics in some cas= es. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon May 27 03:05:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED40D21F9397 for ; Mon, 27 May 2013 03:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.539 X-Spam-Level: X-Spam-Status: No, score=-5.539 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4MdOLMTNJPM for ; Mon, 27 May 2013 03:04:57 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 11E9621F9347 for ; Mon, 27 May 2013 03:04:51 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-be-51a32fc235f0 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1C.10.06701.2CF23A15; Mon, 27 May 2013 12:04:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Mon, 27 May 2013 12:04:50 +0200 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between Thread-Index: Ac5YZ89eNSNKdC6FQhCoA7qw0p8XLAAUyP6AAIGn7AA= Date: Mon, 27 May 2013 10:04:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3795A5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3777C9@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3795A5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvre5h/cWBBo/7uCymLn/MYrFzbgez A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxdM5H9oLO6Iotu16yNTBeCuhi5OSQEDCR 2LTiBjOELSZx4d56ti5GLg4hgcOMEue+LGICSQgJLGGUmLY0rouRg4NNwEKi+582SFhEQEti 9eK5TCBhZgF1iauLg0BMYYFkiS0f8iEqUiSOL77FCmFbSTx/0cIIUsIioCrRtswLJMwr4Csx 6dJaZog9UxglDk7mArE5BQIlurddZQexGYEO+35qDdgtzALiEreezGeCOFhAYsme81DHi0q8 fPyPFWS8hICixPJ+OYjyfImpbdvZIVYJSpyc+YRlAqPoLCSTZiEpm4WkDCKuI7Fg9yc2CFtb YtnC18ww9pkDj5mQxRcwsq9iZM9NzMxJLzffxAiMpINbfhvsYNx0X+wQozQHi5I4rz7v4kAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKcfq4rsLxU+asq1uvcIc0rZwfirUd0hrhZijr5l TY+qHXLTuW35+vtbjVjP/mrbO22Ki+hsQUXL0/stHVfnnSkQ23eZ2bjJyJz33YNjwUd8/G5s uj5bhW3LLk7RRWZvZzXUcW86uvX9fs11lU+PP+eqvlVrubZz4cwb61njw5K5IxRK3ASeKLEU ZyQaajEXFScCAHbWR7NyAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 10:05:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3795A5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The text suggested by Paul is good. Regards, Christer From: Suhas Nandakumar [mailto:suhasietf@gmail.com] Sent: 25. toukokuuta 2013 1:12 To: Christer Holmberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there ai= nt anything in between Hey Christer This looks good ( including Paul's clarification and Martin's statement = about Expectation of the following fixup to make intermediaries happy). Also few comments inline. On Fri, May 24, 2013 at 3:28 AM, Christer Holmberg > wrote: Hi, At the interim yesterday, we agreed that an answerer MUST always include id= entical ports* (usage of port zero within a bundle is a separate topic) for= all m- lines within an bundle group. If the answerer wants to use different ports* for some/all m- lines, it MUS= T NOT include those m- lines in a bundle group (if they already are in a bu= ndle group, a separate offer is needed to remove them). [Suhas] If the answerer wants to use different ports for "ALL" the m-lines = then it is implicitly assumed that there was a Successful O/A exchange + Fi= xup and this Offer is a subsequent one. On the other hand, changing some ports in the Answer can even happen in the= first ever BUNDLE O/A as well. Just wanted to clarify with the wordings. WHAT IT MEANS: There is no way for an answerer to tell that the offerer, fo= r certain m- lines, can use the same port*, eventhough the answer will use = separate ports*. I will work on some actual text proposal later, but please indicate if you = OBJECT to this approach in general. Regards, Christer NOTE: "port" =3D port:address combination - we are working on coming up wit= h better terminology :) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C3795A5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

The text suggested by Pau= l is good.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Suhas Na= ndakumar [mailto:suhasietf@gmail.com]
Sent: 25. toukokuuta 2013 1:12
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - t= here aint anything in between

 

Hey Christer

 

   This looks good ( including Paul's= clarification and Martin's statement about Expectation of the following fi= xup to make intermediaries happy).

 

Also few comments inl= ine.

On Fri, May 24, 2013 at 3:28 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

At the interim yesterday, we agreed that an answerer MUST always i= nclude identical ports* (usage of port zero within a bundle is a separate t= opic) for all m- lines within an bundle group.

  

If the answerer wants to use different ports* for some/all m- line= s, it MUST NOT include those m- lines in a bundle group (if they already ar= e in a bundle group, a separate offer is needed to remove them).

 

[Suhas] If the answerer wants to use different ports= for "ALL" the m-lines then it is implicitly assumed that there w= as a Successful O/A exchange + Fixup and this Offer is a subsequent one= . 

On the other hand, changing some ports in the Answer= can even happen in the first ever BUNDLE O/A as well.

Just wanted to clarify with the wordings.=

 

 

WHAT IT MEANS: There is no way for an answerer to tell that the of= ferer, for certain m- lines, can use the same port*, eventhough the answer = will use separate ports*.

 

I will work on some actual text proposal later, but please indicat= e if you OBJECT to this approach in general.

 

Regards,

 

Christer

 

NOTE: “port” =3D port:address combination – we a= re working on coming up with better terminology J

 

 

 

 

 

 


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

 

--_000_7594FB04B1934943A5C02806D1A2204B1C3795A5ESESSMB209erics_-- From internet-drafts@ietf.org Mon May 27 03:15:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEC021F9195; Mon, 27 May 2013 03:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JupKxnOi2bVl; Mon, 27 May 2013 03:15:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CB321F9017; Mon, 27 May 2013 03:15:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130527101542.13061.30674.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2013 03:15:42 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-delayed-duplication-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 10:15:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Delayed Duplication Attribute in the Session Description= Protocol Author(s) : Ali Begen Yiqun Cai Heidi Ou Filename : draft-ietf-mmusic-delayed-duplication-02.txt Pages : 9 Date : 2013-05-27 Abstract: A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to simply duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as Time-shifted Redundancy, Temporal Redundancy or simply Delayed Duplication. This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-delayed-duplication-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-delayed-duplication-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon May 27 03:15:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B1921F8A0B; Mon, 27 May 2013 03:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT0Z0vO5trBH; Mon, 27 May 2013 03:15:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1775021F9017; Mon, 27 May 2013 03:15:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130527101546.15111.63717.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2013 03:15:46 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-duplication-grouping-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 10:15:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Duplication Grouping Semantics in the Session Descriptio= n Protocol Author(s) : Ali Begen Yiqun Cai Heidi Ou Filename : draft-ietf-mmusic-duplication-grouping-02.txt Pages : 9 Date : 2013-05-27 Abstract: Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework [RFC5888]. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for RTP streams using SSRC multiplexing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-duplication-grouping-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-duplication-grouping-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Mon May 27 03:53:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53421F8EA5 for ; Mon, 27 May 2013 03:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFkv6Fv4-x3P for ; Mon, 27 May 2013 03:53:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CFD9D21F8D70 for ; Mon, 27 May 2013 03:53:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-a1-51a33b38df3b Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 18.BB.28930.83B33A15; Mon, 27 May 2013 12:53:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Mon, 27 May 2013 12:53:44 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions Thread-Index: Ac5YdJNWNYfYqobOTueV815jNgS21wAB15gAAJLnc9A= Date: Mon, 27 May 2013 10:53:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3797E8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> <519F7BFC.2040008@alum.mit.edu> In-Reply-To: <519F7BFC.2040008@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvra6F9eJAgytdmhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx+mA7c8ECgYqvm54xNjB+4eli5OSQEDCR ePxqBQuELSZx4d56ti5GLg4hgcOMEsd2v2cDSQgJLGGUuP5ZsouRg4NNwEKi+582SFhEwFfi 2ePbYCXCAvYSN//1M0PEHSSmHV/MDlIuImAlcXy/PEiYRUBV4tGsI2CreIFaVxx4wAgxPV/i 3NI/YHFOAR2Jcwv7weKMQOd8P7WGCcRmFhCXuPVkPhPEmQISS/acZ4awRSVePv7HCrJKQkBR Ynm/HES5jsSC3Z/YIGxtiWULXzNDrBWUODnzCcsERtFZSKbOQtIyC0nLLCQtCxhZVjGy5yZm 5qSXG25iBEbBwS2/dXcwnjoncohRmoNFSZxXj3dxoJBAemJJanZqakFqUXxRaU5q8SFGJg5O qQbGCeyJrxvWXJWsPOvgGzLlT+8m67pjexIe+pW+v2Zyqb9D+FZKsfCkY/qqr2W1N78zaMtc LbG4eaPcZ/ZJH4orW5fJVb7c6KoiqNss5VRzaPXk/aYJESqNQlIhp575bVNXNtsk5sHnp2b+ qKm/357H0azYLqm/4k+gcaS5v7SmzLkYyeVdXkosxRmJhlrMRcWJAIHHu2lQAgAA Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 10:53:52 -0000 Hi, >> At the interim meeting yesterday, we agreed on some restrictions=20 >> regarding creating SDP answers containing bundle group(s). >> >> Note that the restrictions 1-3 are simply alignments with RFC 5888,=20 >> and are listed simply for clarification purpose. Restrictions 4 is=20 >> BUNDLE specific. Restriction 5 is also alignment with RFC 5888, as m-=20 >> lines with port zero are not allowed within groups, but we will need=20 >> some clarification text saying that a new offer will have to be sent=20 >> in order to remove a stream (either from a bundle group, or completely=20 >> from the session). >> >> (Note that the text below is not necessarily the wording that will go=20 >> into the draft) >> >> In an SDP answer: >> >> 1)a BUNDLE group MUST NOT be created, unless it was included in the=20 >> associated offer >> >> 2)an m- line MUST NOT be added to a BUNDLE group, unless it was=20 >> included in a BUNDLE group in the associated offer >> >> 3)an m- line MUST NOT be added to another BUNDLE group than the group=20 >> in which was included in the associated offer >> >> 4)an m- line MUST NOT be removed from a BUNDLE group if, in the=20 >> associated offer, an identical port number was indicated for all m-=20 >> lines in a BUNDLE group >> >> 5)an m- line MUST NOT be rejected if, in the associated offer, an=20 >> identical port number was indicated for all m- lines in a BUNDLE group > > Where did (5) come from? And what is the justification for it? > I can see no good reason to impose this restriction. I was checking my notes, but could not find anything justifying it. Maybe I= mixed it up with the offer restrictions we were discussing... > Note that there is also a discussion regarding bundle offers, e.g.=20 > when restrictions when adding new m- lines to a bundle. Based on the=20 > outcome of that, there may be some additional answer restrictions, e.g. > regarding the change of bundle transport parameters. But, let's deal=20 > with that in the offer thread. Yes. Regards, Christer From christer.holmberg@ericsson.com Mon May 27 03:57:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1511E21F8C03 for ; Mon, 27 May 2013 03:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhDYMZeDj+u6 for ; Mon, 27 May 2013 03:57:17 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8308721F9017 for ; Mon, 27 May 2013 03:57:12 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-56-51a33c075ff8 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CF.D2.31782.70C33A15; Mon, 27 May 2013 12:57:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Mon, 27 May 2013 12:57:10 +0200 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions Thread-Index: Ac5YdJNWNYfYqobOTueV815jNgS21wAQu3aAAIRBziA= Date: Mon, 27 May 2013 10:57:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C379801@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C377967@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.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrS67zeJAg5kHlSymLn/MYrFzbgez A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxpzmpYCFLxa6mZewNjCuYuxg5OSQETCQu nb7CAmGLSVy4t56ti5GLQ0jgMKPEibbJjBDOEkaJL7+3sHYxcnCwCVhIdP/TBmkQEdCSWL14 LhNImFlAXeLq4iCQsLCAvcTNf/3MECUOEtOOL2YHKRERsJJoeZ8IEmYRUJW4uPIIO4jNK+Ar 8avnOJgtJDCFUWLO9VgQm1MgUGL6xl+sIDYj0GnfT61hArGZBcQlbj2ZzwRxsoDEkj3noV4R lXj5+B/YkRICihLL++UgyvUkbkydwgZha0ssW/iaGWKtoMTJmU9YJjCKzUIydRaSlllIWmYh aVnAyLKKkT03MTMnvdxoEyMwNg5u+a26g/HOOZFDjNIcLErivHq8iwOFBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MPpptOY/3/Zb2fnyE9N4wU8GLv/X7Kyd81xdySHO78C2af+PX3i/613m pCivbo977RKJNhWB6VHr+tfFCwqf2Oz3U9cx/1qOVvN0wyd2KVIqzGeaUq9UzmYUSa0wc/py q+vbLFf7NdXfRbNX1XM/P79Znn3rRNsP931maHcqX184X39WRdtrJyWW4oxEQy3mouJEAEbl vRpbAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 10:57:24 -0000 Hi, >> 4)=A0=A0=A0=A0=A0 an m- line MUST NOT be removed from a BUNDLE group if,= in the associated offer, an identical port number was indicated for all m-= lines in a BUNDLE group > >=A0 [Suhas] =A0.. RFC5888 doesn't clarify what does removing means. Hence,= I would be happy to see 4)=A0 >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If a m-line is removed ( not rejected)= in the Answer, then the m-line should include a unique port that doesn't c= ollide with port associated with any BUNDLE groups. Yes. Regards, Christer From csp@csperkins.org Mon May 27 05:29:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6041021F93EB for ; Mon, 27 May 2013 05:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xs6w0ipk8Bj for ; Mon, 27 May 2013 05:29:44 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 28E2B21F9397 for ; Mon, 27 May 2013 05:29:44 -0700 (PDT) Received: from [81.187.2.149] (port=37947 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UgwYZ-00072H-3M for mmusic@ietf.org; Mon, 27 May 2013 13:29:43 +0100 From: Colin Perkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 27 May 2013 13:29:41 +0100 Message-Id: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> To: "mmusic@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 12:29:50 -0000 There were a number of comments in the call last week, and on the list, = about unique payload types in BUNDLE. I'd like to explore this further. Case A: Within a single RTP session, I think we'd all agree that an = offer that uses the same RTP payload type for two payload formats on a = single m=3D line is problematic:=20 v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN IP4 host.anywhere.com t=3D0 0 m=3Daudio 49170 RTP/AVP 96 a=3Drtpmap:96 AMR-WB/16000 a=3Drtpmap:96 G7291/16000 If this were done the receiver would have no way of distinguishing what = payload format is meant by payload type 96. Accordingly, unique payload = formats need to be used for each payload format. Case B: If one were to use two separate m=3D lines on different ports, = in the non-BUNDLE case, then the same RTP payload type can be reused = without difficulty: v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN IP4 host.anywhere.com t=3D0 0 m=3Daudio 49170 RTP/AVP 96 a=3Drtpmap:96 AMR-WB/16000 m=3Daudio 49172 RTP/AVP 96 a=3Drtpmap:96 G7291/16000 The implication is that there are two separate RTP sessions, which the = receiver can distinguish based on the UDP port on which the packets are = received. The mapping from RTP payload types to payload formats is done = on a per-RTP session basis. Case C: This is when we BUNDLE several m=3D lines on a single UDP port. = On the call last week, there seemed to be agreement that the m=3D lines = in such a BUNDLE group comprise a single RTP session (it also matches = the definition of an RTP session from RFC 3550: the packets go to a = single destination and the m=3D lines share a single SSRC space). To me = this would suggest that the RTP payload type values MUST be unique = across the m=3D lines (or, if the same RTP payload type is used in = different m=3D lines, it MUST map to an identical payload format). The = reason is that everything runs over one UDP port, and if a single RTP = payload type is mapped to different payload formats, there's no way to = distinguish which payload format is meant. This is essentially the same = as case A above. Given this, it's not clear to me that non-unique payload types make = sense within a BUNDLE group. They work on different m=3D lines in the = legacy case because those lines form different RTP sessions, and the RTP = sessions can be used to scope the payload type to payload format = mappings. I don't see that they work in BUNDLE, because there's a single = RTP session, and so a single mapping from payload type to payload = format. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 27 05:41:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FEC21F9418 for ; Mon, 27 May 2013 05:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogd0WxAxeacW for ; Mon, 27 May 2013 05:41:41 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id DC39721F9031 for ; Mon, 27 May 2013 05:41:39 -0700 (PDT) Received: from [81.187.2.149] (port=34250 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ugwk4-00086b-46; Mon, 27 May 2013 13:41:38 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Mon, 27 May 2013 13:41:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> References: To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 12:41:46 -0000 I'm not sure I agree. As I said in my previous message to the list, if we are agreed that the = m=3D lines in a BUNDLE group form a single RTP session, then I believe = we need unique payload types across all m=3D lines. In this case, BUNDLE = can simply say that regular RTP source demultiplexing based on the SSRC = has to be performed, then the payload type can be used to match sources = to m=3D lines for those applications that care about doing so.=20 If we're not agreed that the m=3D lines in a BUNDLE group form a single = RTP session, then we have a lot more to discuss... Colin On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: > Here's is my proposal for roughly what the bundle draft should say = about this demux topic=20 >=20 > Application will decide which packet processing pipeline to pass an = given RTP/RTCP packet to based on what the application knows: >=20 > 1) If future RFCs define new things (like RTP header extension), that = explicitly specify the mapping, check if that future RFC is in use and = if so then use that to form the mapping=20 >=20 > 2) If the PT type is uniquely identifies a mapping, use that to form = the mapping >=20 > 3) If application knows the SSRC the other side will use, use that to = form the mapping=20 >=20 > 4) if there is no way to know which pipeline to pass it too, the = packet MAY be discarded or the application MAY decide to buffer it until = the mapping is known=20 >=20 > This is trivial to implement. It meets the requirements for Plan A, = Plan B, UCIF, CLUE, and so on.=20 >=20 > We could swap the order of step 2 and 3, My thinking for this order = was the only time it made any difference the order was if the PT were = unique and indicated a different mapping than the SSRC. The only way = this could happen is with a SSRC collision so the PT is the one that = would be correct not the SSRC. If someone feels strongly the order of = steps 2 and 3 should be the opposite way around, I can live with that. >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 27 05:45:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CFE21F9031 for ; Mon, 27 May 2013 05:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNzuY-dqq5Ea for ; Mon, 27 May 2013 05:45:08 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEA221F9452 for ; Mon, 27 May 2013 05:45:08 -0700 (PDT) Received: from [81.187.2.149] (port=49144 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UgwnT-0008MC-3E for mmusic@ietf.org; Mon, 27 May 2013 13:45:07 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Colin Perkins In-Reply-To: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> Date: Mon, 27 May 2013 13:45:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> To: "mmusic@ietf.org WG" X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 12:45:18 -0000 On 27 May 2013, at 13:29, Colin Perkins wrote: > There were a number of comments in the call last week, and on the = list, about unique payload types in BUNDLE. I'd like to explore this = further. >=20 > Case A: Within a single RTP session, I think we'd all agree that an = offer that uses the same RTP payload type for two payload formats on a = single m=3D line is problematic:=20 >=20 > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com > s=3D > c=3DIN IP4 host.anywhere.com > t=3D0 0 > m=3Daudio 49170 RTP/AVP 96 > a=3Drtpmap:96 AMR-WB/16000 > a=3Drtpmap:96 G7291/16000 >=20 > If this were done the receiver would have no way of distinguishing = what payload format is meant by payload type 96. Accordingly, unique = payload formats need to be used for each payload format. That should be "...unique payload types need to be used for each payload = format" of course. > Case B: If one were to use two separate m=3D lines on different ports, = in the non-BUNDLE case, then the same RTP payload type can be reused = without difficulty: >=20 > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com > s=3D > c=3DIN IP4 host.anywhere.com > t=3D0 0 > m=3Daudio 49170 RTP/AVP 96 > a=3Drtpmap:96 AMR-WB/16000 > m=3Daudio 49172 RTP/AVP 96 > a=3Drtpmap:96 G7291/16000 >=20 > The implication is that there are two separate RTP sessions, which the = receiver can distinguish based on the UDP port on which the packets are = received. The mapping from RTP payload types to payload formats is done = on a per-RTP session basis. >=20 > Case C: This is when we BUNDLE several m=3D lines on a single UDP = port. On the call last week, there seemed to be agreement that the m=3D = lines in such a BUNDLE group comprise a single RTP session (it also = matches the definition of an RTP session from RFC 3550: the packets go = to a single destination and the m=3D lines share a single SSRC space). = To me this would suggest that the RTP payload type values MUST be unique = across the m=3D lines (or, if the same RTP payload type is used in = different m=3D lines, it MUST map to an identical payload format). The = reason is that everything runs over one UDP port, and if a single RTP = payload type is mapped to different payload formats, there's no way to = distinguish which payload format is meant. This is essentially the same = as case A above. >=20 > Given this, it's not clear to me that non-unique payload types make = sense within a BUNDLE group. They work on different m=3D lines in the = legacy case because those lines form different RTP sessions, and the RTP = sessions can be used to scope the payload type to payload format = mappings. I don't see that they work in BUNDLE, because there's a single = RTP session, and so a single mapping from payload type to payload = format. >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon May 27 05:49:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C8721F9524 for ; Mon, 27 May 2013 05:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG7euLJ2EFVO for ; Mon, 27 May 2013 05:49:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB6A21F9452 for ; Mon, 27 May 2013 05:48:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-c3-51a3563abba1 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 19.0F.28930.A3653A15; Mon, 27 May 2013 14:48:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Mon, 27 May 2013 14:48:57 +0200 From: Christer Holmberg To: Colin Perkins , Cullen Jennings Thread-Topic: [MMUSIC] Proposal for what bundle should say about demux Thread-Index: AQHOV9/DVjr8src5NEuGXcSJwmehbJkY3cWAgAAh+IA= Date: Mon, 27 May 2013 12:48:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3799A2@ESESSMB209.ericsson.se> References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> In-Reply-To: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> 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+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvra5V2OJAg7N/BCyWvzzBaNExmc1i 6vLHLA7MHlN+b2T1mHb/PpvHkiU/mQKYo7hsUlJzMstSi/TtErgypty5wlrQIFIxYeJOtgbG Z/xdjJwcEgImEkcmzmSEsMUkLtxbzwZiCwkcZpR4t1G2i5ELyF7CKNF/7CtTFyMHB5uAhUT3 P20QU0TAU6LzsQdIObOAvMSFJWuYQGxhAVeJc0dXg9kiAm4SzUsuMEPYVhJ3t+xhBGllEVCV 6FluD2LyCvhKdK7kgFjUzCgxs/sLWDmngKPE28+/2EFsRqDLvp+CGM8sIC5x68l8JoiLBSSW 7DnPDGGLSrx8/I8VZKaEgKLE8n45iHIdiQW7P7FB2NoSyxa+BivnFRCUODnzCcsERrFZSKbO QtIyC0nLLCQtCxhZVjGy5yZm5qSXG25iBEbLwS2/dXcwnjoncohRmoNFSZxXj3dxoJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbG4tBFuyqvs3vILL7vw/I+52ZN8vOpa9puXt1Y+a1wd9ee tGDjQ41f3lft8lu2ZA5X6c+4hirnwO9Xf936mv1g17o675IVZ9N5Pya7zqo0SQpkM/HpKCwy iEwWucF7hLdeSP7w8ZCoQ1sZpb9c3Dw9NGsWn+LK/P97fIyuO3WbXyti/VKVqP1RiaU4I9FQ i7moOBEAxNF7imQCAAA= Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 12:49:04 -0000 Hi, > I'm not sure I agree. > > As I said in my previous message to the list, if we are agreed that the m= =3D lines in a BUNDLE group form a single RTP session, then I believe we > need unique payload types across all m=3D lines. In this case, BUNDLE can= simply say that regular RTP source demultiplexing based on the SSRC=20 > has to be performed, then the payload type can be used to match sources t= o m=3D lines for those applications that care about doing so.=20 > > If we're not agreed that the m=3D lines in a BUNDLE group form a single R= TP session, then we have a lot more to discuss... Keep in mind that the single-RTP-session has been an assumption for a long = time already - it was not something we agreed upon last week :) Regards, Christer On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: > Here's is my proposal for roughly what the bundle draft should say about = this demux topic=20 >=20 > Application will decide which packet processing pipeline to pass an given= RTP/RTCP packet to based on what the application knows: >=20 > 1) If future RFCs define new things (like RTP header extension), that exp= licitly specify the mapping, check if that future RFC is in use and if so t= hen use that to form the mapping=20 >=20 > 2) If the PT type is uniquely identifies a mapping, use that to form the = mapping >=20 > 3) If application knows the SSRC the other side will use, use that to for= m the mapping=20 >=20 > 4) if there is no way to know which pipeline to pass it too, the packet M= AY be discarded or the application MAY decide to buffer it until the mappin= g is known=20 >=20 > This is trivial to implement. It meets the requirements for Plan A, Plan = B, UCIF, CLUE, and so on.=20 >=20 > We could swap the order of step 2 and 3, My thinking for this order was t= he only time it made any difference the order was if the PT were unique and= indicated a different mapping than the SSRC. The only way this could happe= n is with a SSRC collision so the PT is the one that would be correct not t= he SSRC. If someone feels strongly the order of steps 2 and 3 should be the= opposite way around, I can live with that. >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon May 27 05:52:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6BF21F95E7 for ; Mon, 27 May 2013 05:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.407 X-Spam-Level: X-Spam-Status: No, score=-5.407 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwsXlvFc92EA for ; Mon, 27 May 2013 05:52:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F1ACB21F93BB for ; Mon, 27 May 2013 05:52:07 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-32-51a356f66bf1 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 83.36.31782.6F653A15; Mon, 27 May 2013 14:52:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Mon, 27 May 2013 14:52:06 +0200 From: Christer Holmberg To: Colin Perkins , "mmusic@ietf.org WG" Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOWtXocH/Y1zQW/EWt7TkWSefrJ5kY2NQAgAAiw8A= Date: Mon, 27 May 2013 12:52:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> In-Reply-To: <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> 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+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvre63sMWBBg3LzS2WvzzBaDF1+WMW ByaPaffvs3ksWfKTKYApissmJTUnsyy1SN8ugStj1dN+poJ/nBULbm9maWD8wt7FyMkhIWAi 8f71B2YIW0ziwr31bF2MXBxCAocZJaZ0PwFLCAksYZR4d7G8i5GDg03AQqL7nzZIWETAV+Lq racsIGFhAWuJg3PYIcI2Eg3T/7NA2FYSM/samUBsFgFVic/rW9hAbF6g1sn7jjGCtAoJlEuc nSkHEuYUcJRYdGcx2BhGoGu+n1oD1sosIC5x68l8JogrBSSW7DkPdbGoxMvH/1hBxkgIKEos 75eDKNeRWLD7ExuErS2xbOFrZoitghInZz5hmcAoOgvJ1FlIWmYhaZmFpGUBI8sqRvbcxMyc 9HKjTYzAGDi45bfqDsY750QOMUpzsCiJ8+rxLg4UEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wJiUeeh40N6DvtO/hl4xD1Zk/HqV6ceDVaxy0XdZ5zyRdZkwre3qlKeLWRddnXB1rnGv6msT sX6tP2F3Al8LOwdnZzQWVm+p7XhgF93UXSJZ/Wut+rE93+wDG98eWaQpkmv/54ANX6f8fB6h p1dPfImYn6Qh+uFb5slphVsv37SuLZtj33Gn54cSS3FGoqEWc1FxIgA8+OhwTwIAAA== Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 12:52:13 -0000 Hi, >> There were a number of comments in the call last week, and on the list, = about unique payload types in BUNDLE. I'd like to explore this further. >>=20 >> Case A: Within a single RTP session, I think we'd all agree that an offe= r that uses the same RTP payload type for two payload formats on a single m= =3D line is problematic:=20 >>=20 >> v=3D0 >> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com >> s=3D >> c=3DIN IP4 host.anywhere.com >> t=3D0 0 >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 AMR-WB/16000 >> a=3Drtpmap:96 G7291/16000 >>=20 >> If this were done the receiver would have no way of distinguishing what = payload format is meant by payload type 96. Accordingly, unique payload for= mats need to be used for each payload format. > > That should be "...unique payload types need to be used for each payload = format" of course. What if you have two m- lines, with identical encoding in both? Both repres= ent the same payload format, don't they? :) v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN IP4 host.anywhere.com t=3D0 0 m=3Daudio 49170 RTP/AVP 96 a=3Drtpmap:96 AMR-WB/16000 m=3Daudio 49170 RTP/AVP ??? a=3Drtpmap:??? AMR-WB/16000 Regards, Christer From csp@csperkins.org Mon May 27 05:59:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FF821F960C for ; Mon, 27 May 2013 05:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMKQJylcMbbW for ; Mon, 27 May 2013 05:59:08 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id F17B721F9607 for ; Mon, 27 May 2013 05:59:07 -0700 (PDT) Received: from [81.187.2.149] (port=42519 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ugx10-0003wU-Tw; Mon, 27 May 2013 13:59:07 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> Date: Mon, 27 May 2013 13:59:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 12:59:12 -0000 On 27 May 2013, at 13:52, Christer Holmberg wrote: >>> There were a number of comments in the call last week, and on the = list, about unique payload types in BUNDLE. I'd like to explore this = further. >>>=20 >>> Case A: Within a single RTP session, I think we'd all agree that an = offer that uses the same RTP payload type for two payload formats on a = single m=3D line is problematic:=20 >>>=20 >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com >>> s=3D >>> c=3DIN IP4 host.anywhere.com >>> t=3D0 0 >>> m=3Daudio 49170 RTP/AVP 96 >>> a=3Drtpmap:96 AMR-WB/16000 >>> a=3Drtpmap:96 G7291/16000 >>>=20 >>> If this were done the receiver would have no way of distinguishing = what payload format is meant by payload type 96. Accordingly, unique = payload formats need to be used for each payload format. >>=20 >> That should be "...unique payload types need to be used for each = payload format" of course. >=20 > What if you have two m- lines, with identical encoding in both? Both = represent the same payload format, don't they? :) >=20 > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com > s=3D > c=3DIN IP4 host.anywhere.com > t=3D0 0 > m=3Daudio 49170 RTP/AVP 96 > a=3Drtpmap:96 AMR-WB/16000 > m=3Daudio 49170 RTP/AVP ??? > a=3Drtpmap:??? AMR-WB/16000 Not sure I get your point. You can have two different payload types that = map to the same payload format in a single RTP session, since you can = always distinguish what payload format is intended. You can't have the = same payload type mapping to two different payload formats in a single = RTP session, since you can't then infer what payload format was meant.=20= --=20 Colin Perkins http://csperkins.org/ From christer.holmberg@ericsson.com Mon May 27 06:02:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E19321F94DC for ; Mon, 27 May 2013 06:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.367 X-Spam-Level: X-Spam-Status: No, score=-5.367 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH+l-6O29D+p for ; Mon, 27 May 2013 06:02:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 84BCE21F9446 for ; Mon, 27 May 2013 06:02:36 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-e7-51a3596b1a45 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8C.71.28930.B6953A15; Mon, 27 May 2013 15:02:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Mon, 27 May 2013 15:02:34 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOWtXocH/Y1zQW/EWt7TkWSefrJ5kY2NQAgAAiw8D//+EkAIAAIgyA Date: Mon, 27 May 2013 13:02:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> In-Reply-To: <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> 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+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvrW525OJAg7u35CyWvzzBaDF1+WMW ByaPaffvs3ksWfKTKYApissmJTUnsyy1SN8ugSvj3b13bAVdfBW/3zeyNzDO4e5i5OSQEDCR WNfYxgxhi0lcuLeerYuRi0NI4DCjxJWWP+wQzhJGiXXr3jJ1MXJwsAlYSHT/0wZpEBFQldhx /B8jSJhZQEuic5s1iCksYC1xcA47RIWNRMP0/ywQtpvE9H09TCA2C1Bny/K97CDlvAK+Es/O yUMs+sQocfrEXbAaTgFHiXPbZ4D1MgKd9v3UGrA4s4C4xK0n85kgThaQWLLnPNT5ohIvH/9j BZkpIaAosbxfDqJcR2LB7k9sELa2xLKFr8HKeQUEJU7OfMIygVFsFpKps5C0zELSMgtJywJG llWM7LmJmTnp5YabGIHRcXDLb90djKfOiRxilOZgURLn1eNdHCgkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBcfqiORyH4xJX9B34sipCXEHZPKZ1+RnnuE5nmyPB+1hMlxeZ9Kx8sYtvXQ/n r8fHvYoUJh18Zatp9bZU9o4Ae3KUlg7TRaEr/f7X+fcc/hWVvSb64dxnbh/urJp3+shqPeEn s/Rabpov7gmOnK0qcodN7Gfz+sOt/Tdmxda2G936ycQ0yfH0RCWW4oxEQy3mouJEAOvKhfNc AgAA Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:02:42 -0000 Hi, >>>> There were a number of comments in the call last week, and on the list= , about unique payload types in BUNDLE. I'd like to explore this further. >>>>=20 >>>> Case A: Within a single RTP session, I think we'd all agree that an of= fer that uses the same RTP payload type for two payload formats on a single= m=3D line is problematic:=20 >>>>=20 >>>> v=3D0 >>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DI= N=20 >>>> IP4 host.anywhere.com >>>> t=3D0 0 >>>> m=3Daudio 49170 RTP/AVP 96 >>>> a=3Drtpmap:96 AMR-WB/16000 >>>> a=3Drtpmap:96 G7291/16000 >>>>=20 >>>> If this were done the receiver would have no way of distinguishing wha= t payload format is meant by payload type 96. Accordingly, unique payload f= ormats need to be used for each payload format. >>>=20 >>> That should be "...unique payload types need to be used for each payloa= d format" of course. >>=20 >> What if you have two m- lines, with identical encoding in both? Both=20 >> represent the same payload format, don't they? :) >>=20 >> v=3D0 >> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN IP4= =20 >> host.anywhere.com >> t=3D0 0 >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 AMR-WB/16000 >> m=3Daudio 49170 RTP/AVP ??? >> a=3Drtpmap:??? AMR-WB/16000 > > Not sure I get your point. You can have two different payload types that = map to the same payload format in a single RTP session, since > you can always distinguish what payload format is intended. You can't hav= e the same payload type mapping to two different payload=20 > formats in a single RTP session, since you can't then infer what payload = format was meant.=20 Please not that both PTs map to the SAME payload format :) Regards, Christer From csp@csperkins.org Mon May 27 06:05:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D4C21F9626 for ; Mon, 27 May 2013 06:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.639 X-Spam-Level: X-Spam-Status: No, score=-105.639 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMEW9QVUK8bF for ; Mon, 27 May 2013 06:05:07 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48E21F9625 for ; Mon, 27 May 2013 06:05:07 -0700 (PDT) Received: from [81.187.2.149] (port=42240 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ugx6l-0004TQ-RG; Mon, 27 May 2013 14:05:06 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se> Date: Mon, 27 May 2013 14:05:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:05:12 -0000 On 27 May 2013, at 14:02, Christer Holmberg wrote: >>>>> There were a number of comments in the call last week, and on the = list, about unique payload types in BUNDLE. I'd like to explore this = further. >>>>>=20 >>>>> Case A: Within a single RTP session, I think we'd all agree that = an offer that uses the same RTP payload type for two payload formats on = a single m=3D line is problematic:=20 >>>>>=20 >>>>> v=3D0 >>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D = c=3DIN=20 >>>>> IP4 host.anywhere.com >>>>> t=3D0 0 >>>>> m=3Daudio 49170 RTP/AVP 96 >>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>> a=3Drtpmap:96 G7291/16000 >>>>>=20 >>>>> If this were done the receiver would have no way of distinguishing = what payload format is meant by payload type 96. Accordingly, unique = payload formats need to be used for each payload format. >>>>=20 >>>> That should be "...unique payload types need to be used for each = payload format" of course. >>>=20 >>> What if you have two m- lines, with identical encoding in both? Both=20= >>> represent the same payload format, don't they? :) >>>=20 >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN = IP4=20 >>> host.anywhere.com >>> t=3D0 0 >>> m=3Daudio 49170 RTP/AVP 96 >>> a=3Drtpmap:96 AMR-WB/16000 >>> m=3Daudio 49170 RTP/AVP ??? >>> a=3Drtpmap:??? AMR-WB/16000 >>=20 >> Not sure I get your point. You can have two different payload types = that map to the same payload format in a single RTP session, since >> you can always distinguish what payload format is intended. You can't = have the same payload type mapping to two different payload=20 >> formats in a single RTP session, since you can't then infer what = payload format was meant.=20 >=20 > Please not that both PTs map to the SAME payload format :) I thought I addressed that in my reply. --=20 Colin Perkins http://csperkins.org/ From fluffy@cisco.com Mon May 27 06:15:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE54C21F9446 for ; Mon, 27 May 2013 06:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bZDoeELVzwk for ; Mon, 27 May 2013 06:15:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 297DF21F9377 for ; Mon, 27 May 2013 06:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=559; q=dns/txt; s=iport; t=1369660552; x=1370870152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O72SN6J3HGXp2XUHLAZbPPldJA3yfkYjPyPJ5Nm6w2E=; b=gDpZ6T02Ui7HP2GAaolEArACwt7Mi7HrHDan9H5GBl/h00CGvQK46N// nPjSeJzAY989tKim7D/AvY0/7NHsU81DKp/WTQ3iMJxKLRZumH+/Wz5Xl 9grHJxaFC+ZvHxoi0lsPTcigb0qmAAFHO5Xbt08ci7fZ9BEF3RKOk4BDJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFAPZbo1GtJV2b/2dsb2JhbABaDoJ6gyS/EIEFFnSCIwEBAQMBOj8QAgEIDhQUEDIlAgQOBQiHfwa9eo5qAjEHgnNhA6h7glE+gic X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="215457527" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 27 May 2013 13:15:51 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4RDFppP002434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 13:15:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 27 May 2013 08:15:51 -0500 From: "Cullen Jennings (fluffy)" To: Paul Kyzivat Thread-Topic: [MMUSIC] Proposal for what bundle should say about demux Thread-Index: AQHOWtxPVjr8src5NEuGXcSJwmehbA== Date: Mon, 27 May 2013 13:15:09 +0000 Message-ID: References: <519E6265.4090102@alum.mit.edu> <519E8B58.9030604@alum.mit.edu> In-Reply-To: <519E8B58.9030604@alum.mit.edu> 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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:15:57 -0000 On May 23, 2013, at 3:34 PM, Paul Kyzivat wrote: >=20 > For instance, we have a clue case where we can have two clue switched cap= tures, one representing the video for loudest speaker, and one for the 2nd = loudest speaker. A single SSRC can move from one of those captures to the o= ther. Its the capture (identified by an rtp header extension) that selects = the processing pipeline. Note my proposal put the RTP header extension ahead of looking at SSRC to m= eet needs of CLUE and also possible stuff from UCIF.=20 From fluffy@cisco.com Mon May 27 06:16:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9736121F9377 for ; Mon, 27 May 2013 06:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOjhLEJtIga2 for ; Mon, 27 May 2013 06:16:01 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AC3B521F9610 for ; Mon, 27 May 2013 06:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2606; q=dns/txt; s=iport; t=1369660561; x=1370870161; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=10RvAOIwSpVbrqkt7Op6yR4lEhm/3SXPYF8St1j6TIY=; b=Cigo/Qp09EhNIza5Ua5TJUpXnRHZ0ojn0uRhM2IfhN9cvc2GAmfa79zb jZkYuUPGFSNj3q7xz4vOH5mXmnu/m0ebdb4wgkZQUgAjWobqIT+cH1PKX g33Iw0LcHHDMXWvh205C0gbBDDvPck8ikDfEB4HCqPdyTim87o+3jna2X 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAPZbo1GtJXHB/2dsb2JhbABagwgwwgSBBRZ0giMBAQEDAQEBATc0CwULAgEIDgoKFBAnCyUCBA4FCId/Bgy9bo5qAjEHgnNhA5NqhHqQF4MPgic X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="212399401" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 27 May 2013 13:16:01 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4RDG1xr008117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 13:16:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 27 May 2013 08:16:00 -0500 From: "Cullen Jennings (fluffy)" To: Colin Perkins Thread-Topic: [MMUSIC] Proposal for what bundle should say about demux Thread-Index: AQHOWtxUVjr8src5NEuGXcSJwmehbA== Date: Mon, 27 May 2013 13:15:18 +0000 Message-ID: References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> In-Reply-To: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> 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="us-ascii" Content-ID: <0DE5EA6B8C39DE48B8A7EF6379B03C3F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:16:07 -0000 Great - sounds like we agree this algorithm will work. On May 27, 2013, at 6:41 AM, Colin Perkins wrote: > I'm not sure I agree. >=20 > As I said in my previous message to the list, if we are agreed that the m= =3D lines in a BUNDLE group form a single RTP session, then I believe we ne= ed unique payload types across all m=3D lines. In this case, BUNDLE can sim= ply say that regular RTP source demultiplexing based on the SSRC has to be = performed, then the payload type can be used to match sources to m=3D lines= for those applications that care about doing so.=20 >=20 > If we're not agreed that the m=3D lines in a BUNDLE group form a single R= TP session, then we have a lot more to discuss... >=20 > Colin >=20 >=20 >=20 > On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: >> Here's is my proposal for roughly what the bundle draft should say about= this demux topic=20 >>=20 >> Application will decide which packet processing pipeline to pass an give= n RTP/RTCP packet to based on what the application knows: >>=20 >> 1) If future RFCs define new things (like RTP header extension), that ex= plicitly specify the mapping, check if that future RFC is in use and if so = then use that to form the mapping=20 >>=20 >> 2) If the PT type is uniquely identifies a mapping, use that to form the= mapping >>=20 >> 3) If application knows the SSRC the other side will use, use that to fo= rm the mapping=20 >>=20 >> 4) if there is no way to know which pipeline to pass it too, the packet = MAY be discarded or the application MAY decide to buffer it until the mappi= ng is known=20 >>=20 >> This is trivial to implement. It meets the requirements for Plan A, Plan= B, UCIF, CLUE, and so on.=20 >>=20 >> We could swap the order of step 2 and 3, My thinking for this order was = the only time it made any difference the order was if the PT were unique an= d indicated a different mapping than the SSRC. The only way this could happ= en is with a SSRC collision so the PT is the one that would be correct not = the SSRC. If someone feels strongly the order of steps 2 and 3 should be th= e opposite way around, I can live with that. >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Mon May 27 06:27:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33EF21F94F9 for ; Mon, 27 May 2013 06:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfloqVcuXjjc for ; Mon, 27 May 2013 06:27:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CCF4321F93BB for ; Mon, 27 May 2013 06:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2687; q=dns/txt; s=iport; t=1369661233; x=1370870833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e02bNG0yLtam6ORzVsO+6S2B5+Aw1qHXpZdGkSdrpTk=; b=IOxCX0Yap1VwCyng4GcvO3KBtf5OGz+hcM8v2Nvm1dVDiVAsxYDoNWnL 6d3IAjEu2+Rhbm3ZKtw+tFhOfLLJpfKRQbTKOqX+YTrrmMddMPoJZG7/k Hed0WDnSYvwhUVxHjX2jG9pCL/GfrhZIoV55ey7WE/qJZ1a4XBRkQW8z+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFADJeo1GtJXG//2dsb2JhbABagwgwwgSBBRZ0giMBAQEDATo/BQsCAQgOFBQQMiUCBA4FCId/Br13jmoCMQeCc2EDmGSQF4MPgic X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="212402461" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 27 May 2013 13:27:12 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4RDRCGM009514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 13:27:12 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 27 May 2013 08:27:11 -0500 From: "Cullen Jennings (fluffy)" To: Colin Perkins Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOWt3kxt/fJqOvXUqSPUkSHtfgTg== Date: Mon, 27 May 2013 13:26:29 +0000 Message-ID: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> In-Reply-To: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> 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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:27:17 -0000 On May 27, 2013, at 6:29 AM, Colin Perkins wrote: > Case A: Within a single RTP session, I think we'd all agree that an offer= that uses the same RTP payload type for two payload formats on a single m= =3D line is problematic:=20 >=20 > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com > s=3D > c=3DIN IP4 host.anywhere.com > t=3D0 0 > m=3Daudio 49170 RTP/AVP 96 > a=3Drtpmap:96 AMR-WB/16000 > a=3Drtpmap:96 G7291/16000 >=20 > If this were done the receiver would have no way of distinguishing what p= ayload format is meant by payload type 96. Accordingly, unique payload form= ats need to be used for each payload format. >=20 yes - agree of course > Case B: If one were to use two separate m=3D lines on different ports, in= the non-BUNDLE case, then the same RTP payload type can be reused without = difficulty: >=20 > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com > s=3D > c=3DIN IP4 host.anywhere.com > t=3D0 0 > m=3Daudio 49170 RTP/AVP 96 > a=3Drtpmap:96 AMR-WB/16000 > m=3Daudio 49172 RTP/AVP 96 > a=3Drtpmap:96 G7291/16000 >=20 > The implication is that there are two separate RTP sessions, which the re= ceiver can distinguish based on the UDP port on which the packets are recei= ved. The mapping from RTP payload types to payload formats is done on a per= -RTP session basis. also agree of course=20 >=20 > Case C: This is when we BUNDLE several m=3D lines on a single UDP port. O= n the call last week, there seemed to be agreement that the m=3D lines in s= uch a BUNDLE group comprise a single RTP session (it also matches the defin= ition of an RTP session from RFC 3550: the packets go to a single destinati= on and the m=3D lines share a single SSRC space). To me this would suggest = that the RTP payload type values MUST be unique across the m=3D lines (or, = if the same RTP payload type is used in different m=3D lines, it MUST map t= o an identical payload format). The reason is that everything runs over one= UDP port, and if a single RTP payload type is mapped to different payload = formats, there's no way to distinguish which payload format is meant. This = is essentially the same as case A above. Sure, suspect many people agree with you but the media pipeline is more tha= n just the codec. So if I have 150 thumbnail videos that all using VP8, usi= ng one PT for all of them might be fine given they are all the same codec b= ut they still might need SSRC to be able to figure out which window to rend= er them in. I think that is all the algorithm I am proposing tries to be ab= le to do.=20 From fluffy@cisco.com Mon May 27 06:31:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E10721F9696 for ; Mon, 27 May 2013 06:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMuGa+63vWkJ for ; Mon, 27 May 2013 06:31:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 424D721F95EF for ; Mon, 27 May 2013 06:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2408; q=dns/txt; s=iport; t=1369661498; x=1370871098; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jg0yjP1Kx3813GcGTpyRpLxnRBD1xr2SX7kXBClxvPg=; b=DYzP1XsIWawYnuAM51NWpvoxLZhEyyVFidTwjTyeYZXrJD1uGztzaMip Nf6+FVTzjWPDkSDurQ/aC5wT1xs3xU1PuZ9QVlPkHo+JGo2XBgIF49clb V1Hosevx/U/Csd5A2mgCEB7wv3GZzUgcjX4v4n6phLhAGyJ2n+ZzTCl83 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAEJfo1GtJXG+/2dsb2JhbABagwgwwgSBBRZ0giMBAQEDAQEBAWsLBQsCAQgiJCcLJQIEDgUIh38GDL1sBI5qAjEHgnNhA4wwhzqKYYowgw+CJw X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="215380960" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 27 May 2013 13:31:37 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4RDVbV7030835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 13:31:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 27 May 2013 08:31:37 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions Thread-Index: AQHOWt6DXXiL+A3G8kewvn8ifQrPzg== Date: Mon, 27 May 2013 13:30:55 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> 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: <8D10D614B08ADA4289C4B6ACAF187725@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:31:43 -0000 4 and 5 are very confusing and do not match the notes I had from the call. = I'm pretty sure I disagree with both of them.=20 >From a requirement point of view, I think it is very important that the ans= wer be able to reject any m-line by setting it's port to zero. On May 24, 2013, at 6:32 AM, Christer Holmberg wrote: > Hi, > =20 > At the interim meeting yesterday, we agreed on some restrictions regardin= g creating SDP answers containing bundle group(s). > =20 > Note that the restrictions 1-3 are simply alignments with RFC 5888, and a= re listed simply for clarification purpose. Restrictions 4 is BUNDLE specif= ic. Restriction 5 is also alignment with RFC 5888, as m- lines with port ze= ro are not allowed within groups, but we will need some clarification text = saying that a new offer will have to be sent in order to remove a stream (e= ither from a bundle group, or completely from the session). > =20 > (Note that the text below is not necessarily the wording that will go int= o the draft) > =20 > In an SDP answer: > 1) a BUNDLE group MUST NOT be created, unless it was included in the= associated offer > 2) an m- line MUST NOT be added to a BUNDLE group, unless it was inc= luded in a BUNDLE group in the associated offer > 3) an m- line MUST NOT be added to another BUNDLE group than the gro= up in which was included in the associated offer > 4) an m- line MUST NOT be removed from a BUNDLE group if, in the ass= ociated offer, an identical port number was indicated for all m- lines in a= BUNDLE group > 5) an m- line MUST NOT be rejected if, in the associated offer, an i= dentical port number was indicated for all m- lines in a BUNDLE group > =20 > =20 > Note that there is also a discussion regarding bundle offers, e.g. when r= estrictions when adding new m- lines to a bundle. Based on the outcome of t= hat, there may be some additional answer restrictions, e.g. regarding the c= hange of bundle transport parameters. But, let=92s deal with that in the of= fer thread. > =20 > So, if anyone OBJECTS to the restrictions above, please indicate so. > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Mon May 27 06:38:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA20821F8CEC for ; Mon, 27 May 2013 06:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-LYxurfiK-i for ; Mon, 27 May 2013 06:38:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DFB7D21F900C for ; Mon, 27 May 2013 06:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2590; q=dns/txt; s=iport; t=1369661897; x=1370871497; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=A5GS21mgRf7ylrOOaBgbBw5RgGkD3WneBv/uRXsVlBc=; b=OtCGCRakhOye/qgXgGegQ8+wcvst8GpNbB9pCAuRGwE7tzT+5bXDW4c9 YoVbP434MSiyoEprk6tZncQ4bFd4xHspqiFvUrinSKqaYhpV4U7gfuqnO fcLxseo7HyQMO8RcyyZQhdUP0y5r9L+fFZZKfErH/ScMPDOLPiS3sLM/w I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAPpgo1GtJV2d/2dsb2JhbABaDoJ6MMIEgQUWdIIjAQEBAwEBAQFrCwULAgEIDgoKJCcLJQIEDgUIh38GDL1tBI5qAjEHgnNhA6h7gVh5PoIn X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="215369503" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 27 May 2013 13:38:16 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4RDcGI2025945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 13:38:16 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 27 May 2013 08:38:16 -0500 From: "Cullen Jennings (fluffy)" To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between Thread-Index: AQHOWt9wzBL6ABpIi0iAP6QK6ck69g== Date: Mon, 27 May 2013 13:37:33 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C3777C9@ESESSMB209.ericsson.se> <519F7ADF.1010909@alum.mit.edu> In-Reply-To: <519F7ADF.1010909@alum.mit.edu> 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: <1EC3258B52B87F42A35AC3DCFA816367@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:38:21 -0000 I think a agree with Paul's text but I read it as almost the opposite of wh= at you wrote. I think some examples would help So if the offer has 3 m-lines with A,B, C in a bundle with ports 1,2,3. It = is fine for the answer to put m-lines A and B in a bundle both using port 1= but then have C outside the bundle using port 3. Do have this right? Would= a detail example help ? On May 24, 2013, at 8:36 AM, Paul Kyzivat wrote: > I agree with the sense of what you state below. > I have some nits with the words you use. >=20 > On 5/24/13 6:28 AM, Christer Holmberg wrote: >> Hi, >>=20 >> At the interim yesterday, we agreed that an answerer MUST always include >> identical ports* (usage of port zero within a bundle is a separate >> topic) for all m- lines within an bundle group. >>=20 >> If the answerer wants to use different ports* for some/all m- lines, it >> MUST NOT include those m- lines in a bundle group >=20 > OK so far. But: >=20 >> (if they already are >> in a bundle group, a separate offer is needed to remove them). >=20 > This depends on what you mean by "already in a bundle group". > Certainly they are already in a bundle group in the offer, so presumably = that is not what you mean. >=20 > I presume you mean that they were already in a bundle group in the prior = O/A. >=20 > I think this can be stated more clearly. How about: >=20 > The answer to an offer containing a bundle group may remove an m-line fro= m the bundle group if (and only if) the address/port of the m-line in the o= ffer is distinct from the address/port of all the other m-lines in the offe= red bundle group. When doing so it must supply a unique address/port for th= at m-line in the answer. >=20 > Thanks, > Paul >=20 >> WHAT IT MEANS: There is no way for an answerer to tell that the offerer, >> for certain m- lines, can use the same port*, eventhough the answer will >> use separate ports*. >>=20 >> I will work on some actual text proposal later, but please indicate if >> you OBJECT to this approach in general. >>=20 >> Regards, >>=20 >> Christer >>=20 >> NOTE: =93port=94 =3D port:address combination =96 we are working on comi= ng up >> with better terminology J >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From emcho@sip-communicator.org Mon May 27 06:39:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2919421F900C for ; Mon, 27 May 2013 06:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TabaAoDG2rT for ; Mon, 27 May 2013 06:39:14 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8AE21F9350 for ; Mon, 27 May 2013 06:39:14 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj1so1618613pad.1 for ; Mon, 27 May 2013 06:39:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=b0+PpCXM6w/Kt8qlNifvbDQ8Q2JBP25hixO+OFxPv8U=; b=PKv3r2obHAY0eg2sklmY1X7qFO7iSBXfxhEmnvM0OD1uNfO4P8xU11Vxg0ki/5Wpbf DE5lD0OSXP6bvsuWSCICxah97aEdsG7suLvJSQsXXmRJsxmShk6kHPbOgtQjOOTEoCvd R52r7izrLWk/SCWqnWT+NugguK5Em2pgoNCHLOjbyWhDyONgjsu7nvOnLd3ZUWlu+gUc eL/VwnsijtbTZQQf36ANSOiK1N/Cf4NX8qwryOQqoYbZhp7ugKO5DSMgULmVe/tzRjzX 5Kt8DJelIvtZrf2+eq74aXfmU+4WB3vY3mxQEKACpSaG1tAgmj/b0YTELGyNaczeTSPj Fpag== X-Received: by 10.68.194.202 with SMTP id hy10mr29220026pbc.44.1369661953871; Mon, 27 May 2013 06:39:13 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by mx.google.com with ESMTPSA id vz8sm30666551pac.20.2013.05.27.06.39.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 May 2013 06:39:13 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb11so5517723pad.37 for ; Mon, 27 May 2013 06:39:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.88.38 with SMTP id bd6mr30720026pab.184.1369661952716; Mon, 27 May 2013 06:39:12 -0700 (PDT) Received: by 10.66.89.234 with HTTP; Mon, 27 May 2013 06:39:12 -0700 (PDT) Received: by 10.66.89.234 with HTTP; Mon, 27 May 2013 06:39:12 -0700 (PDT) In-Reply-To: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> Date: Mon, 27 May 2013 16:39:12 +0300 Message-ID: From: Emil Ivov To: Cullen Jennings Content-Type: multipart/alternative; boundary=f46d042dfeaf27a59204ddb346c4 X-Gm-Message-State: ALoCoQms/aRD8HqeXxSzRfb2xNTFV365PZa7hpCsnWFyVEuJYzH92KQrYi84I9L5sL18bhiN/UTf Cc: Colin Perkins , mmusic Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:39:20 -0000 --f46d042dfeaf27a59204ddb346c4 Content-Type: text/plain; charset=ISO-8859-1 On May 27, 2013 4:27 PM, "Cullen Jennings (fluffy)" wrote: > Sure, suspect many people agree with you but the media pipeline is > more than just the codec. So if I have 150 thumbnail videos that all > using VP8, using one PT for all of them might be fine given they are all > the same codec but they still might need SSRC to be able to figure out > which window to render them in. How is tuis a demuxing issue? Isn't this more closely related to application policies and hence subject to application specific signalling? Of course that signalling can use SSRCs but this does this make it an RTP issue? Emil --sent from my mobile --f46d042dfeaf27a59204ddb346c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 27, 2013 4:27 PM, "Cullen Jennings (fluffy)" <fluffy@cisco.com> wrote:

> Sure, suspect many people agree with you but the media = pipeline is
>=A0 more than just the codec. So if I have 150 thumbnail videos that al= l
> using VP8, using one PT for all of them might be fine given they are a= ll
> the same codec but they still might need SSRC to be able to figure out=
> which window to render them in.

How is tuis a demuxing issue?

Isn't this more closely related to application policies = and hence subject to application specific signalling? Of course that signal= ling can use SSRCs but this does this make it an RTP issue?

Emil

--sent from my mobile

--f46d042dfeaf27a59204ddb346c4-- From fluffy@cisco.com Mon May 27 06:42:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF81521F901A for ; Mon, 27 May 2013 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ps-Mdn1OsvA for ; Mon, 27 May 2013 06:42:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9732C21F900C for ; Mon, 27 May 2013 06:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2759; q=dns/txt; s=iport; t=1369662152; x=1370871752; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dqMVRq5tgBA3ATBOQpBeTIPU4f/+gTohH4JRAueDysM=; b=eEHC/mwuqfGWxw9ejwu/KOyPeet9SyiM1OUp9hqcYasLCjSV+VR09vxT t5vcIDZbnM/kQ9jERhmz4BUENDDErAj5ym7FB01vF842IPx27ChBGPjXW ne6WnOdpGKcB/+BWJwndANiKVy69/VwSKm/it8//iX1TOzMYlOKdpbCI3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAG1ho1GtJXG9/2dsb2JhbABagwgwwgSBBRZ0giMBAQEDAQEBATc0CwULAgEIIhQQJwslAgQOBQiHfwYMvW0EjmoCMQeCc2EDk2qVEYMPgic X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="215383815" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 27 May 2013 13:42:31 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4RDgVmc002035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 13:42:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 27 May 2013 08:42:31 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Thread-Index: AQHOWuAJQ8u7oBS0/0SSymrxAHLF5A== Date: Mon, 27 May 2013 13:41:49 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> <519F7DEB.2010809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3794F5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3794F5@ESESSMB209.ericsson.se> 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="us-ascii" Content-ID: <04A5E7068BF5A2438D9BE43FD76AA429@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:42:38 -0000 sounds good to me along with the port zero fix=20 On May 27, 2013, at 3:27 AM, Christer Holmberg wrote: > Hi, >=20 >>> At the interim yesterday, we agreed to use the SDP BUNDLE group=20 >>> attribute to indicate on which port bundled media will be sent. In an=20 >>> SDP offer, the order of the attribute mid values can be used by the=20 >>> offerer to indicate a "wish", but the first attribute mid value in the= =20 >>> answer indicates where the answerer will eventually send bundled media. >>=20 >> This could be interpreted to mean the first a=3Dmid value in the SDP. >> I'm sure you mean "the first mid value in the a=3Dgroup:bundle" line. >=20 > Yes. >=20 >> Or perhaps "the first mid value in the bundle group" - assuming there is= a definition that "bundle group" means an a=3Dgroup:bundle line. >=20 > In the draft "bundle group" means (or, at least is supposed to mean :) th= e bundle grouped m- lines, and in general I think it is better to explicitl= y mention the line/attribute. >=20 >> This can be "future proofed" by saying that the first mid value in the b= undle group in the answer that references an m-line with non-zero=20 >> port value. I realize this adds nothing unless 5888 is revised to permit= m-lines with zero port in a bundle group. But at least it will be ready fo= r that, and harms nothing. >=20 > I agree, but suggest a little different wording: by saying the first mid = value in the group attribute MUST NOT represent a port zero m- line. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >> The main usage of this is the "initial offer", when each m- line=20 >> within a bundle group has a different port value. >>=20 >> So far so good. >>=20 >> The reason I say "almost decision" is because we have started a new=20 >> discussion regarding updated offers, adding new m- lines etc. We need=20 >> to make sure that the order-to-mid-values semantics also apply to=20 >> those, and what restrictions there are when adding m- lines. >>=20 >> But, for now, if you OBJECT to the general principle of using the SDP=20 >> group attribute mid value order for indicating the port where media=20 >> will be sent, please indicate so. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=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 mzanaty@cisco.com Mon May 27 06:47:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D201A21F920B for ; Mon, 27 May 2013 06:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbR9Rbr7ecUr for ; Mon, 27 May 2013 06:47:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DA09C21F91A0 for ; Mon, 27 May 2013 06:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1369662428; x=1370872028; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kyBRLsouosYwfxAn6HHuhOjwQzCulTcrtOM3DTEEi+s=; b=eqbfK9IwqmsEmUiA0EJVM/sttaDyBgUHlwsSLFRvW87LcCQr5Cz9ZUFv yqGba2bjhNgEM1kLYPoJ/ci9J9CU11tHl1t/RS+JMLmcFqTTJYiFKiRQr 6TifcwkLBeH3haJoh13Dp1HLlz4V1ywukpmIhqCIC4qXChKVlGoE6X0UJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAAJjo1GtJV2b/2dsb2JhbABQCoMIMMIEgQUWdIIjAQEBBAEBATc0CxACAQgOCh4QJwslAgQOBYgNDL12jWGBCTMHgnNhA5c7gSmQF4MP X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="215181794" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 27 May 2013 13:47:07 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4RDl7tq024099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 13:47:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 27 May 2013 08:47:07 -0500 From: "Mo Zanaty (mzanaty)" To: Colin Perkins Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOWtXlk2PdGZb5R0u/lFNVUkQUPZkZTi0AgAAB84CAAAH0AIAAAPoAgAAAsAD//7fwvg== Date: Mon, 27 May 2013 13:47:06 +0000 Message-ID: <6D94E7F9-1AB2-4B39-8750-434FFFC5293A@cisco.com> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> In-Reply-To: <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org WG" , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:47:16 -0000 The gist of Christer's question is: unique payload types just for unique pa= yload formats, or also for unique sources? I think we all agree the former = is true, and this seems to be Colin's point below. But Plan A proposes the = latter and extends PT uniqueness to identify sources not just payloads. Mo On May 27, 2013, at 9:05 AM, "Colin Perkins" wrote: On 27 May 2013, at 14:02, Christer Holmberg wrote: >>>>> There were a number of comments in the call last week, and on the lis= t, about unique payload types in BUNDLE. I'd like to explore this further. >>>>>=20 >>>>> Case A: Within a single RTP session, I think we'd all agree that an o= ffer that uses the same RTP payload type for two payload formats on a singl= e m=3D line is problematic:=20 >>>>>=20 >>>>> v=3D0 >>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DI= N=20 >>>>> IP4 host.anywhere.com >>>>> t=3D0 0 >>>>> m=3Daudio 49170 RTP/AVP 96 >>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>> a=3Drtpmap:96 G7291/16000 >>>>>=20 >>>>> If this were done the receiver would have no way of distinguishing wh= at payload format is meant by payload type 96. Accordingly, unique payload = formats need to be used for each payload format. >>>>=20 >>>> That should be "...unique payload types need to be used for each paylo= ad format" of course. >>>=20 >>> What if you have two m- lines, with identical encoding in both? Both=20 >>> represent the same payload format, don't they? :) >>>=20 >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN IP= 4=20 >>> host.anywhere.com >>> t=3D0 0 >>> m=3Daudio 49170 RTP/AVP 96 >>> a=3Drtpmap:96 AMR-WB/16000 >>> m=3Daudio 49170 RTP/AVP ??? >>> a=3Drtpmap:??? AMR-WB/16000 >>=20 >> Not sure I get your point. You can have two different payload types that= map to the same payload format in a single RTP session, since >> you can always distinguish what payload format is intended. You can't ha= ve the same payload type mapping to two different payload=20 >> formats in a single RTP session, since you can't then infer what payload= format was meant.=20 >=20 > Please not that both PTs map to the SAME payload format :) I thought I addressed that in my reply. --=20 Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Mon May 27 06:52:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF8C21F92EB for ; Mon, 27 May 2013 06:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJTc-19JKCaV for ; Mon, 27 May 2013 06:52:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 788A121F92F5 for ; Mon, 27 May 2013 06:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1354; q=dns/txt; s=iport; t=1369662743; x=1370872343; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4HPEIDNNyVx9s/zg+nx0/XlYxoIlwV2ZaoX32ot0I+w=; b=WWOCSiXV6EO8s8b7KoMzvEnocmUtzfKFrEj7t+TdUK/2pk8WBIDL1e3A CoZwzpwkrCA1JsUmVRt6Ipw0I0rImjGlKhexkEpltffkIQhD/rrJdIeC4 oElRmUUCnYuz0s2/NqIEWa0Nejyfo2SSWJfw3QnN5G0wX4h9qfxi7jqAN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALljo1GtJV2d/2dsb2JhbABagwjCNIEFFnSCIwEBAQMBeRACAQgOCgokMiUCBA4FCId/Br4CjmoCMQeCc2EDiGegFIMPgic X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="215386286" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 27 May 2013 13:52:23 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4RDqN3l006432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 13:52:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 27 May 2013 08:52:22 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOWt+UtKSl0n/dG02LnqM8tZy+HJkZYOaA Date: Mon, 27 May 2013 13:51:40 +0000 Message-ID: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> In-Reply-To: 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="iso-8859-1" Content-ID: <7001169E96382F4BA654EF3E753F9649@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:52:35 -0000 On May 27, 2013, at 7:39 AM, Emil Ivov wrote: >=20 > On May 27, 2013 4:27 PM, "Cullen Jennings (fluffy)" wr= ote: >=20 > > Sure, suspect many people agree with you but the media pipeline is > > more than just the codec. So if I have 150 thumbnail videos that all=20 > > using VP8, using one PT for all of them might be fine given they are al= l=20 > > the same codec but they still might need SSRC to be able to figure out= =20 > > which window to render them in. >=20 > How is tuis a demuxing issue? >=20 > Isn't this more closely related to application policies and hence subject= to application specific signalling? Of course that signalling can use SSRC= s but this does this make it an RTP issue? >=20 > Emil I agree. I don't think it is an AVT* issues, I think it is a MMUSIC issues.= One of the application signaling approaches often used for RTP is SDP. Thi= s is a SDP issue. In the plan A context, it can be roughly summarized as ho= w do the RTP packets know which m-line in the SDP they are associated with.= I think Ted put it better when he said which processing pipeline. Then thi= ngs like like the content attribute in SDP can bind it to the applications = intent. In the plan B context you might not use the word m-line but it is r= oughly the same problem.=20 From csp@csperkins.org Mon May 27 06:57:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1EF21F940B for ; Mon, 27 May 2013 06:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMJDXF+MzQ1R for ; Mon, 27 May 2013 06:57:27 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7331C21F942B for ; Mon, 27 May 2013 06:57:27 -0700 (PDT) Received: from [81.187.2.149] (port=42645 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UgxvP-0006id-Vh; Mon, 27 May 2013 14:57:26 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Mon, 27 May 2013 14:57:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:57:32 -0000 I don't agree with the phrasing about "packet processing pipelines", but = can't tell if this is a terminology disagreement or a more fundamental = disconnect. The way I see the demultiplexing logically working is: | | packets +-- v | +----------+ | |UDP socket| A | +----------+ | RTP || | | | and RTCP || | +------> SCTP | || +---------> STUN/ICE +-- || +-- || | split by SSRC | || || || | || || || B | +--+ +--+ +--+ | |PB| |PB| |PB| Playout buffer, process RTCP, FEC, etc. | +--+ +--+ +--+ +-- | | | +-- | / | | +---+ | | / | | C | +--+ +--+ +--+ | |CR| |CR| |CR| Codecs and rendering | +--+ +--+ +--+ +-- If your algorithm is for demultiplexing at layer C, i.e., to figure out = what codec and rendering pipeline to use, then I think we're in = agreement apart from terminology.=20 For layer B, I believe the SSRC is the right thing to use to = demultiplex, and fits with RTP and RTCP. This is where RTCP is = processed, playout de-jitter buffering happens, FEC is processed, NACKs = are sent, etc. It's logically independent of the decoding and rendering = process since you can start filling your de-jitter buffer for an SSRC = before you figure out if/how/where you're going to render that SSRC.=20 For layer A, there was a clear-cut way of doing this with RTP, RTCP, and = STUN. I haven't looked at SCTP enough to know how that affects things. I = do think it's a logically separate issue, and should be documented = separately to BUNDLE though, since it the same issues arise with = non-bundled sessions. An implementation might merge these together, of course, but to avoid = confusion the standards should be clear what level they're considering. Colin On 27 May 2013, at 14:15, Cullen Jennings (fluffy) wrote: > Great - sounds like we agree this algorithm will work. >=20 > On May 27, 2013, at 6:41 AM, Colin Perkins wrote: >=20 >> I'm not sure I agree. >>=20 >> As I said in my previous message to the list, if we are agreed that = the m=3D lines in a BUNDLE group form a single RTP session, then I = believe we need unique payload types across all m=3D lines. In this = case, BUNDLE can simply say that regular RTP source demultiplexing based = on the SSRC has to be performed, then the payload type can be used to = match sources to m=3D lines for those applications that care about doing = so.=20 >>=20 >> If we're not agreed that the m=3D lines in a BUNDLE group form a = single RTP session, then we have a lot more to discuss... >>=20 >> Colin >>=20 >>=20 >>=20 >> On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: >>> Here's is my proposal for roughly what the bundle draft should say = about this demux topic=20 >>>=20 >>> Application will decide which packet processing pipeline to pass an = given RTP/RTCP packet to based on what the application knows: >>>=20 >>> 1) If future RFCs define new things (like RTP header extension), = that explicitly specify the mapping, check if that future RFC is in use = and if so then use that to form the mapping=20 >>>=20 >>> 2) If the PT type is uniquely identifies a mapping, use that to form = the mapping >>>=20 >>> 3) If application knows the SSRC the other side will use, use that = to form the mapping=20 >>>=20 >>> 4) if there is no way to know which pipeline to pass it too, the = packet MAY be discarded or the application MAY decide to buffer it until = the mapping is known=20 >>>=20 >>> This is trivial to implement. It meets the requirements for Plan A, = Plan B, UCIF, CLUE, and so on.=20 >>>=20 >>> We could swap the order of step 2 and 3, My thinking for this order = was the only time it made any difference the order was if the PT were = unique and indicated a different mapping than the SSRC. The only way = this could happen is with a SSRC collision so the PT is the one that = would be correct not the SSRC. If someone feels strongly the order of = steps 2 and 3 should be the opposite way around, I can live with that. >>>=20 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 27 07:00:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D368121F965C for ; Mon, 27 May 2013 07:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.656 X-Spam-Level: X-Spam-Status: No, score=-105.656 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGcPOI2rN4sH for ; Mon, 27 May 2013 06:59:57 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 157F921F940B for ; Mon, 27 May 2013 06:59:57 -0700 (PDT) Received: from [81.187.2.149] (port=37643 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ugxxo-0006nh-PQ; Mon, 27 May 2013 14:59:56 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Mon, 27 May 2013 14:59:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <178BDB89-3526-48CD-9566-C4AD244DB1B0@csperkins.org> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 14:00:02 -0000 On 27 May 2013, at 14:26, Cullen Jennings (fluffy) wrote: > On May 27, 2013, at 6:29 AM, Colin Perkins wrote: >> Case A: Within a single RTP session, I think we'd all agree that an = offer that uses the same RTP payload type for two payload formats on a = single m=3D line is problematic:=20 >>=20 >> v=3D0 >> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com >> s=3D >> c=3DIN IP4 host.anywhere.com >> t=3D0 0 >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 AMR-WB/16000 >> a=3Drtpmap:96 G7291/16000 >>=20 >> If this were done the receiver would have no way of distinguishing = what payload format is meant by payload type 96. Accordingly, unique = payload formats need to be used for each payload format. >>=20 >=20 > yes - agree of course >=20 >> Case B: If one were to use two separate m=3D lines on different = ports, in the non-BUNDLE case, then the same RTP payload type can be = reused without difficulty: >>=20 >> v=3D0 >> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com >> s=3D >> c=3DIN IP4 host.anywhere.com >> t=3D0 0 >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 AMR-WB/16000 >> m=3Daudio 49172 RTP/AVP 96 >> a=3Drtpmap:96 G7291/16000 >>=20 >> The implication is that there are two separate RTP sessions, which = the receiver can distinguish based on the UDP port on which the packets = are received. The mapping from RTP payload types to payload formats is = done on a per-RTP session basis. >=20 > also agree of course=20 >=20 >>=20 >> Case C: This is when we BUNDLE several m=3D lines on a single UDP = port. On the call last week, there seemed to be agreement that the m=3D = lines in such a BUNDLE group comprise a single RTP session (it also = matches the definition of an RTP session from RFC 3550: the packets go = to a single destination and the m=3D lines share a single SSRC space). = To me this would suggest that the RTP payload type values MUST be unique = across the m=3D lines (or, if the same RTP payload type is used in = different m=3D lines, it MUST map to an identical payload format). The = reason is that everything runs over one UDP port, and if a single RTP = payload type is mapped to different payload formats, there's no way to = distinguish which payload format is meant. This is essentially the same = as case A above. >=20 > Sure, suspect many people agree with you but the media pipeline is = more than just the codec. So if I have 150 thumbnail videos that all = using VP8, using one PT for all of them might be fine given they are all = the same codec but they still might need SSRC to be able to figure out = which window to render them in. Of course. > I think that is all the algorithm I am proposing tries to be able to = do.=20 Then perhaps the disagreement is just about terminology, and what point = in the reception process we're talking about demultiplexing. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 27 07:06:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AC021F8FCB for ; Mon, 27 May 2013 07:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.624 X-Spam-Level: X-Spam-Status: No, score=-105.624 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfjCiYsB7ysF for ; Mon, 27 May 2013 07:05:58 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53BBF21F89D5 for ; Mon, 27 May 2013 07:05:58 -0700 (PDT) Received: from [81.187.2.149] (port=39268 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ugy3f-0007Wt-9k; Mon, 27 May 2013 15:05:57 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <6D94E7F9-1AB2-4B39-8750-434FFFC5293A@cisco.com> Date: Mon, 27 May 2013 15:05:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <63BA9030-983D-4426-A378-C6634F77D4DA@csperkins.org> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <6D94E7F9-1AB2-4B39-8750-434FFFC5293A@cisco.com> To: "Mo Zanaty (mzanaty)" X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org WG" , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 14:06:02 -0000 The SSRC identifies the source in RTP: that's fundamental to the design = of the protocol.=20 If Plan A wants to use unique PT values to determine how and where a = source is rendered, that's fine, subject to the limited number of PT = values. I don't think it's fine to redefine the PT as identifying the = source. Colin On 27 May 2013, at 14:47, Mo Zanaty (mzanaty) wrote: > The gist of Christer's question is: unique payload types just for = unique payload formats, or also for unique sources? I think we all agree = the former is true, and this seems to be Colin's point below. But Plan A = proposes the latter and extends PT uniqueness to identify sources not = just payloads. >=20 > Mo >=20 >=20 > On May 27, 2013, at 9:05 AM, "Colin Perkins" = wrote: >=20 > On 27 May 2013, at 14:02, Christer Holmberg wrote: >>>>>> There were a number of comments in the call last week, and on the = list, about unique payload types in BUNDLE. I'd like to explore this = further. >>>>>>=20 >>>>>> Case A: Within a single RTP session, I think we'd all agree that = an offer that uses the same RTP payload type for two payload formats on = a single m=3D line is problematic:=20 >>>>>>=20 >>>>>> v=3D0 >>>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D = c=3DIN=20 >>>>>> IP4 host.anywhere.com >>>>>> t=3D0 0 >>>>>> m=3Daudio 49170 RTP/AVP 96 >>>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>>> a=3Drtpmap:96 G7291/16000 >>>>>>=20 >>>>>> If this were done the receiver would have no way of = distinguishing what payload format is meant by payload type 96. = Accordingly, unique payload formats need to be used for each payload = format. >>>>>=20 >>>>> That should be "...unique payload types need to be used for each = payload format" of course. >>>>=20 >>>> What if you have two m- lines, with identical encoding in both? = Both=20 >>>> represent the same payload format, don't they? :) >>>>=20 >>>> v=3D0 >>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN = IP4=20 >>>> host.anywhere.com >>>> t=3D0 0 >>>> m=3Daudio 49170 RTP/AVP 96 >>>> a=3Drtpmap:96 AMR-WB/16000 >>>> m=3Daudio 49170 RTP/AVP ??? >>>> a=3Drtpmap:??? AMR-WB/16000 >>>=20 >>> Not sure I get your point. You can have two different payload types = that map to the same payload format in a single RTP session, since >>> you can always distinguish what payload format is intended. You = can't have the same payload type mapping to two different payload=20 >>> formats in a single RTP session, since you can't then infer what = payload format was meant.=20 >>=20 >> Please not that both PTs map to the SAME payload format :) >=20 >=20 > I thought I addressed that in my reply. >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From christer.holmberg@ericsson.com Mon May 27 07:28:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEC921F901A for ; Mon, 27 May 2013 07:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZxfKq6XbeEG for ; Mon, 27 May 2013 07:28:24 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9B98E21F920B for ; Mon, 27 May 2013 07:28:23 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-8d-51a36d86caaf Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 86.2E.06701.68D63A15; Mon, 27 May 2013 16:28:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Mon, 27 May 2013 16:28:22 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions Thread-Index: Ac5YdJNWNYfYqobOTueV815jNgS21wCWRNCAAAYVf+E= Date: Mon, 27 May 2013 14:28:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C379AEC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C377967@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvrW5b7uJAg63f9C06JrNZTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgytjw4jFbwXzRiuaTC1kbGI8IdDFyckgImEh0 PLnKDGGLSVy4t56ti5GLQ0jgMKPE/rUtrCAJIYEljBLXXtR0MXJwsAlYSHT/0wYJiwgYSjTt mccEEmYWUJe4ujgIJCwsYC9x818/M0SJg8S044vZIWwriR8n1oCVswioSryf7wwS5hXwlei+ /JgJYmsfo8SDw8/YQBKcQIljbRMZQWxGoNO+nwLp5QRaJS5x68l8JoiTBSSW7DkPdb6oxMvH /1ghbEWJj6/2MULUG0i8PzefGcLWlli28DUzxGJBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCR ZRUje25iZk56ufkmRmB0HNzy22AH46b7YocYpTlYlMR59XkXBwoJpCeWpGanphakFsUXleak Fh9iZOLglGpgFHivG+zEUPNi1qK9Wb2lTMHbXT3arB9bnhRdtMrmSsAd7qA83+TjYoLPFt7i FP65JCxl8ZcFXK5zQ+L2yPLNuuFpe1nvf0KCW7Og4tQI01s897STLp1a+/nunEOfPnyam/7f 9IQHj8n3t8dOiiovcu3i/yBXyuHwaPOkOdzWpimxjw6n7fe6rMRSnJFoqMVcVJwIAE3u2fZc AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 14:28:29 -0000 Hi, > 4 and 5 are very confusing and do not match the notes I had from the call= . I'm pretty sure I disagree with both of them. > > From a requirement point of view, I think it is very important that the a= nswer be able to reject any m-line by setting it's port to zero. Forget about 5 (at least for now) - I probably mixed some things up. My take from the meeting is that there was an agreement on 4. But, if you disagree with 4, which port do you think the offerer shall use = for receiving media? It cannot use the "bundle port", as the answerer remov= ed the m- line from the bundle group. Regards, Christer On May 24, 2013, at 6:32 AM, Christer Holmberg wrote: > Hi, > > At the interim meeting yesterday, we agreed on some restrictions regardin= g creating SDP answers containing bundle group(s). > > Note that the restrictions 1-3 are simply alignments with RFC 5888, and a= re listed simply for clarification purpose. Restrictions 4 is BUNDLE specif= ic. Restriction 5 is also alignment with RFC 5888, as m- lines with port ze= ro are not allowed within groups, but we will need some clarification text = saying that a new offer will have to be sent in order to remove a stream (e= ither from a bundle group, or completely from the session). > > (Note that the text below is not necessarily the wording that will go int= o the draft) > > In an SDP answer: > 1) a BUNDLE group MUST NOT be created, unless it was included in the= associated offer > 2) an m- line MUST NOT be added to a BUNDLE group, unless it was inc= luded in a BUNDLE group in the associated offer > 3) an m- line MUST NOT be added to another BUNDLE group than the gro= up in which was included in the associated offer > 4) an m- line MUST NOT be removed from a BUNDLE group if, in the ass= ociated offer, an identical port number was indicated for all m- lines in a= BUNDLE group > 5) an m- line MUST NOT be rejected if, in the associated offer, an i= dentical port number was indicated for all m- lines in a BUNDLE group > > > Note that there is also a discussion regarding bundle offers, e.g. when r= estrictions when adding new m- lines to a bundle. Based on the outcome of t= hat, there may be some additional answer restrictions, e.g. regarding the c= hange of bundle transport parameters. But, let=92s deal with that in the of= fer thread. > > So, if anyone OBJECTS to the restrictions above, please indicate so. > > Regards, > > Christer > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon May 27 07:33:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10C221F9617 for ; Mon, 27 May 2013 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.364 X-Spam-Level: X-Spam-Status: No, score=-5.364 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_47=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iU-Mzv03ferJ for ; Mon, 27 May 2013 07:33:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A821F93EC for ; Mon, 27 May 2013 07:33:40 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-c4-51a36ec315d6 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 23.DE.06701.3CE63A15; Mon, 27 May 2013 16:33:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Mon, 27 May 2013 16:33:39 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between Thread-Index: Ac5YZ89eNSNKdC6FQhCoA7qw0p8XLAAE3h6AAJTS/oAABfqb0Q== Date: Mon, 27 May 2013 14:33:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C379AFB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3777C9@ESESSMB209.ericsson.se> <519F7ADF.1010909@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.18] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre6RvMWBBtsmc1p0TGazmLr8MYvF ig0HWB2YPf6+/8DkMeX3RlaPJUt+MgUwR3HZpKTmZJalFunbJXBlXF3+m6Xgs1TF0kkbmRoY e0S7GDk5JARMJL6/PckEYYtJXLi3nq2LkYtDSOAwo8TvtfMZIZwljBK393xg7WLk4GATsJDo /qcN0iAiECnxfuF+dpAws4C6xNXFQSCmsECyxJYP+RAVKRLHF99ihbCdJKatWc8OYrMIqErc efmHEcTmFfCV2LpqChPEpg2MEv/PrQJr4ARKzPy9mhnEZgS67fupNWB3MguIS9x6Mh/qZgGJ JXvOM0PYohIvH/9jhbAVJT6+2scIUW8g8f7cfGYIW1ti2cLXzBCLBSVOznzCMoFRbBaSsbOQ tMxC0jILScsCRpZVjOy5iZk56eXmmxiBMXNwy2+DHYyb7osdYpTmYFES59XnXRwoJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgXHD7bx7/c1L7m4/3q+YrHQj8PnaF6/y9OSWan+eOGXbmtzT phXyysp+Aiu2fDbzCljG9E+2rXBeRcaUlC9dDpK+ek+bptvo5yYatGxiDLt1ykVP/vn0TyLH Q/W9Y2WeGC+2Y+5mbC5TtTOP1HgtXJ0u8fT+lNmGZyYwMprPX3oo1ibktXz3TiWW4oxEQy3m ouJEAODenyVnAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 14:33:46 -0000 Hi, >I think a agree with Paul's text but I read it as almost the opposite of w= hat you wrote. We meant the same thing: the bundle port is the first mid value in the SDP = group:BUNDLE attribute, and the first mid value in the SDP group:BUNDLE att= ribute must not represent a zero port m- line. Paul talked about "the first mid representing a non-zero m- line", while I = talk about having a rule saying that "the first mid must not represent a ze= ro m- line to begin with" > I think some examples would help There will be lots of them :) > So if the offer has 3 m-lines with A,B, C in a bundle with ports 1,2,3. I= t is fine for the answer to put m-lines A and B in a bundle both using port= 1 but then have C outside the bundle using port 3. Do have this right? Wou= ld a detail example help ? Yes, as long as the offer contains DIFFERENT ports, it is allowed to leave = C outside. But, if the offer contains IDENTICAL ports, it is not allowed to leave C ou= tside, because there would be no "fallback" port for C. That is what rule #= 4, which you are pretty sure you disagree with, says :) Regards, Christer On May 24, 2013, at 8:36 AM, Paul Kyzivat wrote: > I agree with the sense of what you state below. > I have some nits with the words you use. > > On 5/24/13 6:28 AM, Christer Holmberg wrote: >> Hi, >> >> At the interim yesterday, we agreed that an answerer MUST always include >> identical ports* (usage of port zero within a bundle is a separate >> topic) for all m- lines within an bundle group. >> >> If the answerer wants to use different ports* for some/all m- lines, it >> MUST NOT include those m- lines in a bundle group > > OK so far. But: > >> (if they already are >> in a bundle group, a separate offer is needed to remove them). > > This depends on what you mean by "already in a bundle group". > Certainly they are already in a bundle group in the offer, so presumably = that is not what you mean. > > I presume you mean that they were already in a bundle group in the prior = O/A. > > I think this can be stated more clearly. How about: > > The answer to an offer containing a bundle group may remove an m-line fro= m the bundle group if (and only if) the address/port of the m-line in the o= ffer is distinct from the address/port of all the other m-lines in the offe= red bundle group. When doing so it must supply a unique address/port for th= at m-line in the answer. > > Thanks, > Paul > >> WHAT IT MEANS: There is no way for an answerer to tell that the offerer, >> for certain m- lines, can use the same port*, eventhough the answer will >> use separate ports*. >> >> I will work on some actual text proposal later, but please indicate if >> you OBJECT to this approach in general. >> >> Regards, >> >> Christer >> >> NOTE: =93port=94 =3D port:address combination =96 we are working on comi= ng up >> with better terminology J >> >> >> >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Mon May 27 08:48:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA1321F90FD for ; Mon, 27 May 2013 08:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdafept71zkX for ; Mon, 27 May 2013 08:47:56 -0700 (PDT) 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 5009021F8F87 for ; Mon, 27 May 2013 08:47:56 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta07.westchester.pa.mail.comcast.net with comcast id h3hE1l0071ap0As573nvwX; Mon, 27 May 2013 15:47:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id h3nv1l00M3ZTu2S3i3nvb2; Mon, 27 May 2013 15:47:55 +0000 Message-ID: <51A3802A.1090203@alum.mit.edu> Date: Mon, 27 May 2013 11:47:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> <519E8CA6.1090009@alum.mit.edu> In-Reply-To: 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=1369669675; bh=4JMqZY7sx5HITz5jH5d1SckWIcM2Ec0c55g+lboOpRs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y7alsuurUndAEeE/8IrDXDhs4OWTNZxg1GKjQaAkdfOrzKzPQ9rn2Xd4nkh6/NKFW MU4KxvbleiMxShWRk7bCne0BP9+h7/iRfACWwHNJCIJxQsLcqZnQDdRKkl1cp4w+77 CHAZlP0ezEGMfxfR8vB819JgzKHSJHuQDhyUnoUiBmbq39406AQTc8MXYR6GCqCF4H CwJDyn6YOFoyZe517gW6dZsTHp17eSA4MSl39jNMssUGXWVCqNetB1yDSNssnvBycD sArId2Vb2+CeskwdfQDOP7xz2mFROlEnm1IOvv0SgxKCYm3vlLhrRZMpXgFqDAh2zc RWqIWF/EljV1w== Cc: "Cullen Jennings \(fluffy\)" , Christer Holmberg , mmusic Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 15:48:02 -0000 On 5/23/13 8:14 PM, Martin Thomson wrote: > On 23 May 2013 14:39, Paul Kyzivat wrote: >> I am pretty strongly opposed to restricting how one can recycle m-lines. >> IMO this is a pretty basic and fundamental mechanism. > > What I'm suggesting would permit recycling(*). However, if you are > amending a session (as opposed to throwing it out entirely and > starting over), then I would rather that you cannot (I suggest MUST > NOT) change the BUNDLE affiliation of an m-line. I disagree with this. > This is - of course > - only possible if you permit rejected m-lines to remain in a group. > > This really goes back to the whole BUNDLE negotiation model. If a > line is tentatively part of a BUNDLE group in the first exchange, > confirmed in the second, do we permit splitting, reassignment, etc... > in subsequent exchanges? Yes, I think we do. IMO the following are some basic principles that ought to hold: 1) we can't allow an accepted m-line to be removed from a bundle while it shares an address/port with the bundle. We've settled that. 2) it should be possible to remove non-zero-port m-lines from a bundle offer, because the recipient needs to put them on separate addresses from the bundle. 3) There needs to be a way to handle the case where an answerer can't handle all the m-lines in a bundle offer as a single bundle, but could handle them as multiple bundles. I've proposed that this could be handled by refusing some of the m-lines in the bundle, and also removing them from the bundle. Then making a new offer that includes those m-lines in a new bundle. Removing the refused m-lines from the bundle could be handled at the time of rejection (the answer), or at the time of the new offer. I see no particular reason to prefer or legislate one way or the other. 4) In (3) I was thinking of a starting point where splitting occurred at the time of the initial offer for the bundle. The situation is a little different if the goal is to split an operational bundle, where the m-lines being split out already share an address/port with the bundle. (This is a less compelling case, but there are probably some reasons for it.) I see several approaches to this: 4a) new O/A that removes the m-lines from the old bundle and gives them unique address/ports. Later, another O/A that puts those m-lines into a new bundle. 4b) new O/A that rejects the m-lines and removes them from the old bundle. Later, another O/A that puts those m-lines into a new bundle. 4c) new O/A that rejects the m-lines, leaving them in the bundle. Later, another O/A that removes the rejected m-lines from the bundle. Later yet, another O/A that offers addresses for those m-lines and puts them into a new bundle. 4d) consolidate two steps in 4c: new O/A that rejects the m-lines, leaving them in the bundle. Later, another O/A that offers addresses for those m-lines and puts them into a new bundle. 4e) further consolidation: new O/A that removes previously active m-lines that had been previously bundled from their old bundle, gives them unique address/port values, and puts them into a new bundle. There are basic primitives that show up above, that IMO ought to be ok: A) reject an m-line (port zero) in an answer and remove from bundle. (This is basic behavior of 5888. Even if we relax it and allow rejected m-lines in groups we should still permit this.) B) in a subsequent offer, reject (port zero) an m-line that was previously active and bundled, and remove it from the bundle. (This also seems to be basic behavior from 5888.) C) in a subsequent offer, reject (port zero) an m-line that was previously active and bundled, but leave the m-line in the bundle. (Only if 5888 is extended to allow rejected m-lines in bundles.) D) in a subsequent offer, remove a previously rejected m-line from a previously signaled bundle. (Only if 5888 is extended to allow rejected m-lines in bundles.) E) in an answer, remove a zero port m-line in the offered bundle from the bundle in the answer. F) in a subsequent offer, reuse an m-line that was rejected in the prior offer or answer, and was previously not in any bundle. Use this m-line for any purpose where a totally new m-line may be used. (This includes adding to an existing bundle, or proposing a new bundle.) G) in a subsequent offer, reuse an m-line that was rejected in a prior offer or answer, and was previously in a bundle, as a new active m-line within the bundle. (According to the same rules as for adding an entirely new m-line to the bundle.) H) Any change that can be done with two O/A exchanges using above rules, should be able to be done in one O/A exchange if the outcome of the first is deterministic. (Some examples: B = C+D Replace C+G with an offer that replaces a previously active m-line within a bundle with a proposal for a new m-line, also in the bundle, but otherwise entirely new. Replace an active m-line within a bundle with an unbundled m-line with a different address/port. (Skipping B.) If we are going to revise 5888 so that we can keep rejected m-lines in bundle groups, then we must clearly define the distinction between a rejected m-line that is bundled from one that is not. IMO the distinction is that an unbundled one has *no* significance other than as a placeholder required by the O/A requirement to preserve the ordering and numbering of m-lines. Including one in an offer means that this m-line is desired if and only if the bundle is accepted in the answer. In that case, a rejected m-line in the bundle in an answer agrees that. Then a cleanup O/A will put the bundle port into that m-line, so that rejected m-lines would only be in bundles in a transient way. Thanks, Paul > Or, do we permit the movement in and out of BUNGLE groups for any > m-line? If I want to migrate off one BUNDLE and to another, do I > first reject the line and remove it from the BUNDLE group (exchange 1) > and then re-animate it with a new BUNDLE group (exchange 2)? > From pkyzivat@alum.mit.edu Mon May 27 08:55:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBC021F96C5 for ; Mon, 27 May 2013 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs3VxWcXgQU5 for ; Mon, 27 May 2013 08:55:16 -0700 (PDT) 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 4594A21F8ED8 for ; Mon, 27 May 2013 08:55:15 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id h3mq1l00217dt5G543vF9V; Mon, 27 May 2013 15:55:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id h3vF1l00F3ZTu2S3Z3vF9F; Mon, 27 May 2013 15:55:15 +0000 Message-ID: <51A381E2.9040203@alum.mit.edu> Date: Mon, 27 May 2013 11:55:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bernard Aboba References: <519E5F54.3000806@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=1369670115; bh=Z8xaOhN7CRKzNfeDOTEvDGRIb+aZHhxFj8GkqLqm2DQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aQ6RQaoxiTswQHg6+ZgeyPOLZ9Dl9aeycfy5V1t3I4Mo5DrcL2w+XJDU9WnqZmO5a pQBeKnb+qnKokaTlMrTtBHQu3kErhhosCTt6A2tE+vs5aTPlKrLwzX0g7AfNd0mquW n03jSkceVJqLB6NEe1WA7+ZWn0tY8JDsvZO+q0zwibfJTfH97Phe5JdiF3Gq7XZ8CZ /5cbKoVb/xcxzGFVzu+NmGSv38kgtxru8FdH9LDb1RQBybtHoAjYkM9WBpKSt4mM2B pWqkWx7KdTLP2tBmH3WyUZl2mOk4Qs8YovEAqPF0Jda3pvElZgf6CWcR5e+iYHt+ag i5lzWmeWjykHg== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 15:55:23 -0000 On 5/24/13 3:34 PM, Bernard Aboba wrote: > On May 23, 2013, at 11:50, "Paul Kyzivat" wrote: > >> After all the discussion in the meeting today, I thought it would be good to unwind all the indenting and start a new thread on one issue that is part of the "demux" problem: >> >> IMO the following should obviously be a truism. I want to know if all agree. >> >> If an O/A exchange negotiates a bundle with multiple m-lines, >> then attributes in those m-lines and the associated media sections must provide sufficient information to associate each incoming packet on the 5-tuple to exactly *one* of those m-lines. > > [BA] I would argue that this statement needs to be true for *both* RTP and RTCP packets. I don't know enough to comment on that, but it sounds right. >> (If it doesn't, then there was no point in including those m-lines in the bundle.) >> >> For instance a=ssrc, if unique to one m-line, can bind packets with that SSRC to the m-line. > > [BA] That is only necessary for RTP (and RTCP) if the PT is not unique to an m line; otherwise PT demux is sufficient for RTP. For RTCP the situation is more complicated. If we only need to bind RTCP packets from RTP senders, we can build an SSRC to PT to m line table dynamically, based on SSRCs and PTs seen in RTP packets. However if we get a RR from a source that has not yet sent, we can't map it to an m line without a=ssrc if BUNDLE is in use. I discussed that elsewhere. There are several features that, when present in the SDP and in the packet, can be used to bind the packet to the m-line. The PT has the advantage that it is always present in RTP m-lines, and is always present in RTP packets. But as you mention, I guess it is not present in RTCP packets. I'll also note that PT doesn't help when bundling non-rtp m-lines, such as DTLS/SCTP. >> If a property such as SSRC is used this way, then there is the possibility of receiving packets that don't match any of the m-lines. I think we ought to address that, by defining some syntax to specify what to do with packets that don't match any m-line. This might be to specify one m-line as the default, or that packets that don't match be discarded. > > [BA] I do not believe that a default m line makes sense for RTCP packets that can't be bound to an m line. Discard, while undesirable, seems like the only option. However this could create problems in diagnostics in some cases. Again, I'll defer to others that know more about this. Thanks, Paul From pkyzivat@alum.mit.edu Mon May 27 09:07:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899E821F96E0 for ; Mon, 27 May 2013 09:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bSg0wn1zA6y for ; Mon, 27 May 2013 09:07:31 -0700 (PDT) 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 A684021F96C6 for ; Mon, 27 May 2013 09:07:30 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id h0og1l0061GhbT85447Vp4; Mon, 27 May 2013 16:07:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id h47V1l00q3ZTu2S3T47VhD; Mon, 27 May 2013 16:07:29 +0000 Message-ID: <51A384C0.4010600@alum.mit.edu> Date: Mon, 27 May 2013 12:07:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <519E5F54.3000806@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C379542@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C379542@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369670849; bh=FYiQLaY8gX4bVG9F3wFMzr/ohxQyjP2ZYPDYKq2V1lk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Hgtqg1TZsKxmXrBxCXmTaCcV8fxNTHYK6ONz7GFLrloGlo6viW+Wymn+EEI31b/Zs 90AH3Rd44WtvgsK+lJV7sn7TYij4SGIFHi+ZmJ7SDxWlQAVUXd1sba9CNHGH8KfWtD C4mCoZ3vn5bRTjijg6XjM7A1wem6N5gYUiy14hycSOHlZGQspfPZwueUTnE2/fnBM/ 8v1TvoqAcAqI69wCBDkGRdiXg6ehwpaCqvpRYztPYrFl80aoCFo7oCN6U+tL7dzLWt v/MdnlufwSBBiBgqHr499KwpJ4u+A89pwm+tagXqgvPoffYxVQYmi1ls7JyuU26lde NXW2eiO9F07pw== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 16:07:35 -0000 On 5/27/13 6:01 AM, Christer Holmberg wrote: > Hi, > > I am skeptical towards specifying a default m- line as well, as the media type may not even match :) That problem can occur even without defaults: E.g., I could put an a=ssrc with a video m-line, while it turns out that the packets with that ssrc are audio packets. This needs to be part of the matching process. All of the specified things must match. That does mean that it should be possible to specify a=ssrc:* for both an audio and a video m-line. (And for any other top level media types.) Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: 24. toukokuuta 2013 22:35 > To: Paul Kyzivat > Cc: IETF MMUSIC WG > Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle > > On May 23, 2013, at 11:50, "Paul Kyzivat" wrote: > >> After all the discussion in the meeting today, I thought it would be good to unwind all the indenting and start a new thread on one issue that is part of the "demux" problem: >> >> IMO the following should obviously be a truism. I want to know if all agree. >> >> If an O/A exchange negotiates a bundle with multiple m-lines, then >> attributes in those m-lines and the associated media sections must provide sufficient information to associate each incoming packet on the 5-tuple to exactly *one* of those m-lines. > > [BA] I would argue that this statement needs to be true for *both* RTP and RTCP packets. > >> (If it doesn't, then there was no point in including those m-lines in >> the bundle.) >> >> For instance a=ssrc, if unique to one m-line, can bind packets with that SSRC to the m-line. > > [BA] That is only necessary for RTP (and RTCP) if the PT is not unique to an m line; otherwise PT demux is sufficient for RTP. For RTCP the situation is more complicated. If we only need to bind RTCP packets from RTP senders, we can build an SSRC to PT to m line table dynamically, based on SSRCs and PTs seen in RTP packets. However if we get a RR from a source that has not yet sent, we can't map it to an m line without a=ssrc if BUNDLE is in use. > >> If a property such as SSRC is used this way, then there is the possibility of receiving packets that don't match any of the m-lines. I think we ought to address that, by defining some syntax to specify what to do with packets that don't match any m-line. This might be to specify one m-line as the default, or that packets that don't match be discarded. > > [BA] I do not believe that a default m line makes sense for RTCP packets that can't be bound to an m line. Discard, while undesirable, seems like the only option. However this could create problems in diagnostics in some cases. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From fluffy@cisco.com Mon May 27 09:11:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCF121F8FCB for ; Mon, 27 May 2013 09:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.099 X-Spam-Level: X-Spam-Status: No, score=-110.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3599aFQp8PS for ; Mon, 27 May 2013 09:11:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD4921F8FED for ; Mon, 27 May 2013 09:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=310; q=dns/txt; s=iport; t=1369671068; x=1370880668; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rbA+xwF2+rVe864ZS4sKyEUnrzK+XNNzaTlHxpA8ZEo=; b=BJLvQBIarM7qZqyLRvIbtivaSkrxrWW7uBgAAAn8rqufHSP20OQ5y+Hx mRcq7HAQzSsd8A6/SztdscwJswgd5Ajl9aplR+IzXX8bMATmDBAQzzJJV +eS1x8i4NmpNCyfbCxe0TxjmpjxIXCSmoyhUEZDxV8agKA4DM/zv4Cnks 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAAyFo1GtJXHB/2dsb2JhbABagwiDJL8RgQYWdIIjAQEBAwF5BQsCAQgiJDIlAQEEDgUIh38GvU2OagIxB4JzYQOoe4FYgTeCJw X-IronPort-AV: E=Sophos;i="4.87,752,1363132800"; d="scan'208";a="215413970" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 27 May 2013 16:11:07 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4RGB77C008618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 16:11:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 27 May 2013 11:11:07 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between Thread-Index: Ac5YZ89eNSNKdC6FQhCoA7qw0p8XLAAE3h6AAJTS/oAABfqb0QAODaEA Date: Mon, 27 May 2013 16:10:25 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C3777C9@ESESSMB209.ericsson.se> <519F7ADF.1010909@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C379AFB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C379AFB@ESESSMB209.ericsson.se> 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: <3226E08CBFFE2543A7E6F40AAE361612@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 16:11:13 -0000 On May 27, 2013, at 8:33 AM, Christer Holmberg wrote: > We meant the same thing: the bundle port is the first mid value in the SD= P group:BUNDLE attribute, and the first mid value in the SDP group:BUNDLE a= ttribute must not represent a zero port m- line. +1=20 From csp@csperkins.org Mon May 27 09:15:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE12F21F96CD for ; Mon, 27 May 2013 09:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeinMWw55x6g for ; Mon, 27 May 2013 09:15:16 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 50EDA21F9675 for ; Mon, 27 May 2013 09:15:16 -0700 (PDT) Received: from [81.187.2.149] (port=41810 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh04e-0002Gj-8p; Mon, 27 May 2013 17:15:04 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51A381E2.9040203@alum.mit.edu> Date: Mon, 27 May 2013 17:15:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <519E5F54.3000806@alum.mit.edu> <51A381E2.9040203@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 16:15:22 -0000 On 27 May 2013, at 16:55, Paul Kyzivat wrote: > On 5/24/13 3:34 PM, Bernard Aboba wrote: >> On May 23, 2013, at 11:50, "Paul Kyzivat" = wrote: >>=20 >>> After all the discussion in the meeting today, I thought it would be = good to unwind all the indenting and start a new thread on one issue = that is part of the "demux" problem: >>>=20 >>> IMO the following should obviously be a truism. I want to know if = all agree. >>>=20 >>> If an O/A exchange negotiates a bundle with multiple m-lines, >>> then attributes in those m-lines and the associated media sections = must provide sufficient information to associate each incoming packet on = the 5-tuple to exactly *one* of those m-lines. >>=20 >> [BA] I would argue that this statement needs to be true for *both* = RTP and RTCP packets. >=20 > I don't know enough to comment on that, but it sounds right. >=20 >>> (If it doesn't, then there was no point in including those m-lines = in the bundle.) >>>=20 >>> For instance a=3Dssrc, if unique to one m-line, can bind packets = with that SSRC to the m-line. >>=20 >> [BA] That is only necessary for RTP (and RTCP) if the PT is not = unique to an m line; otherwise PT demux is sufficient for RTP. For RTCP = the situation is more complicated. If we only need to bind RTCP packets = from RTP senders, we can build an SSRC to PT to m line table = dynamically, based on SSRCs and PTs seen in RTP packets. However if we = get a RR from a source that has not yet sent, we can't map it to an m = line without a=3Dssrc if BUNDLE is in use. >=20 > I discussed that elsewhere. There are several features that, when = present in the SDP and in the packet, can be used to bind the packet to = the m-line. The PT has the advantage that it is always present in RTP = m-lines, and is always present in RTP packets. But as you mention, I = guess it is not present in RTCP packets. RTCP operates at a different level, so it's not clear why it needs to be = bound to an m=3D line. Use the SSRC to group related RTP and RTCP = packets according to source, and match them to a de-jitter buffer and = the state for RTCP processing. Use the PT to match those sources with = the payload format, m=3D line and the corresponding decoding and = rendering context. > I'll also note that PT doesn't help when bundling non-rtp m-lines, = such as DTLS/SCTP. >=20 >>> If a property such as SSRC is used this way, then there is the = possibility of receiving packets that don't match any of the m-lines. I = think we ought to address that, by defining some syntax to specify what = to do with packets that don't match any m-line. This might be to specify = one m-line as the default, or that packets that don't match be = discarded. >>=20 >> [BA] I do not believe that a default m line makes sense for RTCP = packets that can't be bound to an m line. Discard, while undesirable, = seems like the only option. However this could create problems in = diagnostics in some cases. >=20 > Again, I'll defer to others that know more about this. Match the RTCP to the RTP based on the SSRC, and process it. There is no = need to discard the RTCP in this case. Yes, you need to define what to do about an RTP source that doesn't = match to an m=3D line, but that's at a higher-layer than the RTP = demultiplexing. The issue of if/how/where an RTP source is decoded = should be separate to the issue of how the RTP and RTCP packets = comprising that source are demultiplexed, fed to a de-jitter buffer, = reported in RTCP, etc.=20 --=20 Colin Perkins http://csperkins.org/ From partha@parthasarathi.co.in Mon May 27 09:19:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299AB21F9677 for ; Mon, 27 May 2013 09:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.765 X-Spam-Level: X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxxZmIcTqS3U for ; Mon, 27 May 2013 09:19:50 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id CF4CD21F9691 for ; Mon, 27 May 2013 09:19:50 -0700 (PDT) Received: from userPC (unknown [122.179.80.84]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 6DE3E6480AF; Mon, 27 May 2013 16:19:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1369671590; bh=fQlzDTo7TUYN1pXtD/Ebh9bFbjEszBdhEod7LFW2NJM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=c6LczVcr1X2nKsXE4mfPXb2hN3ne8e139majQo0fHRWwS1aKQKedLigOuT58mSoq9 lepTmz7VTVrPSGgoEVLB7lcuhi5thDivbOLtWGcAQ5svyZEl9o5MmfEP23G2NQ9Yzk uR61mqQyeysh1Oa70DquhMxq4j6yWvZEWJC/IvDs= From: "Parthasarathi R" To: =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , References: <20130520161935.17435.91264.idtracker@ietfa.amsl.com> <51A28FCC.9010401@ericsson.com> In-Reply-To: <51A28FCC.9010401@ericsson.com> Date: Mon, 27 May 2013 21:49:41 +0530 Message-ID: <001501ce5af6$01c845c0$0558d140$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5aYlKiUuvBD7tQQCOj8p8Nq+AjeQAk0EAw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0209.51A387A6.0025, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: 'mmusic' Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 16:19:55 -0000 Ari, Thank for your comments. We'll incorporate all the comments in the next revision. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Ari Ker=E4nen > Sent: Monday, May 27, 2013 4:12 AM > To: draft-ietf-mmusic-sdp-g723-g729@tools.ietf.org > Cc: mmusic > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729- > 01.txt >=20 > Hi, >=20 > There seems to be one (recurring) typo in the examples: >=20 > 4.1. Offer with G279 annexb=3Dyes and answer with G279 annexb=3Dno >=20 > [Offer with G279 annexb=3Dyes] >=20 > s/G279/G729/g > (same in the sections 4.2 & 4.3) >=20 >=20 > Also, the following sentence in section 3 seems a bit hard to parse: >=20 > Based on the above, it is best to not use comfort noise frames if > the > SDP offer or answer indicates no support for it. >=20 > Maybe rather say "[...] offer or answer indicates that comfort noise = is > not supported", if that's what you mean. >=20 >=20 > Cheers, > Ari > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From partha@parthasarathi.co.in Mon May 27 09:28:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0514721F9675 for ; Mon, 27 May 2013 09:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kM8TCwtoVYp for ; Mon, 27 May 2013 09:28:15 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id ADDDF21F9007 for ; Mon, 27 May 2013 09:28:15 -0700 (PDT) Received: from userPC (unknown [122.179.80.84]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 44F06648098; Mon, 27 May 2013 16:28:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1369672095; bh=c49WvOAQfy4wd7lKJ3DT0H9ic55F+YS9+rqjJT2PUv4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=By/uOoT4bhdFv14dnX2hqXg1p3h4D0BJI2e3Txy6DThcf9uWC0StHExT677nnl3UJ 48Tx2BAoUvZb15IqU2VOqw5EHnx6KkKJmF1yQw5Lqn0Dl1SgH0VphN8bX4uVDKPGYj z2m9TR7e56R4zQCn5Z0XI0zbU4MuDU6a8sm3I8p0= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Dale R. Worley'" , "'Paul Kyzivat'" References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> <201305232206.r4NM6l5C5338062@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C377609@ESESSMB209.ericsson.se> <004d01ce5a08$a3193720$e94ba560$@co.in> <7594FB04B1934943A5C02806D1A2204B1C37943B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37943B@ESESSMB209.ericsson.se> Date: Mon, 27 May 2013 21:58:06 +0530 Message-ID: <001701ce5af7$2ee19240$8ca4b6c0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOV9u/fklHpYO4tka0o0wHa47jypkTW/u2gACjmhCAA1ChYIABY7GggACIl4A= Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.51A3899F.0095, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 16:28:20 -0000 Christer, My intention of the below mail is to say that the offer/answer interaction issues created by BUNDLE for forking and it has to be documented. Also, it is not implementation issue but more of protocol design issue. Please read inline for more comments. Thanks Partha > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, May 27, 2013 1:44 PM > To: Parthasarathi R; 'Dale R. Worley'; 'Paul Kyzivat' > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] When a bundle offer is forked > > Hi, > > >Forking has to be seen with the RTP role (endpoint, translator, mixer) > as the offer/answer exchange varies drastically for each RTP role. SIP > >forking with RTP endpoint issues are explained as part of Sec 3.1 of > RFC 3960. One of the complexity introduced as part of BUNDLE is to have > >two offer/answer before consolidating. The offer/answer interaction > between SIP forking with RTP endpoint and BUNDLE has to be mentioned. > I'll explain with the SIP serial forking with RTP endpoint scenario for > more clarity > > > >1) INVITE with SDP having BUNDLE offer and different port in each m- > line is send out from UAC > >2) 183 with SDP and BUNDLE support is received from UAS1 > >3) UPDATE with SDP having BUNDLE offer and single port in each m-line > is send towards UAS1 after completing PRACK & 200 > >4) 183 with SDP and BUNDLE support is received from UAS2 > > > >Here at Step 4, it is not possible for UAC to "mute" UAS1 as one > another OFFER is initiated already at Step 3 and BUNDLE forces to > "mute" the answer > >UAS2. This limitation has to be mentioned as part of BUNDLE. Please > let me know your opinion on this. > > I don't understand. The UAC can: > > 1) wait for the UPDATE answer from UAS1, and then send a new "mute" > UPDATE; or > 2) send a BYE to UAS1, and terminate the whole early dialog. > UAC choice is restricted to the above choice because of BUNDLE. This has to be mentioned in the document > Also, BUNDLE is not the only SIP/SDP mechanism which uses multiple > Offer/Answer transactions. > I agree with you that multiple offer/answer transaction is not just by BUNDLE. Please indicate whether any document mention the issues related forking with multiple offer/answer. > Regards, > > Christer > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Friday, May 24, 2013 1:55 PM > > To: Dale R. Worley; Paul Kyzivat > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] When a bundle offer is forked > > > > Hi, > > > > I agree with Dale. Each early dialog is handled separately. > > > > From a standards perspective, I don't think we need to say much about > > forking in BUNDLE, other than maybe some general words that it may > > happen. > > > > Then, whether it becomes tricky to implement, e.g. if one early leg > > uses BUNDLE and another doesn't, is another issue. But, as SIP has > > mechanisms to terminate early dialogs you don't like etc, I see this > > as a pure implementation issue. > > > > Regards, > > > > Christer > > > > > > > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Dale R. Worley > > Sent: 24. toukokuuta 2013 1:07 > > To: Paul Kyzivat > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] When a bundle offer is forked > > > > > From: Paul Kyzivat > > > > > > On 5/23/13 6:35 AM, Emil Ivov wrote: > > > > > > > In case a bundle offer gets forked and various answers ... > > > > > > I trimmed everything else out of Emil's reply, and changed to > > subject, > > > because this is a whole different can of worms! > > > > > > I think we must acknowledge that this *can* happen, though it is a > > low > > > probability event. It raises all sorts of ugly issues. A few: > > > > Is this actually complicated? That is, worse than is already the > case > > in SIP... > > > > My understanding is that in SIP (and this must be a SIP situation), > > each fork proceeds with completely independent state from all other > > forks. The forks happen to share sending/receiving ports, but the > > received packets can be demultiplexed to the correct fork based on > > their sending addresses. Of course, there are a range of obnoxious > > situations where you receive packets before you receive a SIP > response > > (SDP answer) that describes them, but that is true in non-bundled SIP > > as well. > > > > Dale > > _______________________________________________ > > 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 pkyzivat@alum.mit.edu Mon May 27 09:32:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F8721F96C2 for ; Mon, 27 May 2013 09:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPS6yOfDrI66 for ; Mon, 27 May 2013 09:32:38 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id E068B21F96B8 for ; Mon, 27 May 2013 09:32:37 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta14.westchester.pa.mail.comcast.net with comcast id h3BF1l0030QuhwU5E4YdWn; Mon, 27 May 2013 16:32:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id h4Yd1l00H3ZTu2S3N4YdJg; Mon, 27 May 2013 16:32:37 +0000 Message-ID: <51A38AA4.70309@alum.mit.edu> Date: Mon, 27 May 2013 12:32:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> <519F7DEB.2010809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3794F5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3794F5@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369672357; bh=D5QMiszVozjDeWL8DqSt7/qYQkJtvK4ThDoFYmaNNU0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QBPzEHhoKkTJXLi9jElH1bXpJ74lrcKrQ15aObJeWLV0Zk8SRvBQhx+HnpQn4olZ6 lgWpz5G64/aZ5qUhV1vZw5Rg+dSidO3V7Z4j/x3Ic3unlRY2C0xCf7Dl2feAs683OF mzBF7XJ0qzKXxu+iisMxShfOMalbO8F42D+6A6AuElZzLTmspdJy5gibczmdjHaVC8 U+uV9EY9MvNC8W3KLJ8GlbARLYt/ENTUz+nJGZvJpDufKOkvaD5zW4wHo3ZyzsjbDP k6DQGHfwtC16PvyrqUsozkBEHSU3b+WQ/aHpEnq5hiCmZ7cwV+hF1qgVjaDlfoPAb6 ixlJ7SbloOinA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 16:32:44 -0000 On 5/27/13 5:27 AM, Christer Holmberg wrote: > Hi, > >>> At the interim yesterday, we agreed to use the SDP BUNDLE group >>> attribute to indicate on which port bundled media will be sent. In an >>> SDP offer, the order of the attribute mid values can be used by the >>> offerer to indicate a "wish", but the first attribute mid value in the >>> answer indicates where the answerer will eventually send bundled media. >> >> This could be interpreted to mean the first a=mid value in the SDP. >> I'm sure you mean "the first mid value in the a=group:bundle" line. > > Yes. > >> Or perhaps "the first mid value in the bundle group" - assuming there is a definition that "bundle group" means an a=group:bundle line. > > In the draft "bundle group" means (or, at least is supposed to mean :) the bundle grouped m- lines, and in general I think it is better to explicitly mention the line/attribute. > >> This can be "future proofed" by saying that the first mid value in the bundle group in the answer that references an m-line with non-zero >> port value. I realize this adds nothing unless 5888 is revised to permit m-lines with zero port in a bundle group. But at least it will be ready for that, and harms nothing. > > I agree, but suggest a little different wording: by saying the first mid value in the group attribute MUST NOT represent a port zero m- line. I just want to be sure we're clear here. Are you saying that even if we relax 5888 so that we may have m-lines with port zero in a bundle group, that the *first* mid in the bundle group can't designate a zero port??? I guess that should always be possible as long as there is at least one with a non-zero port. Do we have a possibility, with ICE, that all the m-lines in the bundle will have zero port? (Because we are waiting for ICE to figure out the actual port.) Or are we going to use something else for that purpose? As long as there is no possibility of having a bundle where all the ports are zero then I'm ok with what you propose. Thanks, Paul From pkyzivat@alum.mit.edu Mon May 27 09:56:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53321F940B for ; Mon, 27 May 2013 09:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6v2z45ZdAmi for ; Mon, 27 May 2013 09:56:05 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1C321F90AC for ; Mon, 27 May 2013 09:56:05 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta12.westchester.pa.mail.comcast.net with comcast id h41J1l0021vXlb85C4w5Ao; Mon, 27 May 2013 16:56:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id h4w41l01T3ZTu2S3d4w5Hc; Mon, 27 May 2013 16:56:05 +0000 Message-ID: <51A39023.1070605@alum.mit.edu> Date: Mon, 27 May 2013 12:56:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> In-Reply-To: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> 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=1369673765; bh=H5ncAjxLNCDU+kITzdS6YLaTIqS/3gXg+IOysElGqyA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=i6kvsm0JdvKcWuDmhVsmMaPgG6EY2q86e0iOXSQh+b+4ZmDKsTd4AelVcrP6iyyyh S2FYOPc5fRBTv4qdL+7H35xryAyqHa81xkbecD9YT9XV29EA6jVYo84Kw8QE+55wi2 OCMqXLPhkBaCRMpSby0xv8CjDvu0x5w1zwDtFa5G6q/uJMSCMvx7z1eIhHDxeja7U5 gwYEQtmih/CpsrB1EFCVn0YqakUzhOJz/bEGFDBdOc5JqNUYVrLBizmk3Y/+E1OAA6 T8N5bvwv8pmkekLk7amyNqvOpfsDK6E13wnC/4ZpFidR48mVg7UMjQDhv/KzmH9lTC CWBqkxv+VlW8A== Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 16:56:10 -0000 Colin, As I suggested on another thread, ISTM that it should be possible to reuse the same PT to map to different payload formats in different m-lines of a bundle *if* there is some other characteristic declared in SDP and present in packets that can be used to associate the packet to one m-line. In that case, after picking the m-line, the mapping from PT to payload format for *that* m-line can be used. E.g., v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 a=group:bundle X Y m=audio 49170 RTP/AVP 96 a=mid:X a=ssrc:1111 cname:x@example.com a=rtpmap:96 AMR-WB/16000 m=audio 49172 RTP/AVP 96 a=mid:Y a=ssrc:2222 cname:y@example.com a=rtpmap:96 G7291/16000 Thanks, Paul On 5/27/13 8:29 AM, Colin Perkins wrote: > There were a number of comments in the call last week, and on the list, about unique payload types in BUNDLE. I'd like to explore this further. > > Case A: Within a single RTP session, I think we'd all agree that an offer that uses the same RTP payload type for two payload formats on a single m= line is problematic: > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.anywhere.com > s= > c=IN IP4 host.anywhere.com > t=0 0 > m=audio 49170 RTP/AVP 96 > a=rtpmap:96 AMR-WB/16000 > a=rtpmap:96 G7291/16000 > > If this were done the receiver would have no way of distinguishing what payload format is meant by payload type 96. Accordingly, unique payload formats need to be used for each payload format. > > Case B: If one were to use two separate m= lines on different ports, in the non-BUNDLE case, then the same RTP payload type can be reused without difficulty: > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.anywhere.com > s= > c=IN IP4 host.anywhere.com > t=0 0 > m=audio 49170 RTP/AVP 96 > a=rtpmap:96 AMR-WB/16000 > m=audio 49172 RTP/AVP 96 > a=rtpmap:96 G7291/16000 > > The implication is that there are two separate RTP sessions, which the receiver can distinguish based on the UDP port on which the packets are received. The mapping from RTP payload types to payload formats is done on a per-RTP session basis. > > Case C: This is when we BUNDLE several m= lines on a single UDP port. On the call last week, there seemed to be agreement that the m= lines in such a BUNDLE group comprise a single RTP session (it also matches the definition of an RTP session from RFC 3550: the packets go to a single destination and the m= lines share a single SSRC space). To me this would suggest that the RTP payload type values MUST be unique across the m= lines (or, if the same RTP payload type is used in different m= lines, it MUST map to an identical payload format). The reason is that everything runs over one UDP port, and if a single RTP payload type is mapped to different payload formats, there's no way to distinguish which payload format is meant. This is essentially the same as case A above. > > Given this, it's not clear to me that non-unique payload types make sense within a BUNDLE group. They work on different m= lines in the legacy case because those lines form different RTP sessions, and the RTP sessions can be used to scope the payload type to payload format mappings. I don't see that they work in BUNDLE, because there's a single RTP session, and so a single mapping from payload type to payload format. > From christer.holmberg@ericsson.com Mon May 27 10:16:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729F321F967D for ; Mon, 27 May 2013 10:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7TCoAR-ozvg for ; Mon, 27 May 2013 10:16:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4AACA21F9679 for ; Mon, 27 May 2013 10:16:26 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-f3-51a394e859c9 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 57.6F.28930.8E493A15; Mon, 27 May 2013 19:16:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Mon, 27 May 2013 19:16:24 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Thread-Index: Ac5Yevnd5lghFfM/QmuiU1fEkjXC+QAAh7mAAI+mEfAACtXEAAAFeb+C Date: Mon, 27 May 2013 17:16:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C379C4A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> <519F7DEB.2010809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3794F5@ESESSMB209.ericsson.se>, <51A38AA4.70309@alum.mit.edu> In-Reply-To: <51A38AA4.70309@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre7LKYsDDX4fY7aYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6Mj1d3shTsEK5YfP8hcwPjNP4uRk4OCQET iUX77rFD2GISF+6tZ+ti5OIQEjjMKHH+yHIWCGcJo8S1vgtAGQ4ONgELie5/2iCmiICGxKSt aiAms4C6xNXFQSBjhAWsJKYvmcYKYosIWEvcmN7OCGG7SXRNX80MYrMIqEp83XaZBcTmFfCV uDR3LRPEpouMEt/6roA1cApoSRxunw7WwAh02/dTa5hAbGYBcYlbT+YzQdwsILFkz3lmCFtU 4uXjf6wQtqJE+9MGRoh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjGKzkIydhaRlFpKWWUha FjCyrGJkz03MzEkvN9zECIyQg1t+6+5gPHVO5BCjNAeLkjivHu/iQCGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MYcG7PnXKp3oaHtr3sMXdVar2WDpXvZ64vMsJi3ie+ZE73myarRV+5aac qqvSP19OziN/prwT/6RitdrZKTx3x9yC8LIni+ycju/cVdDwurWz4eGtkyKrSsNeChQuNXn+ S1/ridwK6bybYo2G15hO/ziq6pb2/dqSxmi2l6Wvtyd90DVmPmOlxFKckWioxVxUnAgAUy7i S14CAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:16:36 -0000 Hi, >>>> At the interim yesterday, we agreed to use the SDP BUNDLE group >>>> attribute to indicate on which port bundled media will be sent. In an >>>> SDP offer, the order of the attribute mid values can be used by the >>>> offerer to indicate a "wish", but the first attribute mid value in the >>>> answer indicates where the answerer will eventually send bundled media= . >>> >>> This could be interpreted to mean the first a=3Dmid value in the SDP. >>> I'm sure you mean "the first mid value in the a=3Dgroup:bundle" line. >> >> Yes. >> >>> Or perhaps "the first mid value in the bundle group" - assuming there i= s a definition that "bundle group" means an a=3Dgroup:bundle line. >> >> In the draft "bundle group" means (or, at least is supposed to mean :) t= he bundle grouped m- lines, and in general I think it is better to explicit= ly mention the line/attribute. >> >>> This can be "future proofed" by saying that the first mid value in the = bundle group in the answer that references an m-line with non-zero >>> port value. I realize this adds nothing unless 5888 is revised to permi= t m-lines with zero port in a bundle group. But at least it will be ready f= or that, and harms nothing. >> >> I agree, but suggest a little different wording: by saying the first mid= value in the group attribute MUST NOT represent a port zero m- line. > > I just want to be sure we're clear here. > > Are you saying that even if we relax 5888 so that we may have m-lines > with port zero in a bundle group, that the *first* mid in the bundle > group can't designate a zero port??? Yes, for BUNDLE. It doesn't have to be a generic 5888 rule. > I guess that should always be possible as long as there is at least one > with a non-zero port. > > Do we have a possibility, with ICE, that all the m-lines in the bundle > will have zero port? (Because we are waiting for ICE to figure out the > actual port.) Or are we going to use something else for that purpose? > > As long as there is no possibility of having a bundle where all the > ports are zero then I'm ok with what you propose. I hear what you're saying. But, in that case saying "first non-zero mid" does not work either, does it= ? :) Another option is to also allow mids for zero-port m- lines to be first. A = first mid for a port zero m- line would mean that there is no port for bund= led media. Maybe there could be a use-case for that. Regards, Christer From christer.holmberg@ericsson.com Mon May 27 10:22:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BC821F966E for ; Mon, 27 May 2013 10:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hk60BuBkdqG for ; Mon, 27 May 2013 10:22:09 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70621F9626 for ; Mon, 27 May 2013 10:22:08 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-10-51a3963f243c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 78.06.31782.F3693A15; Mon, 27 May 2013 19:22:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Mon, 27 May 2013 19:22:07 +0200 From: Christer Holmberg To: Parthasarathi R , "'Dale R. Worley'" , 'Paul Kyzivat' Thread-Topic: [MMUSIC] When a bundle offer is forked Thread-Index: AQHOV9u/fklHpYO4tka0o0wHa47jypkTW/u2gACjmhCAA1ChYIABY7GggACIl4CAABAK7g== Date: Mon, 27 May 2013 17:22:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C379C5E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> <201305232206.r4NM6l5C5338062@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C377609@ESESSMB209.ericsson.se> <004d01ce5a08$a3193720$e94ba560$@co.in> <7594FB04B1934943A5C02806D1A2204B1C37943B@ESESSMB209.ericsson.se>, <001701ce5af7$2ee19240$8ca4b6c0$@co.in> In-Reply-To: <001701ce5af7$2ee19240$8ca4b6c0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvra79tMWBBh139S2mLn/MYjH5Ux+r xYoNB1gtXp4oc2Dx+Pv+A5PH5P1fmT2WLPnJ5PFh/hf2AJYoLpuU1JzMstQifbsErowlp38y F2xSq2hrusjewLhYrouRk0NCwERizoEHbBC2mMSFe+vBbCGBw4wSh69odTFyAdlLGCXOfdnC 3MXIwcEmYCHR/U8bpEZEoJlRonWdFUiYWUBd4uriIJCwsICxxL9F81ggSkwk/rT3MkHYYRKL D18Bi7MIqEpsWtTECmLzCvhKrOy+xQSxaiqHxLKpy8ESnEDNz5/3M4LYjEC3fT+1BmwQs4C4 xK0n85kgbhaQWLLnPDOELSrx8vE/VghbUaL9aQMjRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJ ywRGsVlIxs5C0jILScssJC0LGFlWMbLnJmbmpJcbbWIExtHBLb9VdzDeOSdyiFGag0VJnFeP d3GgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaAolheiTnnzm/a6eZreMk19c6rGdaKC6au NXFuSLsWV/T87PN5amUnj00XnrP3jJ6gvdXzAot78l8eHpyt0R1tueuRpOnUepOoPYGSXmtC j9p8WnTj8W2XKccOF+conGn2U1K7/K7Ztfot1959b35NPGu9/InxZM0rqhxcp6/EXH0kZen3 IqRdiaU4I9FQi7moOBEAvJOgunECAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:22:15 -0000 Hi, >My intention of the below mail is to say that the offer/answer interaction >issues created by BUNDLE for forking and it has to be documented. Also, it >is not implementation issue but more of protocol design issue. Please read >inline for more comments. Ok. >>>Forking has to be seen with the RTP role (endpoint, translator, mixer) >>> as the offer/answer exchange varies drastically for each RTP role. SIP >>>forking with RTP endpoint issues are explained as part of Sec 3.1 of >>> RFC 3960. One of the complexity introduced as part of BUNDLE is to have >>>two offer/answer before consolidating. The offer/answer interaction >>> between SIP forking with RTP endpoint and BUNDLE has to be mentioned. >>> I'll explain with the SIP serial forking with RTP endpoint scenario for >>> more clarity >>> >>>1) INVITE with SDP having BUNDLE offer and different port in each m- >>> line is send out from UAC >>>2) 183 with SDP and BUNDLE support is received from UAS1 >>>3) UPDATE with SDP having BUNDLE offer and single port in each m-line >>> is send towards UAS1 after completing PRACK & 200 >>>4) 183 with SDP and BUNDLE support is received from UAS2 >> >>>Here at Step 4, it is not possible for UAC to "mute" UAS1 as one >>> another OFFER is initiated already at Step 3 and BUNDLE forces to >>> "mute" the answer >>>UAS2. This limitation has to be mentioned as part of BUNDLE. Please >>> let me know your opinion on this. >> >> I don't understand. The UAC can: >> >> 1) wait for the UPDATE answer from UAS1, and then send a new "mute" UPDA= TE; or >> 2) send a BYE to UAS1, and terminate the whole early dialog. >> > UAC choice is restricted to the above choice because of BUNDLE. I don't see how the UAC is more restricted than in other cases where it wou= ld send an UPDATE to UAS1, and then receive an answer on UAS2. >This has to be mentioned in the document > >> Also, BUNDLE is not the only SIP/SDP mechanism which uses multiple >> Offer/Answer transactions. >> >> I agree with you that multiple offer/answer transaction is not = just >> by BUNDLE. Please indicate whether any document mention the issues relat= ed >> forking with multiple offer/answer. Not any IETF document that I am aware of. Regards, Christer > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Friday, May 24, 2013 1:55 PM > > To: Dale R. Worley; Paul Kyzivat > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] When a bundle offer is forked > > > > Hi, > > > > I agree with Dale. Each early dialog is handled separately. > > > > From a standards perspective, I don't think we need to say much about > > forking in BUNDLE, other than maybe some general words that it may > > happen. > > > > Then, whether it becomes tricky to implement, e.g. if one early leg > > uses BUNDLE and another doesn't, is another issue. But, as SIP has > > mechanisms to terminate early dialogs you don't like etc, I see this > > as a pure implementation issue. > > > > Regards, > > > > Christer > > > > > > > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Dale R. Worley > > Sent: 24. toukokuuta 2013 1:07 > > To: Paul Kyzivat > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] When a bundle offer is forked > > > > > From: Paul Kyzivat > > > > > > On 5/23/13 6:35 AM, Emil Ivov wrote: > > > > > > > In case a bundle offer gets forked and various answers ... > > > > > > I trimmed everything else out of Emil's reply, and changed to > > subject, > > > because this is a whole different can of worms! > > > > > > I think we must acknowledge that this *can* happen, though it is a > > low > > > probability event. It raises all sorts of ugly issues. A few: > > > > Is this actually complicated? That is, worse than is already the > case > > in SIP... > > > > My understanding is that in SIP (and this must be a SIP situation), > > each fork proceeds with completely independent state from all other > > forks. The forks happen to share sending/receiving ports, but the > > received packets can be demultiplexed to the correct fork based on > > their sending addresses. Of course, there are a range of obnoxious > > situations where you receive packets before you receive a SIP > response > > (SDP answer) that describes them, but that is true in non-bundled SIP > > as well. > > > > Dale > > _______________________________________________ > > 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 pkyzivat@alum.mit.edu Mon May 27 10:31:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7368B21F90AC for ; Mon, 27 May 2013 10:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q08aDaaTT9Ts for ; Mon, 27 May 2013 10:31:31 -0700 (PDT) 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 E49A821F8F87 for ; Mon, 27 May 2013 10:31:30 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id h50C1l0051ap0As5A5XWnb; Mon, 27 May 2013 17:31:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id h5XV1l0193ZTu2S3i5XWEc; Mon, 27 May 2013 17:31:30 +0000 Message-ID: <51A39870.7040708@alum.mit.edu> Date: Mon, 27 May 2013 13:31:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> 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=1369675890; bh=ci1QaGJwyhOErhSAf5pPOzP/A0KqTe8gQndjp6yP4MM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F7lGipgtZSjbI+MrygAd9tyrzXNXhIoWUo0g7zbhmFNsGgD73vf8RZM+emAgut81f GtpZyTCFIjUoGiyXwYME2E7Ct7b/1VpRqMipsNBb/kYqvVzp50Sxrwqi24LZdNmYOJ Da3y/wDXHz7aYh+5RgqgTNxnOO5Fd/C/dlZrNPCNiMX1AXmlLBPyq5pZv1kosHKevW s3PY1M49NTIUnJ1CTsks8yUixTvZxS6EZdF+PmqioMrSrtoEBk8VtoxJlZ1zEFgr0k Brp4Lt/tYGgstYyIy1sUiq/JwI+HawjIzNI2RFv/UPJDedxtGekXgOnq25mLAGhiuo vsZ5SKT8mkqNg== Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:31:35 -0000 Colin, (I guess you know I am naive about RTP, so take this with a grain of salt.) In the below, you first split by SSRC. Then later you map to codec. That seems to suggest that each SSRC might have a unique mapping from PT to codec. Did you intend that? I also don't understand below how you expect unknown SSRCs to be handled. ISTM that the flow you show could result in establishing a bunch of state for each received SSRC, whether that SSRC is of interest or not. In some cases it may be that specific SSRCs are expected, and others can be ignored (or whatever). In other cases the recipient may not know what SSRCs to expect, but may have some other way of deciding which it wants to process. That was the point of my thread about associating packets to m-lines. If you can at least associate a packet with one of the bundled m-lines, even if it is by a means other than SSRC, then it becomes easier to decide what to do with it. For instance, I think Cullen intends that in plan A you could associate packets with m-lines via the PT, and then for each m-line process only packets for the most recently seen SSRC. (So when a new SSRC is received, drop all state for the prior SSRC and establish a new state for the new one.) The same approach can work using a header extension identifying a clue capture encoding to map to an m-line. When doing that, it won't be necessary for the PT to be unique across m-lines. Thanks, Paul On 5/27/13 9:57 AM, Colin Perkins wrote: > I don't agree with the phrasing about "packet processing pipelines", but can't tell if this is a terminology disagreement or a more fundamental disconnect. The way I see the demultiplexing logically working is: > > | > | packets > +-- v > | +----------+ > | |UDP socket| > A | +----------+ > | RTP || | | > | and RTCP || | +------> SCTP > | || +---------> STUN/ICE > +-- || > +-- || > | split by SSRC > | || || || > | || || || > B | +--+ +--+ +--+ > | |PB| |PB| |PB| Playout buffer, process RTCP, FEC, etc. > | +--+ +--+ +--+ > +-- | | | > +-- | / | > | +---+ | > | / | | > C | +--+ +--+ +--+ > | |CR| |CR| |CR| Codecs and rendering > | +--+ +--+ +--+ > +-- > > If your algorithm is for demultiplexing at layer C, i.e., to figure out what codec and rendering pipeline to use, then I think we're in agreement apart from terminology. > > For layer B, I believe the SSRC is the right thing to use to demultiplex, and fits with RTP and RTCP. This is where RTCP is processed, playout de-jitter buffering happens, FEC is processed, NACKs are sent, etc. It's logically independent of the decoding and rendering process since you can start filling your de-jitter buffer for an SSRC before you figure out if/how/where you're going to render that SSRC. > > For layer A, there was a clear-cut way of doing this with RTP, RTCP, and STUN. I haven't looked at SCTP enough to know how that affects things. I do think it's a logically separate issue, and should be documented separately to BUNDLE though, since it the same issues arise with non-bundled sessions. > > An implementation might merge these together, of course, but to avoid confusion the standards should be clear what level they're considering. > > Colin > > > > On 27 May 2013, at 14:15, Cullen Jennings (fluffy) wrote: >> Great - sounds like we agree this algorithm will work. >> >> On May 27, 2013, at 6:41 AM, Colin Perkins wrote: >> >>> I'm not sure I agree. >>> >>> As I said in my previous message to the list, if we are agreed that the m= lines in a BUNDLE group form a single RTP session, then I believe we need unique payload types across all m= lines. In this case, BUNDLE can simply say that regular RTP source demultiplexing based on the SSRC has to be performed, then the payload type can be used to match sources to m= lines for those applications that care about doing so. >>> >>> If we're not agreed that the m= lines in a BUNDLE group form a single RTP session, then we have a lot more to discuss... >>> >>> Colin >>> >>> >>> >>> On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: >>>> Here's is my proposal for roughly what the bundle draft should say about this demux topic >>>> >>>> Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows: >>>> >>>> 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping >>>> >>>> 2) If the PT type is uniquely identifies a mapping, use that to form the mapping >>>> >>>> 3) If application knows the SSRC the other side will use, use that to form the mapping >>>> >>>> 4) if there is no way to know which pipeline to pass it too, the packet MAY be discarded or the application MAY decide to buffer it until the mapping is known >>>> >>>> This is trivial to implement. It meets the requirements for Plan A, Plan B, UCIF, CLUE, and so on. >>>> >>>> We could swap the order of step 2 and 3, My thinking for this order was the only time it made any difference the order was if the PT were unique and indicated a different mapping than the SSRC. The only way this could happen is with a SSRC collision so the PT is the one that would be correct not the SSRC. If someone feels strongly the order of steps 2 and 3 should be the opposite way around, I can live with that. >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>> >>> >>> >>> _______________________________________________ >>> 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 pkyzivat@alum.mit.edu Mon May 27 10:42:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027C221F8E76 for ; Mon, 27 May 2013 10:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.113 X-Spam-Level: X-Spam-Status: No, score=0.113 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg6WUWv0Udya for ; Mon, 27 May 2013 10:42:27 -0700 (PDT) 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 1690521F8ED8 for ; Mon, 27 May 2013 10:42:26 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta02.westchester.pa.mail.comcast.net with comcast id h0DD1l0050ldTLk515iSGj; Mon, 27 May 2013 17:42:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id h5iS1l00F3ZTu2S3Q5iSLu; Mon, 27 May 2013 17:42:26 +0000 Message-ID: <51A39B01.6030305@alum.mit.edu> Date: Mon, 27 May 2013 13:42:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> <519F7DEB.2010809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3794F5@ESESSMB209.ericsson.se>, <51A38AA4.70309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C379C4A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C379C4A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369676546; bh=aYWYJk5KYxKlaMt3EWpcKSO3hzr/whQUuR5COT33+aE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dOptPhHl6GB+wgNBkuC6g3YkZyor7Kz7SGX8Jhs+IVuUz8L3E/j0z+wuPWmVE/794 w8tCf5+vYAhMQeEepMpR1bS7RtwzakyWRKaPYaEXQAwKZOb1oSSkSP6/l0Sndi7w43 zjn56844EerCnWYVM1wt3kB9NsENPOM+9fxFyHZSmiM2BqKriT9ZPK7EgvciY3aGwA 1BPxS4paCbWTfO/fyqNEJymVoEPn14F2XNSs04t2KzZ9+jipVmQ0yDBUt8i+8GhN+y aWliC/QgPU2F+R7RUUVEAK6Sno25doGDlhPcq6ejsx09bQapnGnWSyy86pLeJ1K5OO XbWEwx94aO02Q== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:42:36 -0000 On 5/27/13 1:16 PM, Christer Holmberg wrote: > > Hi, > >>>>> At the interim yesterday, we agreed to use the SDP BUNDLE group >>>>> attribute to indicate on which port bundled media will be sent. In an >>>>> SDP offer, the order of the attribute mid values can be used by the >>>>> offerer to indicate a "wish", but the first attribute mid value in the >>>>> answer indicates where the answerer will eventually send bundled media. >>>> >>>> This could be interpreted to mean the first a=mid value in the SDP. >>>> I'm sure you mean "the first mid value in the a=group:bundle" line. >>> >>> Yes. >>> >>>> Or perhaps "the first mid value in the bundle group" - assuming there is a definition that "bundle group" means an a=group:bundle line. >>> >>> In the draft "bundle group" means (or, at least is supposed to mean :) the bundle grouped m- lines, and in general I think it is better to explicitly mention the line/attribute. >>> >>>> This can be "future proofed" by saying that the first mid value in the bundle group in the answer that references an m-line with non-zero >>>> port value. I realize this adds nothing unless 5888 is revised to permit m-lines with zero port in a bundle group. But at least it will be ready for that, and harms nothing. >>> >>> I agree, but suggest a little different wording: by saying the first mid value in the group attribute MUST NOT represent a port zero m- line. >> >> I just want to be sure we're clear here. >> >> Are you saying that even if we relax 5888 so that we may have m-lines >> with port zero in a bundle group, that the *first* mid in the bundle >> group can't designate a zero port??? > > Yes, for BUNDLE. It doesn't have to be a generic 5888 rule. > >> I guess that should always be possible as long as there is at least one >> with a non-zero port. >> >> Do we have a possibility, with ICE, that all the m-lines in the bundle >> will have zero port? (Because we are waiting for ICE to figure out the >> actual port.) Or are we going to use something else for that purpose? >> >> As long as there is no possibility of having a bundle where all the >> ports are zero then I'm ok with what you propose. > > I hear what you're saying. > > But, in that case saying "first non-zero mid" does not work either, does it? :) Yep, you're right! > Another option is to also allow mids for zero-port m- lines to be first. A first mid for a port zero m- line would mean that there is no port for bundled media. Maybe there could be a use-case for that. That sounds like a bad choice if one of the other m-lines in the bundle has a non-zero port. So maybe your rule is best, if it works: first mid in bundle must identify an m-line in the bundle with non-zero port if there is one. If there are non with non-zero port then it can refer to one that is zero. But we can't take this too far without deciding if we want to allow rejected m-lines in bundles, and if so, what that means. Thanks, Paul From christer.holmberg@ericsson.com Mon May 27 10:51:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EC721F9682 for ; Mon, 27 May 2013 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.548 X-Spam-Level: X-Spam-Status: No, score=-4.548 tagged_above=-999 required=5 tests=[AWL=-0.976, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lvumfqu6g54c for ; Mon, 27 May 2013 10:51:30 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55C21F966F for ; Mon, 27 May 2013 10:51:29 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-76-51a39d1f4eea Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 26.28.31782.F1D93A15; Mon, 27 May 2013 19:51:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Mon, 27 May 2013 19:51:27 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT Thread-Index: Ac5Yevnd5lghFfM/QmuiU1fEkjXC+QAAh7mAAI+mEfAACtXEAAAFeb+C///ns4CAACHrdA== Date: Mon, 27 May 2013 17:51:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C379D52@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37797E@ESESSMB209.ericsson.se> <519F7DEB.2010809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3794F5@ESESSMB209.ericsson.se>, <51A38AA4.70309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C379C4A@ESESSMB209.ericsson.se>, <51A39B01.6030305@alum.mit.edu> In-Reply-To: <51A39B01.6030305@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra7C3MWBBue/c1pMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG26c9LAWvZCru919kaWA8K9bFyMkhIWAi sb1nDyOELSZx4d56ti5GLg4hgcOMEs1tG9hAEkICSxglJr9n7mLk4GATsJDo/qcNYooIaEhM 2qoGYjILqEtcXRwEUiwsYCUxfck0VhBbRMBa4sb0dkYIO0ziY2MTmM0ioCpx8eIFsBpeAV+J N8c2MEJs3cokMf/cNXaQBKeAjkTT8Z/MIDYj0GnfT61hArGZBcQlbj2ZzwRxsoDEkj3nmSFs UYmXj/+xQtiKEu1PGxgh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzUIydhaSlllIWmYh aVnAyLKKkT03MTMnvdxoEyMwPg5u+a26g/HOOZFDjNIcLErivHq8iwOFBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MMb0fu2R2bFoknRQnd2BT8e7QvuKv8ctLExauC511ut+XV+fCwaLV889 17fj5+nrCpk/mhmbE9Xl7ea2JGYK/Z04udR2Q/zFy757Jn2tW+3vlspaXK/+T0xDd0LYr9Vd KuudSubced6flPBO9gWXxeXDokGvpkjfj//C8Ftz9zXbEokX0strHJVYijMSDbWYi4oTAfdd 0VhdAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:51:36 -0000 Hi, >>>>>> At the interim yesterday, we agreed to use the SDP BUNDLE group >>>>>> attribute to indicate on which port bundled media will be sent. In a= n >>>>>> SDP offer, the order of the attribute mid values can be used by the >>>>>> offerer to indicate a "wish", but the first attribute mid value in t= he >>>>>> answer indicates where the answerer will eventually send bundled med= ia. >>>>> >>>>> This could be interpreted to mean the first a=3Dmid value in the SDP. >>>>> I'm sure you mean "the first mid value in the a=3Dgroup:bundle" line. >>>> >>>> Yes. >>>> >>>>> Or perhaps "the first mid value in the bundle group" - assuming there= is a definition that "bundle group" means an a=3Dgroup:bundle line. >>>> >>>> In the draft "bundle group" means (or, at least is supposed to mean :)= the bundle grouped m- lines, and in general I think it is better to explic= itly mention the line/attribute. >>>> >>>>> This can be "future proofed" by saying that the first mid value in th= e bundle group in the answer that references an m-line with non-zero >>>>> port value. I realize this adds nothing unless 5888 is revised to per= mit m-lines with zero port in a bundle group. But at least it will be ready= for that, and harms nothing. >>>> >>>> I agree, but suggest a little different wording: by saying the first m= id value in the group attribute MUST NOT represent a port zero m- line. >>> >>> I just want to be sure we're clear here. >>> >>> Are you saying that even if we relax 5888 so that we may have m-lines >>> with port zero in a bundle group, that the *first* mid in the bundle >>> group can't designate a zero port??? >> >> Yes, for BUNDLE. It doesn't have to be a generic 5888 rule. >> >>> I guess that should always be possible as long as there is at least one >>> with a non-zero port. >>> >>> Do we have a possibility, with ICE, that all the m-lines in the bundle >>> will have zero port? (Because we are waiting for ICE to figure out the >>> actual port.) Or are we going to use something else for that purpose? >>> >>> As long as there is no possibility of having a bundle where all the >>> ports are zero then I'm ok with what you propose. >> >> I hear what you're saying. >> >> But, in that case saying "first non-zero mid" does not work either, does= it? :) > > Yep, you're right! > >> Another option is to also allow mids for zero-port m- lines to be first.= A first mid for a port zero m- line would mean that there is no port for b= undled media. Maybe there could be a use-case for that. > > That sounds like a bad choice if one of the other m-lines in the bundle h= as a non-zero port. I agree, but it would allow us to have a generic rule, which would be appli= cable also in the case where all m- lines have zero port values (assuming w= e'll allow such m- lines in a bundle group to begin with, that is). > So maybe your rule is best, if it works: first mid in bundle must > identify an m-line in the bundle with non-zero port if there is one. If > there are non with non-zero port then it can refer to one that is zero. > > But we can't take this too far without deciding if we want to allow > rejected m-lines in bundles, and if so, what that means. I don't think it means anything else than that the media associated with th= e m- line is disabled. As you have said earlier, having a port-zero-m-line = in a bundle could be used as a "hint that it may be used within a bundle la= ter", but I can't think of any new technical semantics. Plan A uses port-ze= ro-m-lines, but the plan doesn't define new semantics for the port value it= self. Regards, Christer= From christer.holmberg@ericsson.com Mon May 27 10:55:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E5921F8CB4 for ; Mon, 27 May 2013 10:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.221 X-Spam-Level: X-Spam-Status: No, score=-5.221 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBcZ9vOtsL+S for ; Mon, 27 May 2013 10:55:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 363D521F8AD1 for ; Mon, 27 May 2013 10:55:49 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-2b-51a39e236f9b Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4D.58.31782.32E93A15; Mon, 27 May 2013 19:55:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Mon, 27 May 2013 19:55:47 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOWtXocH/Y1zQW/EWt7TkWSefrJ5kY2NQAgAAiw8D//+EkAIAAIgyA///fnwCAAHHXZg== Date: Mon, 27 May 2013 17:55:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> In-Reply-To: <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra7KvMWBBvePslksf3mC0WLq8scs Dkwe0+7fZ/NYsuQnUwBTFJdNSmpOZllqkb5dAlfGsQlX2Qr2cVZM3LOVuYFxB3sXIyeHhICJ xLuZe1ggbDGJC/fWs4HYQgKHGSUm7SvuYuQCspcwSszc9B0owcHBJmAh0f1PG6RGREBVYsfx f4wgYWYBLYnObdYgprCAtcTBOewQFTYSDdP/s0DYYRKfnn1gBLFZgDofzt3PBGLzCvhK/Lry lRVi02smibOzFoM1cAo4SrSu3AnWwAh02vdTa8AamAXEJW49mc8EcbKAxJI955khbFGJl4// sULYihLtTxsYIep1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiy ipE9NzEzJ73caBMjMD4ObvmtuoPxzjmRQ4zSHCxK4rx6vIsDhQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTCKLNZ6r/ix+O4/yfB/JmXuphe/NZSKusWcvGPT0Pj2f/bpKSwivPutOlb99VlT 8GCffr8Q36RDWiUulWoqkTUSxzl/px4UvRr9I9euWjiBa9H9Y07MNrsmX6lJXrX5kP4tfaY9 Qpvzz8TN2D5lRrbSG11hrQ8L2ta9kLqdHbA/eP+FjYqccWuVWIozEg21mIuKEwF6tOiEXQIA AA== Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:55:55 -0000 Hi, >>>> v=3D0 >>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN I= P4 >>>> host.anywhere.com >>>> t=3D0 0 >>>> m=3Daudio 49170 RTP/AVP 96 >>>> a=3Drtpmap:96 AMR-WB/16000 >>>> m=3Daudio 49170 RTP/AVP ??? >>>> a=3Drtpmap:??? AMR-WB/16000 >>> >>> Not sure I get your point. You can have two different payload types tha= t map to the same payload format in a single RTP session, since >>> you can always distinguish what payload format is intended. You can't h= ave the same payload type mapping to two different payload >>> formats in a single RTP session, since you can't then infer what payloa= d format was meant. >> >> Please not that both PTs map to the SAME payload format :) > > I thought I addressed that in my reply. I am not sure you did - at least I didn't get it :) Again, my understanding of what you said is that, for any payload format wi= thin an RTP session, the PT value has to be unique. In the example above the same payload format, within the same RTP session, = is used in two separate m- lines. But, I still can't use the same PT value = for both m- lines, even if the payload format is the same, can I? Regards, Christer From csp@csperkins.org Mon May 27 11:08:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5182721F9675 for ; Mon, 27 May 2013 11:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ehc5ZF5MA4S5 for ; Mon, 27 May 2013 11:08:15 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF9721F8FED for ; Mon, 27 May 2013 11:08:15 -0700 (PDT) Received: from [81.187.2.149] (port=46096 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh1q9-00026B-BO; Mon, 27 May 2013 19:08:14 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51A39870.7040708@alum.mit.edu> Date: Mon, 27 May 2013 19:08:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E11F505-6808-4E09-9359-8494B795BEDD@csperkins.org> References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> <51A39870.7040708@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 18:08:20 -0000 Paul, On 27 May 2013, at 18:31, Paul Kyzivat wrote: > Colin, >=20 > (I guess you know I am naive about RTP, so take this with a grain of = salt.) >=20 > In the below, you first split by SSRC. Then later you map to codec. = That seems to suggest that each SSRC might have a unique mapping from PT = to codec. Did you intend that? That's not how RTP has worked historically. The mapping from payload = type to payload format has always been done on a per-RTP session basis, = with a static mapping for some types, and a dynamic binding via SDP for = others. > I also don't understand below how you expect unknown SSRCs to be = handled. ISTM that the flow you show could result in establishing a = bunch of state for each received SSRC, whether that SSRC is of interest = or not. If you receive RTP and/or RTCP packets you need to keep some state for = that SSRC. At least, you need to record the SSRC as in-use so you can = avoid collisions, and you need to send RTCP reports for that SSRC. The = state requirements for this are small (tens of bytes per SSRC). If you = care about decoding and rendering the source there is more state, of = course, but you only need that if you're rendering their media. You also need to be slightly smart to prevent DoS attacks if the other = side decides to send you a stream of packets with a different, random, = SSRC in each, but that's just basic robustness, and there are plenty of = other ways to DoS a poorly engineered receiver at the RTP layer without = playing tricks with SSRCs. > In some cases it may be that specific SSRCs are expected, and others = can be ignored (or whatever). In other cases the recipient may not know = what SSRCs to expect, but may have some other way of deciding which it = wants to process. Sure - if you know what SSRCs you're expecting, you can pre-populate = some of the state at the RTP level, and tell that layer that unknown = SSRCs can be discarded. None of that changes the basic approach to = de-multiplexing. > That was the point of my thread about associating packets to m-lines. = If you can at least associate a packet with one of the bundled m-lines, = even if it is by a means other than SSRC, then it becomes easier to = decide what to do with it. For instance, I think Cullen intends that in = plan A you could associate packets with m-lines via the PT, and then for = each m-line process only packets for the most recently seen SSRC. (So = when a new SSRC is received, drop all state for the prior SSRC and = establish a new state for the new one.) I would suggest instead: de-multiplex into sources based on the SSRC and = keep state for those according to the RTP timing rules. If you want to = associate sources with m=3D lines via the PT, and determine what to = render based on most recently active, that works fine, and works with = all the various RTP and RTCP extensions (unlike de-multiplexing sources = based on the PT), and gives you many more possible sources since the = SSRC space is larger than the PT space. > The same approach can work using a header extension identifying a clue = capture encoding to map to an m-line. When doing that, it won't be = necessary for the PT to be unique across m-lines. The combination of an RTP Header Extension and/or RTCP SDES packet to = identify an m=3D line would also work, and associates with the stream = based on the SSRC. You don't need to use the PT to demultiplex for this. Colin > Thanks, > Paul >=20 > On 5/27/13 9:57 AM, Colin Perkins wrote: >> I don't agree with the phrasing about "packet processing pipelines", = but can't tell if this is a terminology disagreement or a more = fundamental disconnect. The way I see the demultiplexing logically = working is: >>=20 >> | >> | packets >> +-- v >> | +----------+ >> | |UDP socket| >> A | +----------+ >> | RTP || | | >> | and RTCP || | +------> SCTP >> | || +---------> STUN/ICE >> +-- || >> +-- || >> | split by SSRC >> | || || || >> | || || || >> B | +--+ +--+ +--+ >> | |PB| |PB| |PB| Playout buffer, process RTCP, FEC, etc. >> | +--+ +--+ +--+ >> +-- | | | >> +-- | / | >> | +---+ | >> | / | | >> C | +--+ +--+ +--+ >> | |CR| |CR| |CR| Codecs and rendering >> | +--+ +--+ +--+ >> +-- >>=20 >> If your algorithm is for demultiplexing at layer C, i.e., to figure = out what codec and rendering pipeline to use, then I think we're in = agreement apart from terminology. >>=20 >> For layer B, I believe the SSRC is the right thing to use to = demultiplex, and fits with RTP and RTCP. This is where RTCP is = processed, playout de-jitter buffering happens, FEC is processed, NACKs = are sent, etc. It's logically independent of the decoding and rendering = process since you can start filling your de-jitter buffer for an SSRC = before you figure out if/how/where you're going to render that SSRC. >>=20 >> For layer A, there was a clear-cut way of doing this with RTP, RTCP, = and STUN. I haven't looked at SCTP enough to know how that affects = things. I do think it's a logically separate issue, and should be = documented separately to BUNDLE though, since it the same issues arise = with non-bundled sessions. >>=20 >> An implementation might merge these together, of course, but to avoid = confusion the standards should be clear what level they're considering. >>=20 >> Colin >>=20 >>=20 >>=20 >> On 27 May 2013, at 14:15, Cullen Jennings (fluffy) wrote: >>> Great - sounds like we agree this algorithm will work. >>>=20 >>> On May 27, 2013, at 6:41 AM, Colin Perkins = wrote: >>>=20 >>>> I'm not sure I agree. >>>>=20 >>>> As I said in my previous message to the list, if we are agreed that = the m=3D lines in a BUNDLE group form a single RTP session, then I = believe we need unique payload types across all m=3D lines. In this = case, BUNDLE can simply say that regular RTP source demultiplexing based = on the SSRC has to be performed, then the payload type can be used to = match sources to m=3D lines for those applications that care about doing = so. >>>>=20 >>>> If we're not agreed that the m=3D lines in a BUNDLE group form a = single RTP session, then we have a lot more to discuss... >>>>=20 >>>> Colin >>>>=20 >>>>=20 >>>>=20 >>>> On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: >>>>> Here's is my proposal for roughly what the bundle draft should say = about this demux topic >>>>>=20 >>>>> Application will decide which packet processing pipeline to pass = an given RTP/RTCP packet to based on what the application knows: >>>>>=20 >>>>> 1) If future RFCs define new things (like RTP header extension), = that explicitly specify the mapping, check if that future RFC is in use = and if so then use that to form the mapping >>>>>=20 >>>>> 2) If the PT type is uniquely identifies a mapping, use that to = form the mapping >>>>>=20 >>>>> 3) If application knows the SSRC the other side will use, use that = to form the mapping >>>>>=20 >>>>> 4) if there is no way to know which pipeline to pass it too, the = packet MAY be discarded or the application MAY decide to buffer it until = the mapping is known >>>>>=20 >>>>> This is trivial to implement. It meets the requirements for Plan = A, Plan B, UCIF, CLUE, and so on. >>>>>=20 >>>>> We could swap the order of step 2 and 3, My thinking for this = order was the only time it made any difference the order was if the PT = were unique and indicated a different mapping than the SSRC. The only = way this could happen is with a SSRC collision so the PT is the one that = would be correct not the SSRC. If someone feels strongly the order of = steps 2 and 3 should be the opposite way around, I can live with that. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Colin Perkins >>>> http://csperkins.org/ >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 27 11:10:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C972921F9616 for ; Mon, 27 May 2013 11:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.644 X-Spam-Level: X-Spam-Status: No, score=-105.644 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOHjiidcUafX for ; Mon, 27 May 2013 11:10:52 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0E721F9260 for ; Mon, 27 May 2013 11:10:52 -0700 (PDT) Received: from [81.187.2.149] (port=43635 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh1se-0002Jc-Oi; Mon, 27 May 2013 19:10:51 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se> Date: Mon, 27 May 2013 19:10:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 18:10:56 -0000 On 27 May 2013, at 18:55, Christer Holmberg wrote: >>>>> v=3D0 >>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN= IP4 >>>>> host.anywhere.com >>>>> t=3D0 0 >>>>> m=3Daudio 49170 RTP/AVP 96 >>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>> m=3Daudio 49170 RTP/AVP ??? >>>>> a=3Drtpmap:??? AMR-WB/16000 >>>>=20 >>>> Not sure I get your point. You can have two different payload types = that map to the same payload format in a single RTP session, since >>>> you can always distinguish what payload format is intended. You = can't have the same payload type mapping to two different payload >>>> formats in a single RTP session, since you can't then infer what = payload format was meant. >>>=20 >>> Please not that both PTs map to the SAME payload format :) >>=20 >> I thought I addressed that in my reply. >=20 > I am not sure you did - at least I didn't get it :) >=20 > Again, my understanding of what you said is that, for any payload = format within an RTP session, the PT value has to be unique. Correct. > In the example above the same payload format, within the same RTP = session, is used in two separate m- lines. But, I still can't use the = same PT value for both m- lines, even if the payload format is the same, = can I? Why not? I don't see any problem mapping the same payload type to the = exact same payload format in two different m=3D lines. Mapping the same = payload type to two different payload formats is the problem. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 27 11:29:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F048521F91A0 for ; Mon, 27 May 2013 11:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.624 X-Spam-Level: X-Spam-Status: No, score=-105.624 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx2DRQkmN0tV for ; Mon, 27 May 2013 11:29:16 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89E21F911B for ; Mon, 27 May 2013 11:29:16 -0700 (PDT) Received: from [81.187.2.149] (port=48843 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh2AV-0006sp-7Y; Mon, 27 May 2013 19:29:15 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51A39023.1070605@alum.mit.edu> Date: Mon, 27 May 2013 19:29:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 18:29:21 -0000 Paul, What would that other characteristic be? The only thing you have is the = SSRC, and SDP doesn't scope "a=3Drtpmap:" lines to be per "a=3Dssrc:" = line, and RTP certainly doesn't treat payload types as per SSRC. Colin On 27 May 2013, at 17:56, Paul Kyzivat wrote: > Colin, >=20 > As I suggested on another thread, ISTM that it should be possible to = reuse the same PT to map to different payload formats in different = m-lines of a bundle *if* there is some other characteristic declared in = SDP and present in packets that can be used to associate the packet to = one m-line. In that case, after picking the m-line, the mapping from PT = to payload format for *that* m-line can be used. E.g., >=20 > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com > s=3D > c=3DIN IP4 host.anywhere.com > t=3D0 0 > a=3Dgroup:bundle X Y > m=3Daudio 49170 RTP/AVP 96 > a=3Dmid:X > a=3Dssrc:1111 cname:x@example.com > a=3Drtpmap:96 AMR-WB/16000 > m=3Daudio 49172 RTP/AVP 96 > a=3Dmid:Y > a=3Dssrc:2222 cname:y@example.com > a=3Drtpmap:96 G7291/16000 >=20 > Thanks, > Paul >=20 >=20 > On 5/27/13 8:29 AM, Colin Perkins wrote: >> There were a number of comments in the call last week, and on the = list, about unique payload types in BUNDLE. I'd like to explore this = further. >>=20 >> Case A: Within a single RTP session, I think we'd all agree that an = offer that uses the same RTP payload type for two payload formats on a = single m=3D line is problematic: >>=20 >> v=3D0 >> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com >> s=3D >> c=3DIN IP4 host.anywhere.com >> t=3D0 0 >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 AMR-WB/16000 >> a=3Drtpmap:96 G7291/16000 >>=20 >> If this were done the receiver would have no way of distinguishing = what payload format is meant by payload type 96. Accordingly, unique = payload formats need to be used for each payload format. >>=20 >> Case B: If one were to use two separate m=3D lines on different = ports, in the non-BUNDLE case, then the same RTP payload type can be = reused without difficulty: >>=20 >> v=3D0 >> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com >> s=3D >> c=3DIN IP4 host.anywhere.com >> t=3D0 0 >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 AMR-WB/16000 >> m=3Daudio 49172 RTP/AVP 96 >> a=3Drtpmap:96 G7291/16000 >>=20 >> The implication is that there are two separate RTP sessions, which = the receiver can distinguish based on the UDP port on which the packets = are received. The mapping from RTP payload types to payload formats is = done on a per-RTP session basis. >>=20 >> Case C: This is when we BUNDLE several m=3D lines on a single UDP = port. On the call last week, there seemed to be agreement that the m=3D = lines in such a BUNDLE group comprise a single RTP session (it also = matches the definition of an RTP session from RFC 3550: the packets go = to a single destination and the m=3D lines share a single SSRC space). = To me this would suggest that the RTP payload type values MUST be unique = across the m=3D lines (or, if the same RTP payload type is used in = different m=3D lines, it MUST map to an identical payload format). The = reason is that everything runs over one UDP port, and if a single RTP = payload type is mapped to different payload formats, there's no way to = distinguish which payload format is meant. This is essentially the same = as case A above. >>=20 >> Given this, it's not clear to me that non-unique payload types make = sense within a BUNDLE group. They work on different m=3D lines in the = legacy case because those lines form different RTP sessions, and the RTP = sessions can be used to scope the payload type to payload format = mappings. I don't see that they work in BUNDLE, because there's a single = RTP session, and so a single mapping from payload type to payload = format. >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Mon May 27 11:38:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA8821F94DC for ; Mon, 27 May 2013 11:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.42 X-Spam-Level: X-Spam-Status: No, score=0.42 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrBO6Xm1U2-0 for ; Mon, 27 May 2013 11:38:34 -0700 (PDT) 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 87E1D21F9418 for ; Mon, 27 May 2013 11:38:34 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta06.westchester.pa.mail.comcast.net with comcast id h6221l0061swQuc566eawx; Mon, 27 May 2013 18:38:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id h6eZ1l00o3ZTu2S3b6eZRj; Mon, 27 May 2013 18:38:33 +0000 Message-ID: <51A3A829.7050201@alum.mit.edu> Date: Mon, 27 May 2013 14:38:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se> <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> In-Reply-To: <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> 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=1369679914; bh=k7WSWFaDBTzeO3XqA9dK0uo7CGGo5/v1VZE2R0JDMcI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Yrpup20E0SVUOaj70NKwVwHScTDSlN7IcameyVVuNdVYL1bv95D20c2EZhKstXCkQ HIYIay60guTA0zD14SyYH9VHqQHf+KXcKWF8inF6MULbvD9hFC48jOH0X4VwrRwAHy 0cH2/1nItnzh4X4fZ3dmnEFuOftWTD3rVMdfGQ971uVb5Klws8Z4RO4ij2HEubCFAl 2q348fsO4hKux76cycVRcznnJlJsAIvOqGGNwMsqSFTvz6k6xHCJzD+7Q1PpUPgX6Q mFeZEgM23Z/gFAM8mM1SPG0BcOppz7ZmztcSXClwOooKDZdAE8V0sBbl6ZK9El3s3A 6x99KqBRQYJsQ== Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 18:38:39 -0000 On 5/27/13 2:10 PM, Colin Perkins wrote: > On 27 May 2013, at 18:55, Christer Holmberg wrote: >>>>>> v=0 >>>>>> o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 >>>>>> host.anywhere.com >>>>>> t=0 0 >>>>>> m=audio 49170 RTP/AVP 96 >>>>>> a=rtpmap:96 AMR-WB/16000 >>>>>> m=audio 49170 RTP/AVP ??? >>>>>> a=rtpmap:??? AMR-WB/16000 >>>>> >>>>> Not sure I get your point. You can have two different payload types that map to the same payload format in a single RTP session, since >>>>> you can always distinguish what payload format is intended. You can't have the same payload type mapping to two different payload >>>>> formats in a single RTP session, since you can't then infer what payload format was meant. >>>> >>>> Please not that both PTs map to the SAME payload format :) >>> >>> I thought I addressed that in my reply. >> >> I am not sure you did - at least I didn't get it :) >> >> Again, my understanding of what you said is that, for any payload format within an RTP session, the PT value has to be unique. > > Correct. Now you're both confused. What you are trying to say is that for any PT value withing an RTP session the payload format must be unique. E.g., two different PTs may map to the same format, but one PT may not map to two different formats. But I continue to argue that we could relax that, as long as there is something else that selects which PT mapping to use. >> In the example above the same payload format, within the same RTP session, is used in two separate m- lines. But, I still can't use the same PT value for both m- lines, even if the payload format is the same, can I? > > > Why not? I don't see any problem mapping the same payload type to the exact same payload format in two different m= lines. Mapping the same payload type to two different payload formats is the problem. It depends. *If* you are trying to use the PT to associate packets to an m-line, then indeed you might need to use different PT values for the same payload format in order to accomplish that. Thanks, Paul From csp@csperkins.org Mon May 27 11:41:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AD721F8E9A for ; Mon, 27 May 2013 11:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.607 X-Spam-Level: X-Spam-Status: No, score=-105.607 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAIJgC1Hfl8i for ; Mon, 27 May 2013 11:41:54 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 124F021F8C1A for ; Mon, 27 May 2013 11:41:54 -0700 (PDT) Received: from [81.187.2.149] (port=39945 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh2Mj-0007yK-1m; Mon, 27 May 2013 19:41:53 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51A3A829.7050201@alum.mit.edu> Date: Mon, 27 May 2013 19:41:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se> <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <51A3A829.7050201@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 18:41:58 -0000 On 27 May 2013, at 19:38, Paul Kyzivat wrote: > On 5/27/13 2:10 PM, Colin Perkins wrote: >> On 27 May 2013, at 18:55, Christer Holmberg wrote: >>>>>>> v=3D0 >>>>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D = c=3DIN IP4 >>>>>>> host.anywhere.com >>>>>>> t=3D0 0 >>>>>>> m=3Daudio 49170 RTP/AVP 96 >>>>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>>>> m=3Daudio 49170 RTP/AVP ??? >>>>>>> a=3Drtpmap:??? AMR-WB/16000 >>>>>>=20 >>>>>> Not sure I get your point. You can have two different payload = types that map to the same payload format in a single RTP session, since >>>>>> you can always distinguish what payload format is intended. You = can't have the same payload type mapping to two different payload >>>>>> formats in a single RTP session, since you can't then infer what = payload format was meant. >>>>>=20 >>>>> Please not that both PTs map to the SAME payload format :) >>>>=20 >>>> I thought I addressed that in my reply. >>>=20 >>> I am not sure you did - at least I didn't get it :) >>>=20 >>> Again, my understanding of what you said is that, for any payload = format within an RTP session, the PT value has to be unique. >>=20 >> Correct. >=20 > Now you're both confused. What you are trying to say is that for any = PT value withing an RTP session the payload format must be unique. >=20 > E.g., two different PTs may map to the same format, but one PT may not = map to two different formats. >=20 > But I continue to argue that we could relax that, as long as there is = something else that selects which PT mapping to use. Yes, but why? >>> In the example above the same payload format, within the same RTP = session, is used in two separate m- lines. But, I still can't use the = same PT value for both m- lines, even if the payload format is the same, = can I? >>=20 >>=20 >> Why not? I don't see any problem mapping the same payload type to the = exact same payload format in two different m=3D lines. Mapping the same = payload type to two different payload formats is the problem. >=20 > It depends. *If* you are trying to use the PT to associate packets to = an m-line, then indeed you might need to use different PT values for the = same payload format in order to accomplish that. Sure, but no-one is arguing against that. The problem is using the same = PT for different payload formats.=20 --=20 Colin Perkins http://csperkins.org/ From christer.holmberg@ericsson.com Mon May 27 11:44:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B524C21F966F for ; Mon, 27 May 2013 11:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.21 X-Spam-Level: X-Spam-Status: No, score=-5.21 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlKTpypDydWz for ; Mon, 27 May 2013 11:44:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0CECB21F966B for ; Mon, 27 May 2013 11:44:00 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-b4-51a3a96fd5e2 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 44.6B.31782.F69A3A15; Mon, 27 May 2013 20:43:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Mon, 27 May 2013 20:43:59 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOWtXocH/Y1zQW/EWt7TkWSefrJ5kY2NQAgAAiw8D//+EkAIAAIgyA///fnwCAAHHXZv//45cAAAVIH3g= Date: Mon, 27 May 2013 18:43:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> In-Reply-To: <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW7+ysWBBmsXGVosf3mC0WLq8scs Dkwe0+7fZ/NYsuQnUwBTFJdNSmpOZllqkb5dAlfGjQUvmQsm8VTMO7uIuYHxJGcXIyeHhICJ xO6599kgbDGJC/fWA9lcHEIChxkltu2cxgThLGGUODflD1CGg4NNwEKi+582SIOIgKrEjuP/ GEHCzAJaEp3brEFMYQFriYNz2CEqbCQapv9ngbCTJBomXwSzWYA6O77PYAaxeQV8JY5t+M0O sek5s8SBF3uZQeZwCjhKPD5XBVLDCHTa91NrmEBsZgFxiVtP5jNBnCwgsWTPeWYIW1Ti5eN/ rBC2okT70wZGiHodiQW7P7FB2NoSyxa+htorKHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxi ZM9NzMxJLzfaxAiMj4NbfqvuYLxzTuQQozQHi5I4rx7v4kAhgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjOlXz5n7pHheuDnzfuKfad1HfU8zsV/RdLgdYizIYWEb9uvmmUeNZb6akpe4V0zW jZPNveer7x3turL5uFb/A0vnqglpmd41J1W5th50MYtv+mJ10PpcyrF/Gk5zL+6en64n/3v2 1727HgiurQ1leMK23PJMN7fhw2D7fe2rOlLtTdjL63b1KbEUZyQaajEXFScCAHA8P9xdAgAA Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 18:44:06 -0000 Hi, >>>>>> v=3D0 >>>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN= IP4 >>>>>> host.anywhere.com >>>>>> t=3D0 0 >>>>>> m=3Daudio 49170 RTP/AVP 96 >>>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>>> m=3Daudio 49170 RTP/AVP ??? >>>>>> a=3Drtpmap:??? AMR-WB/16000 >>>>> >>>>> Not sure I get your point. You can have two different payload types t= hat map to the same payload format in a single RTP session, since >>>>> you can always distinguish what payload format is intended. You can't= have the same payload type mapping to two different payload >>>>> formats in a single RTP session, since you can't then infer what payl= oad format was meant. >>>> >>>> Please not that both PTs map to the SAME payload format :) >>> >>> I thought I addressed that in my reply. >> >> I am not sure you did - at least I didn't get it :) >> >> Again, my understanding of what you said is that, for any payload format= within an RTP session, the PT value has to be unique. > > Correct. > >> In the example above the same payload format, within the same RTP sessio= n, is used in two separate m- lines. But, I still can't use the same PT val= ue for both m- lines, even if the payload format is the same, can I? >Why not? I don't see any problem mapping the same payload type to the exac= t same payload format in two different m=3D lines. But, when I receive media with that payload format, how do I know to which = m- line it "belongs", as the same PT value is used for both m- lines? Regards, Christer From pkyzivat@alum.mit.edu Mon May 27 11:49:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A47B21F8DB7 for ; Mon, 27 May 2013 11:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM+8CXekLYVV for ; Mon, 27 May 2013 11:49:43 -0700 (PDT) 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 A373F21F8AD1 for ; Mon, 27 May 2013 11:49:41 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta02.westchester.pa.mail.comcast.net with comcast id h6V71l0050bG4ec516phKf; Mon, 27 May 2013 18:49:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id h6pg1l00w3ZTu2S3P6pgxB; Mon, 27 May 2013 18:49:40 +0000 Message-ID: <51A3AAC3.9030905@alum.mit.edu> Date: Mon, 27 May 2013 14:49:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Colin Perkins References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@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=1369680581; bh=WtnAJJcpdOn2UCE+n7jGe3GLEcxD/p3A1Gxnn804q80=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OCFRTxDc8KpUKIrVyHKl90v0lApS5VwsLHYSBantuY1EcO7J57Y1H93ax3ym07gsk 23fVaynJfHPNQpHRHvgBlvzBr6kEuC+BPyNEiaoGHQNuAaH+G/iub9LR8Lzxe74Nkq 2pwwhm6YbM2Z/H8r+FYfzF1fY1PvBSK4WBBysyjvxSI9DjM629QMUjllSZny+INGHw cA8wHeutVB1rXLrkZPtEt356t0yxgCd9X9WY3ylKH65s4ulYw8U5zi71R4DNpXmtI5 VJE6nx3UX5rcwE0T4DpixjHsaU5CtNszoPP+tLmCyRcCJuDR8Dhko24Xe0kv8YoWWl sfgOj3f4u3ktg== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 18:49:48 -0000 On 5/27/13 2:29 PM, Colin Perkins wrote: > Paul, > > What would that other characteristic be? The only thing you have is the SSRC, and SDP doesn't scope "a=rtpmap:" lines to be per "a=ssrc:" line, and RTP certainly doesn't treat payload types as per SSRC. This is all part of defining the precise semantics of bundling! In the example I gave below, what I am suggesting is that: - SSRC 1111 is associated with m-line X, and SSRC 22222 is associated with m-line Y. - When a packet is received, it must first be associated with an m-line. If it has SSRC=1111 then it can be associated with m-line X. Then, m-line X gives the mapping of PT 96 to audio and AMR. If it has SSRC=2222 then it can be associated with m-line Y. Then, m-line Y gives the mapping of PT 96 to audio and G.7291. (If a packet with some other SSRC is received then the mapping to an m-line is unknown, unless we introduce some other rule.) - in some other example, if some PT is unique to a single m-line, then a packet with that PT can be associated to that m-line. Have I made myself clear yet? Thanks, Paul > Colin > > > > On 27 May 2013, at 17:56, Paul Kyzivat wrote: >> Colin, >> >> As I suggested on another thread, ISTM that it should be possible to reuse the same PT to map to different payload formats in different m-lines of a bundle *if* there is some other characteristic declared in SDP and present in packets that can be used to associate the packet to one m-line. In that case, after picking the m-line, the mapping from PT to payload format for *that* m-line can be used. E.g., >> >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.anywhere.com >> s= >> c=IN IP4 host.anywhere.com >> t=0 0 >> a=group:bundle X Y >> m=audio 49170 RTP/AVP 96 >> a=mid:X >> a=ssrc:1111 cname:x@example.com >> a=rtpmap:96 AMR-WB/16000 >> m=audio 49172 RTP/AVP 96 >> a=mid:Y >> a=ssrc:2222 cname:y@example.com >> a=rtpmap:96 G7291/16000 >> >> Thanks, >> Paul >> >> >> On 5/27/13 8:29 AM, Colin Perkins wrote: >>> There were a number of comments in the call last week, and on the list, about unique payload types in BUNDLE. I'd like to explore this further. >>> >>> Case A: Within a single RTP session, I think we'd all agree that an offer that uses the same RTP payload type for two payload formats on a single m= line is problematic: >>> >>> v=0 >>> o=alice 2890844526 2890844526 IN IP4 host.anywhere.com >>> s= >>> c=IN IP4 host.anywhere.com >>> t=0 0 >>> m=audio 49170 RTP/AVP 96 >>> a=rtpmap:96 AMR-WB/16000 >>> a=rtpmap:96 G7291/16000 >>> >>> If this were done the receiver would have no way of distinguishing what payload format is meant by payload type 96. Accordingly, unique payload formats need to be used for each payload format. >>> >>> Case B: If one were to use two separate m= lines on different ports, in the non-BUNDLE case, then the same RTP payload type can be reused without difficulty: >>> >>> v=0 >>> o=alice 2890844526 2890844526 IN IP4 host.anywhere.com >>> s= >>> c=IN IP4 host.anywhere.com >>> t=0 0 >>> m=audio 49170 RTP/AVP 96 >>> a=rtpmap:96 AMR-WB/16000 >>> m=audio 49172 RTP/AVP 96 >>> a=rtpmap:96 G7291/16000 >>> >>> The implication is that there are two separate RTP sessions, which the receiver can distinguish based on the UDP port on which the packets are received. The mapping from RTP payload types to payload formats is done on a per-RTP session basis. >>> >>> Case C: This is when we BUNDLE several m= lines on a single UDP port. On the call last week, there seemed to be agreement that the m= lines in such a BUNDLE group comprise a single RTP session (it also matches the definition of an RTP session from RFC 3550: the packets go to a single destination and the m= lines share a single SSRC space). To me this would suggest that the RTP payload type values MUST be unique across the m= lines (or, if the same RTP payload type is used in different m= lines, it MUST map to an identical payload format). The reason is that everything runs over one UDP port, and if a single RTP payload type is mapped to different payload formats, there's no way to distinguish which payload format is meant. This is essentially the same as case A above. >>> >>> Given this, it's not clear to me that non-unique payload types make sense within a BUNDLE group. They work on different m= lines in the legacy case because those lines form different RTP sessions, and the RTP sessions can be used to scope the payload type to payload format mappings. I don't see that they work in BUNDLE, because there's a single RTP session, and so a single mapping from payload type to payload format. >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > From csp@csperkins.org Mon May 27 11:52:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7122F21F8DB7 for ; Mon, 27 May 2013 11:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.592 X-Spam-Level: X-Spam-Status: No, score=-105.592 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FkR+3OnpPpc for ; Mon, 27 May 2013 11:52:30 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 26A3921F8AD1 for ; Mon, 27 May 2013 11:52:28 -0700 (PDT) Received: from [81.187.2.149] (port=47175 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh2Ww-0001jB-C1; Mon, 27 May 2013 19:52:27 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> Date: Mon, 27 May 2013 19:52:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 18:52:50 -0000 On 27 May 2013, at 19:43, Christer Holmberg wrote: >>>>>>> v=3D0 >>>>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D = c=3DIN IP4 >>>>>>> host.anywhere.com >>>>>>> t=3D0 0 >>>>>>> m=3Daudio 49170 RTP/AVP 96 >>>>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>>>> m=3Daudio 49170 RTP/AVP ??? >>>>>>> a=3Drtpmap:??? AMR-WB/16000 >>>>>>=20 >>>>>> Not sure I get your point. You can have two different payload = types that map to the same payload format in a single RTP session, since >>>>>> you can always distinguish what payload format is intended. You = can't have the same payload type mapping to two different payload >>>>>> formats in a single RTP session, since you can't then infer what = payload format was meant. >>>>>=20 >>>>> Please not that both PTs map to the SAME payload format :) >>>>=20 >>>> I thought I addressed that in my reply. >>>=20 >>> I am not sure you did - at least I didn't get it :) >>>=20 >>> Again, my understanding of what you said is that, for any payload = format within an RTP session, the PT value has to be unique. >>=20 >> Correct. >>=20 >>> In the example above the same payload format, within the same RTP = session, is used in two separate m- lines. But, I still can't use the = same PT value for both m- lines, even if the payload format is the same, = can I? >=20 >> Why not? I don't see any problem mapping the same payload type to the = exact same payload format in two different m=3D lines. >=20 > But, when I receive media with that payload format, how do I know to = which m- line it "belongs", as the same PT value is used for both m- = lines? You don't. If you care about that, you need to either use distinct PT = values for each m=3D line, or signal SSRCs.=20 --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Mon May 27 11:55:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123F021F8D94 for ; Mon, 27 May 2013 11:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.496 X-Spam-Level: X-Spam-Status: No, score=0.496 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEi1hY9DAr1U for ; Mon, 27 May 2013 11:55:54 -0700 (PDT) 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 1CC0E21F8D00 for ; Mon, 27 May 2013 11:55:53 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id h6Nl1l0011HzFnQ596vt5R; Mon, 27 May 2013 18:55:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id h6vt1l0073ZTu2S3a6vt0b; Mon, 27 May 2013 18:55:53 +0000 Message-ID: <51A3AC38.4030501@alum.mit.edu> Date: Mon, 27 May 2013 14:55:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369680953; bh=1lF5MesolGYYAjOwiggQSdU4wT4V7MqeCnR0dbLxMN4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=B2Kt5lv6vMOiiEwNEsWBGg9Hxdobn06Vlkgmb/Y6lMrl386fv79sdq7UJB9sAR3lW Um5ZfoNMhuBaz0ac50E05A22rwcsgdskrS5XpFpIYS1pKM1PVEVj3iiCFk/gWwKtWs A1M7EkAKntm4KNYAcCfaZq/nzUtUa/tlLalp5pEpl8HNjnTP/HARy83rCwb+XnHIC5 1yyaQlU7zz1eijGv+YGoGMQxEguE6W33k0hSZ5ZD1HgO8qIdYm9gPk+lsmE/37mgbl UKGwTj6oEf/rzfKc24nV9wG8WTPjrSD6SuknhsedHbgKaMhzDkqNFjv6onPEmjEjoJ M9PDQfFEz0Xsg== Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 18:55:59 -0000 On 5/27/13 2:43 PM, Christer Holmberg wrote: > > Hi, > >>>>>>> v=0 >>>>>>> o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 >>>>>>> host.anywhere.com >>>>>>> t=0 0 >>>>>>> m=audio 49170 RTP/AVP 96 >>>>>>> a=rtpmap:96 AMR-WB/16000 >>>>>>> m=audio 49170 RTP/AVP ??? >>>>>>> a=rtpmap:??? AMR-WB/16000 >>>>>> >>>>>> Not sure I get your point. You can have two different payload types that map to the same payload format in a single RTP session, since >>>>>> you can always distinguish what payload format is intended. You can't have the same payload type mapping to two different payload >>>>>> formats in a single RTP session, since you can't then infer what payload format was meant. >>>>> >>>>> Please not that both PTs map to the SAME payload format :) >>>> >>>> I thought I addressed that in my reply. >>> >>> I am not sure you did - at least I didn't get it :) >>> >>> Again, my understanding of what you said is that, for any payload format within an RTP session, the PT value has to be unique. >> >> Correct. >> >>> In the example above the same payload format, within the same RTP session, is used in two separate m- lines. But, I still can't use the same PT value for both m- lines, even if the payload format is the same, can I? > >> Why not? I don't see any problem mapping the same payload type to the exact same payload format in two different m= lines. > > But, when I receive media with that payload format, how do I know to which m- line it "belongs", as the same PT value is used for both m- lines? The PT can be viewed as method of last resort for associating a packet with an m-line, because the PT is the one thing that could be used for that association that you *must* specify in RTP. Everything else that *could* be used (e.g., SSRC) is optional. So if nothing else is present in the SDP that could be used then the PTs need to be unique per-m-line. But if something else is present, then it is no longer necessary that the PTs be unique. Thanks, Paul From pkyzivat@alum.mit.edu Mon May 27 12:08:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6960221F96C8 for ; Mon, 27 May 2013 12:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbwkaRtW3Rcz for ; Mon, 27 May 2013 12:08:31 -0700 (PDT) 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 8543B21F96C6 for ; Mon, 27 May 2013 12:08:31 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id gzTq1l00316LCl05378W5N; Mon, 27 May 2013 19:08:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id h78W1l00R3ZTu2S3S78W4V; Mon, 27 May 2013 19:08:30 +0000 Message-ID: <51A3AF2A.6030302@alum.mit.edu> Date: Mon, 27 May 2013 15:08:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Colin Perkins References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> <51A39870.7040708@alum.mit.edu> <6E11F505-6808-4E09-9359-8494B795BEDD@csperkins.org> In-Reply-To: <6E11F505-6808-4E09-9359-8494B795BEDD@csperkins.org> 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=1369681710; bh=BApAtsGn0VXs5i3ayWCLbAjObdInRtghHXywQ3+o4dQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kf7XfaK2PIQxJQ/clwLM+cowREazgUaKAVmPdEjmXZ03hzwSKyp4ldyhRhouumUsT 4JZetDALC5mKXjAQ3oa/9uwLLdI9fEKBizX+w1PwoA0UCq5CB54BEeeLSCdh8b949b 4Dr7vwnSJyUfO8n3gwjcYgIviC2wqGJ/NSNuQmuwUcF2VzUYhh2R9erVvfnCM4Rb9k uYQ75b9wkGYt+xhSMiVXO245ZijFMQmZfBd6o41U6AaFwZ0kySc6Xe/x0C7rzvzbU1 5jcnwoVh8zWMyk8f41k/6GRa7LgxW9WW/sC5HIsS4J6cCkZ4GIo8Ym6fznULow+9pt 0JF+jxrTpMoAg== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 19:08:48 -0000 On 5/27/13 2:08 PM, Colin Perkins wrote: > Paul, > > On 27 May 2013, at 18:31, Paul Kyzivat wrote: >> Colin, >> >> (I guess you know I am naive about RTP, so take this with a grain of salt.) >> >> In the below, you first split by SSRC. Then later you map to codec. That seems to suggest that each SSRC might have a unique mapping from PT to codec. Did you intend that? > > That's not how RTP has worked historically. The mapping from payload type to payload format has always been done on a per-RTP session basis, with a static mapping for some types, and a dynamic binding via SDP for others. Sure, I understand that. There was no way to describe that in SDP, so of course it wasn't done that way. The introduction of bundling makes it possible to describe more possibilities. So that it becomes necessary to decide which ones will now be valid and which will not. I asked because it wasn't clear. I think things can be made to work either way. If this is to be illegal, then the rules for forming bundles should say so. >> I also don't understand below how you expect unknown SSRCs to be handled. ISTM that the flow you show could result in establishing a bunch of state for each received SSRC, whether that SSRC is of interest or not. > > If you receive RTP and/or RTCP packets you need to keep some state for that SSRC. At least, you need to record the SSRC as in-use so you can avoid collisions, and you need to send RTCP reports for that SSRC. The state requirements for this are small (tens of bytes per SSRC). If you care about decoding and rendering the source there is more state, of course, but you only need that if you're rendering their media. > > You also need to be slightly smart to prevent DoS attacks if the other side decides to send you a stream of packets with a different, random, SSRC in each, but that's just basic robustness, and there are plenty of other ways to DoS a poorly engineered receiver at the RTP layer without playing tricks with SSRCs. > >> In some cases it may be that specific SSRCs are expected, and others can be ignored (or whatever). In other cases the recipient may not know what SSRCs to expect, but may have some other way of deciding which it wants to process. > > Sure - if you know what SSRCs you're expecting, you can pre-populate some of the state at the RTP level, and tell that layer that unknown SSRCs can be discarded. None of that changes the basic approach to de-multiplexing. > >> That was the point of my thread about associating packets to m-lines. If you can at least associate a packet with one of the bundled m-lines, even if it is by a means other than SSRC, then it becomes easier to decide what to do with it. For instance, I think Cullen intends that in plan A you could associate packets with m-lines via the PT, and then for each m-line process only packets for the most recently seen SSRC. (So when a new SSRC is received, drop all state for the prior SSRC and establish a new state for the new one.) > > I would suggest instead: de-multiplex into sources based on the SSRC and keep state for those according to the RTP timing rules. If you want to associate sources with m= lines via the PT, and determine what to render based on most recently active, that works fine, and works with all the various RTP and RTCP extensions (unlike de-multiplexing sources based on the PT), and gives you many more possible sources since the SSRC space is larger than the PT space. > >> The same approach can work using a header extension identifying a clue capture encoding to map to an m-line. When doing that, it won't be necessary for the PT to be unique across m-lines. > > The combination of an RTP Header Extension and/or RTCP SDES packet to identify an m= line would also work, and associates with the stream based on the SSRC. You don't need to use the PT to demultiplex for this. One of my points is that if SSRC and/or header extension value is known in advance, then putting that in the SDP and using it to associate to an m-line can relax the requirement that PTs be unique per-m-line. That makes it possible to support more m-lines in a bundle. This could be advantageous for plan A. Thanks, Paul > Colin > > > >> Thanks, >> Paul >> >> On 5/27/13 9:57 AM, Colin Perkins wrote: >>> I don't agree with the phrasing about "packet processing pipelines", but can't tell if this is a terminology disagreement or a more fundamental disconnect. The way I see the demultiplexing logically working is: >>> >>> | >>> | packets >>> +-- v >>> | +----------+ >>> | |UDP socket| >>> A | +----------+ >>> | RTP || | | >>> | and RTCP || | +------> SCTP >>> | || +---------> STUN/ICE >>> +-- || >>> +-- || >>> | split by SSRC >>> | || || || >>> | || || || >>> B | +--+ +--+ +--+ >>> | |PB| |PB| |PB| Playout buffer, process RTCP, FEC, etc. >>> | +--+ +--+ +--+ >>> +-- | | | >>> +-- | / | >>> | +---+ | >>> | / | | >>> C | +--+ +--+ +--+ >>> | |CR| |CR| |CR| Codecs and rendering >>> | +--+ +--+ +--+ >>> +-- >>> >>> If your algorithm is for demultiplexing at layer C, i.e., to figure out what codec and rendering pipeline to use, then I think we're in agreement apart from terminology. >>> >>> For layer B, I believe the SSRC is the right thing to use to demultiplex, and fits with RTP and RTCP. This is where RTCP is processed, playout de-jitter buffering happens, FEC is processed, NACKs are sent, etc. It's logically independent of the decoding and rendering process since you can start filling your de-jitter buffer for an SSRC before you figure out if/how/where you're going to render that SSRC. >>> >>> For layer A, there was a clear-cut way of doing this with RTP, RTCP, and STUN. I haven't looked at SCTP enough to know how that affects things. I do think it's a logically separate issue, and should be documented separately to BUNDLE though, since it the same issues arise with non-bundled sessions. >>> >>> An implementation might merge these together, of course, but to avoid confusion the standards should be clear what level they're considering. >>> >>> Colin >>> >>> >>> >>> On 27 May 2013, at 14:15, Cullen Jennings (fluffy) wrote: >>>> Great - sounds like we agree this algorithm will work. >>>> >>>> On May 27, 2013, at 6:41 AM, Colin Perkins wrote: >>>> >>>>> I'm not sure I agree. >>>>> >>>>> As I said in my previous message to the list, if we are agreed that the m= lines in a BUNDLE group form a single RTP session, then I believe we need unique payload types across all m= lines. In this case, BUNDLE can simply say that regular RTP source demultiplexing based on the SSRC has to be performed, then the payload type can be used to match sources to m= lines for those applications that care about doing so. >>>>> >>>>> If we're not agreed that the m= lines in a BUNDLE group form a single RTP session, then we have a lot more to discuss... >>>>> >>>>> Colin >>>>> >>>>> >>>>> >>>>> On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: >>>>>> Here's is my proposal for roughly what the bundle draft should say about this demux topic >>>>>> >>>>>> Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows: >>>>>> >>>>>> 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping >>>>>> >>>>>> 2) If the PT type is uniquely identifies a mapping, use that to form the mapping >>>>>> >>>>>> 3) If application knows the SSRC the other side will use, use that to form the mapping >>>>>> >>>>>> 4) if there is no way to know which pipeline to pass it too, the packet MAY be discarded or the application MAY decide to buffer it until the mapping is known >>>>>> >>>>>> This is trivial to implement. It meets the requirements for Plan A, Plan B, UCIF, CLUE, and so on. >>>>>> >>>>>> We could swap the order of step 2 and 3, My thinking for this order was the only time it made any difference the order was if the PT were unique and indicated a different mapping than the SSRC. The only way this could happen is with a SSRC collision so the PT is the one that would be correct not the SSRC. If someone feels strongly the order of steps 2 and 3 should be the opposite way around, I can live with that. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>>> >>>>> >>>>> -- >>>>> Colin Perkins >>>>> http://csperkins.org/ >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 csp@csperkins.org Mon May 27 12:09:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E69721F96C7 for ; Mon, 27 May 2013 12:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.179 X-Spam-Level: X-Spam-Status: No, score=-106.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ-x74LwwsyV for ; Mon, 27 May 2013 12:08:57 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id A558C21F93EB for ; Mon, 27 May 2013 12:08:57 -0700 (PDT) Received: from [81.187.2.149] (port=37890 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh2mu-0004pA-5F; Mon, 27 May 2013 20:08:57 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51A3AAC3.9030905@alum.mit.edu> Date: Mon, 27 May 2013 20:08:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6EC91C7A-E0EE-4A2C-BF86-E2864DF7A4F3@csperkins.org> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <51A3AAC3.9030905@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 19:09:02 -0000 On 27 May 2013, at 19:49, Paul Kyzivat wrote: > On 5/27/13 2:29 PM, Colin Perkins wrote: >> What would that other characteristic be? The only thing you have is = the SSRC, and SDP doesn't scope "a=3Drtpmap:" lines to be per "a=3Dssrc:" = line, and RTP certainly doesn't treat payload types as per SSRC. >=20 > This is all part of defining the precise semantics of bundling! >=20 > In the example I gave below, what I am suggesting is that: >=20 > - SSRC 1111 is associated with m-line X, and SSRC 22222 is associated > with m-line Y. >=20 > - When a packet is received, it must first be associated with > an m-line. If it has SSRC=3D1111 then it can be associated with > m-line X. Then, m-line X gives the mapping of PT 96 to audio > and AMR. If it has SSRC=3D2222 then it can be associated with > m-line Y. Then, m-line Y gives the mapping of PT 96 to audio > and G.7291. (If a packet with some other SSRC is received > then the mapping to an m-line is unknown, unless we introduce > some other rule.) >=20 > - in some other example, if some PT is unique to a single m-line, > then a packet with that PT can be associated to that m-line. >=20 > Have I made myself clear yet? Yes, but I think that's the wrong approach.=20 When an RTP or RTCP packet arrives it first needs to be associated with = an RTP source (step B in the diagram in = http://www.ietf.org/mail-archive/web/mmusic/current/msg11251.html). That = RTP source then, if you care about such things, can be associated with = an m=3D line (step C in the diagram).=20 You can use some combination of the payload type and a=3Dssrc: lines to = perform the mapping at step C. That's fine. I'm arguing, however, that = step B is important for RTP to work right, and that we can't just map to = sources based on the payload type. --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Mon May 27 12:14:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC04521F967F for ; Mon, 27 May 2013 12:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+8hr-tYZFgU for ; Mon, 27 May 2013 12:13:57 -0700 (PDT) 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 917F421F93EF for ; Mon, 27 May 2013 12:13:54 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta04.westchester.pa.mail.comcast.net with comcast id h78D1l0040Fqzac547DtoL; Mon, 27 May 2013 19:13:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id h7Dt1l00u3ZTu2S3U7Dtne; Mon, 27 May 2013 19:13:53 +0000 Message-ID: <51A3B070.1090006@alum.mit.edu> Date: Mon, 27 May 2013 15:13:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> In-Reply-To: <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> 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=1369682033; bh=FBl85KnD0KAbZAhO+hHtP59qiJzQXE2n+HKwSZIZblw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gDm5nKcAWoi4Efe/u+/OmHAItAdcXMT43Yg3pSxG+B67VsOU3wmFs/c+VUKkT8G6k rJY+wPcNSEIzcRNuhG5xJsmmbfV+EPii67/Ll8ffaRhJh4AbwbxYv/0mTtIaV0DJfw GE3FsaEuYfdTCBx231AjtOjE7rApLK3LHb33LJuEkiC8XX8LMgEGL9JO8ARJ6eY48w e7t8ms2eOXzGnx6DASefSF8WbYuvmc/eYnKLs9LNAYTDGdRU27p+Khd6K3Dbm+GWQS qza6+Ww8zDOd6IwMNBu08EWi76qw4oQaw+aRaZvp8uHT/cDFYl7hSc/HbbqkV3WdTo WCRzquki2iBlA== Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 19:14:02 -0000 On 5/27/13 2:52 PM, Colin Perkins wrote: >>>> In the example above the same payload format, within the same RTP session, is used in two separate m- lines. But, I still can't use the same PT value for both m- lines, even if the payload format is the same, can I? >> >>> Why not? I don't see any problem mapping the same payload type to the exact same payload format in two different m= lines. >> >> But, when I receive media with that payload format, how do I know to which m- line it "belongs", as the same PT value is used for both m- lines? > > You don't. If you care about that, you need to either use distinct PT values for each m= line, or signal SSRCs. I assert that if you don't care about associating a packet to a particular m-line in a bundle that you don't need to use bundle. So if you used bundle, you must care, and so there must be a way to achieve that association. The reason you care is because doing so allows you to discover all the other things in that media section of the SDP that may be pertinent to this packet. Thanks, Paul From csp@csperkins.org Mon May 27 12:16:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3A721F8EA4 for ; Mon, 27 May 2013 12:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.205 X-Spam-Level: X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyHJXQHTpmFq for ; Mon, 27 May 2013 12:16:11 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8821821F8EAE for ; Mon, 27 May 2013 12:16:10 -0700 (PDT) Received: from [81.187.2.149] (port=39507 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh2ts-0005Tu-0c; Mon, 27 May 2013 20:16:09 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51A3AF2A.6030302@alum.mit.edu> Date: Mon, 27 May 2013 20:16:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> <51A39870.7040708@alum.mit.edu> <6E11F505-6808-4E09-9359-8494B795BEDD@csperkins.org> <51A3AF2A.6030302@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 19:16:16 -0000 On 27 May 2013, at 20:08, Paul Kyzivat wrote: > On 5/27/13 2:08 PM, Colin Perkins wrote: >> Paul, >>=20 >> On 27 May 2013, at 18:31, Paul Kyzivat wrote: >>> Colin, >>>=20 >>> (I guess you know I am naive about RTP, so take this with a grain of = salt.) >>>=20 >>> In the below, you first split by SSRC. Then later you map to codec. = That seems to suggest that each SSRC might have a unique mapping from PT = to codec. Did you intend that? >>=20 >> That's not how RTP has worked historically. The mapping from payload = type to payload format has always been done on a per-RTP session basis, = with a static mapping for some types, and a dynamic binding via SDP for = others. >=20 > Sure, I understand that. There was no way to describe that in SDP, so = of course it wasn't done that way. >=20 > The introduction of bundling makes it possible to describe more = possibilities. So that it becomes necessary to decide which ones will = now be valid and which will not. >=20 > I asked because it wasn't clear. I think things can be made to work = either way. If this is to be illegal, then the rules for forming bundles = should say so. Without a wholesale revision to RTP and the signalling, I believe this = should be illegal (i.e., you MUST NOT map the same payload type to two = different payload formats in a single bundle group).=20 >>> I also don't understand below how you expect unknown SSRCs to be = handled. ISTM that the flow you show could result in establishing a = bunch of state for each received SSRC, whether that SSRC is of interest = or not. >>=20 >> If you receive RTP and/or RTCP packets you need to keep some state = for that SSRC. At least, you need to record the SSRC as in-use so you = can avoid collisions, and you need to send RTCP reports for that SSRC. = The state requirements for this are small (tens of bytes per SSRC). If = you care about decoding and rendering the source there is more state, of = course, but you only need that if you're rendering their media. >>=20 >> You also need to be slightly smart to prevent DoS attacks if the = other side decides to send you a stream of packets with a different, = random, SSRC in each, but that's just basic robustness, and there are = plenty of other ways to DoS a poorly engineered receiver at the RTP = layer without playing tricks with SSRCs. >>=20 >>> In some cases it may be that specific SSRCs are expected, and others = can be ignored (or whatever). In other cases the recipient may not know = what SSRCs to expect, but may have some other way of deciding which it = wants to process. >>=20 >> Sure - if you know what SSRCs you're expecting, you can pre-populate = some of the state at the RTP level, and tell that layer that unknown = SSRCs can be discarded. None of that changes the basic approach to = de-multiplexing. >>=20 >>> That was the point of my thread about associating packets to = m-lines. If you can at least associate a packet with one of the bundled = m-lines, even if it is by a means other than SSRC, then it becomes = easier to decide what to do with it. For instance, I think Cullen = intends that in plan A you could associate packets with m-lines via the = PT, and then for each m-line process only packets for the most recently = seen SSRC. (So when a new SSRC is received, drop all state for the prior = SSRC and establish a new state for the new one.) >>=20 >> I would suggest instead: de-multiplex into sources based on the SSRC = and keep state for those according to the RTP timing rules. If you want = to associate sources with m=3D lines via the PT, and determine what to = render based on most recently active, that works fine, and works with = all the various RTP and RTCP extensions (unlike de-multiplexing sources = based on the PT), and gives you many more possible sources since the = SSRC space is larger than the PT space. >>=20 >>> The same approach can work using a header extension identifying a = clue capture encoding to map to an m-line. When doing that, it won't be = necessary for the PT to be unique across m-lines. >>=20 >> The combination of an RTP Header Extension and/or RTCP SDES packet to = identify an m=3D line would also work, and associates with the stream = based on the SSRC. You don't need to use the PT to demultiplex for this. >=20 > One of my points is that if SSRC and/or header extension value is = known in advance, then putting that in the SDP and using it to associate = to an m-line can relax the requirement that PTs be unique per-m-line. = That makes it possible to support more m-lines in a bundle. This could = be advantageous for plan A. I don't see any problem using the a=3Dssrc: or RTP header extension = based methods to determine what m=3D line an RTP source maps to. I don't = think you need to relax the requirement that PTs be unique per m=3D line = to do this.=20 As I said in the other thread, how you decide how to render an RTP = source is separate to how you demultiplex RTP sources. Most of this = confusion is coming from trying to combine the two operations. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 27 12:24:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7746521F96C1 for ; Mon, 27 May 2013 12:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdvaiwxKNSYj for ; Mon, 27 May 2013 12:24:28 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id DA65921F96AD for ; Mon, 27 May 2013 12:24:27 -0700 (PDT) Received: from [81.187.2.149] (port=41046 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh31u-0000er-7f; Mon, 27 May 2013 20:24:27 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51A3B070.1090006@alum.mit.edu> Date: Mon, 27 May 2013 20:24:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 19:24:39 -0000 On 27 May 2013, at 20:13, Paul Kyzivat wrote: > On 5/27/13 2:52 PM, Colin Perkins wrote: >>>>> In the example above the same payload format, within the same RTP = session, is used in two separate m- lines. But, I still can't use the = same PT value for both m- lines, even if the payload format is the same, = can I? >>>=20 >>>> Why not? I don't see any problem mapping the same payload type to = the exact same payload format in two different m=3D lines. >>>=20 >>> But, when I receive media with that payload format, how do I know to = which m- line it "belongs", as the same PT value is used for both m- = lines? >>=20 >> You don't. If you care about that, you need to either use distinct PT = values for each m=3D line, or signal SSRCs. >=20 > I assert that if you don't care about associating a packet to a = particular m-line in a bundle that you don't need to use bundle. Sure. > So if you used bundle, you must care, and so there must be a way to = achieve that association. Sure. > The reason you care is because doing so allows you to discover all the = other things in that media section of the SDP that may be pertinent to = this packet. Sure.=20 But, again, let's keep the discussion of mapping RTP/RTCP packets onto = RTP sources separate from the discussion of how to map the RTP sources = onto m=3D lines. The former is well-defined by RTP, the latter is not = yet defined. Proposals for solving the latter shouldn't start with "when = a packet arrives, first do this", because that's the domain of the RTP = source de-multiplexing process; rather they should consider "how do we = map this RTP-level source (i.e., a sequence of RTP and RTCP packets = identified by SSRC, whether signalled or not) onto an m=3D line".=20 --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Mon May 27 12:28:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E6721F96D0 for ; Mon, 27 May 2013 12:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V56OVVbvd8sj for ; Mon, 27 May 2013 12:27:59 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 334C721F96DD for ; Mon, 27 May 2013 12:27:58 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta14.westchester.pa.mail.comcast.net with comcast id h6AB1l00317dt5G5E7Tylc; Mon, 27 May 2013 19:27:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id h7Ty1l00A3ZTu2S3Z7TyWA; Mon, 27 May 2013 19:27:58 +0000 Message-ID: <51A3B3BD.4010004@alum.mit.edu> Date: Mon, 27 May 2013 15:27:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Colin Perkins References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <51A3AAC3.9030905@alum.mit.edu> <6EC91C7A-E0EE-4A2C-BF86-E2864DF7A4F3@csperkins.org> In-Reply-To: <6EC91C7A-E0EE-4A2C-BF86-E2864DF7A4F3@csperkins.org> 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=1369682878; bh=UUueJzQSbgiVvNKLn/GE7TPtc6DSTGkUAhOtX5PpJus=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kXsHkSWn5SW+U7fjr6gMLhORxeakAeF5Yir/nc0IPIGM4IXnzXJM+8NrcuzfDr/PZ JiA6154UnLv2auF13hwzQhsAQa+dmA3r2mtBgb4bVMidOhk3zW9tSoNFdVWqEbPFSm cimiKEZ60etPFXpLzE03x4RTINLKRThru1irbHCa9AVhOAGX/DSfog3zdJwcgvytBz UpPOBCw25+zRGYpMVxQodbZ8+cJ2t+UKG/R8ZAP2gUXTU56vhw5dgUdk0PRjOG1vAf i1cXcABxVHdJpRhEnLivBD1dbX4immQY0mRDQrmtTPB4CkBRUqRlLSqU2FXZB7f/+V Xe4+ocKIOF+0w== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 19:28:04 -0000 Colin, On 5/27/13 3:08 PM, Colin Perkins wrote: > On 27 May 2013, at 19:49, Paul Kyzivat wrote: >> On 5/27/13 2:29 PM, Colin Perkins wrote: >>> What would that other characteristic be? The only thing you have is the SSRC, and SDP doesn't scope "a=rtpmap:" lines to be per "a=ssrc:" line, and RTP certainly doesn't treat payload types as per SSRC. >> >> This is all part of defining the precise semantics of bundling! >> >> In the example I gave below, what I am suggesting is that: >> >> - SSRC 1111 is associated with m-line X, and SSRC 22222 is associated >> with m-line Y. >> >> - When a packet is received, it must first be associated with >> an m-line. If it has SSRC=1111 then it can be associated with >> m-line X. Then, m-line X gives the mapping of PT 96 to audio >> and AMR. If it has SSRC=2222 then it can be associated with >> m-line Y. Then, m-line Y gives the mapping of PT 96 to audio >> and G.7291. (If a packet with some other SSRC is received >> then the mapping to an m-line is unknown, unless we introduce >> some other rule.) >> >> - in some other example, if some PT is unique to a single m-line, >> then a packet with that PT can be associated to that m-line. >> >> Have I made myself clear yet? > > > Yes, but I think that's the wrong approach. I think what I am talking about can be tweaked to fit with what you are suggesting. (This is where my limited understanding of RTP causes me trouble.) I've been viewing B & C as a single black box. I've no problem with decomposing it. > When an RTP or RTCP packet arrives it first needs to be associated with an RTP source (step B in the diagram in http://www.ietf.org/mail-archive/web/mmusic/current/msg11251.html). That RTP source then, if you care about such things, can be associated with an m= line (step C in the diagram). OK. Based on the other things you have said, this seems fine. > You can use some combination of the payload type and a=ssrc: lines to perform the mapping at step C. That's fine. Then all the logic to bind the packet to an m-line can appear in step C. I *think* it really only needs to be done once per SSRC, the first time the SSRC is seen. But maybe it can't be done by the first packet that arrives for that SSRC. (Certainly that may be so if the SSRC is first seen an an RTCP packet.) > I'm arguing, however, that step B is important for RTP to work right, and that we can't just map to sources based on the payload type. OK. Thanks, Paul From pkyzivat@alum.mit.edu Mon May 27 12:37:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A041721F967F for ; Mon, 27 May 2013 12:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l89fBqtxCsk0 for ; Mon, 27 May 2013 12:37:09 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id B225E21F966F for ; Mon, 27 May 2013 12:37:09 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta14.westchester.pa.mail.comcast.net with comcast id h6jh1l00B1wpRvQ5E7d8gV; Mon, 27 May 2013 19:37:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id h7d81l00v3ZTu2S3e7d8bX; Mon, 27 May 2013 19:37:08 +0000 Message-ID: <51A3B5E3.6010404@alum.mit.edu> Date: Mon, 27 May 2013 15:37:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Colin Perkins References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> <51A39870.7040708@alum.mit.edu> <6E11F505-6808-4E09-9359-8494B795BEDD@csperkins.org> <51A3AF2A.6030302@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=1369683428; bh=3kbh3WnT1OW9qmwWbvQl9AsVikmWGdplwPDAWnZXGHk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mooIYNG2p4lVWFBsdVYZ4CNKBGqAvk1+L/b0k87PTVefCW46NyBlAAkpyYLWYp3BM RjasYvRaf458V0tU81AwkWlmjY+LKAbmunVLqlT6LMc5PE9bww037DJZQN4+w1X5KT B5BlfcYChwqeXYwhv3rt6iViES4GNEW9UDxde7jZvs/mU007+uC5PfeVu1w8pL8G44 F8aaOqGO4Whz7t6Hq0ffnvxkSbhkT8GAxqhw4rGxLgjCamvot1h/P7/UW5XWA3AiHY CJMalDrlQsBtUPhzdY+LypIe4U1GahuRI6ysv86F+b2KsXGJgfwaqBSbYRRLfUW/5G 0Fp8d8EjBlsQw== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 19:37:15 -0000 Colin, On 5/27/13 3:16 PM, Colin Perkins wrote: > On 27 May 2013, at 20:08, Paul Kyzivat wrote: >> On 5/27/13 2:08 PM, Colin Perkins wrote: >>> Paul, >>> >>> On 27 May 2013, at 18:31, Paul Kyzivat wrote: >>>> Colin, >>>> >>>> (I guess you know I am naive about RTP, so take this with a grain of salt.) >>>> >>>> In the below, you first split by SSRC. Then later you map to codec. That seems to suggest that each SSRC might have a unique mapping from PT to codec. Did you intend that? >>> >>> That's not how RTP has worked historically. The mapping from payload type to payload format has always been done on a per-RTP session basis, with a static mapping for some types, and a dynamic binding via SDP for others. >> >> Sure, I understand that. There was no way to describe that in SDP, so of course it wasn't done that way. >> >> The introduction of bundling makes it possible to describe more possibilities. So that it becomes necessary to decide which ones will now be valid and which will not. >> >> I asked because it wasn't clear. I think things can be made to work either way. If this is to be illegal, then the rules for forming bundles should say so. > > Without a wholesale revision to RTP and the signalling, I believe this should be illegal (i.e., you MUST NOT map the same payload type to two different payload formats in a single bundle group). > >>>> I also don't understand below how you expect unknown SSRCs to be handled. ISTM that the flow you show could result in establishing a bunch of state for each received SSRC, whether that SSRC is of interest or not. >>> >>> If you receive RTP and/or RTCP packets you need to keep some state for that SSRC. At least, you need to record the SSRC as in-use so you can avoid collisions, and you need to send RTCP reports for that SSRC. The state requirements for this are small (tens of bytes per SSRC). If you care about decoding and rendering the source there is more state, of course, but you only need that if you're rendering their media. >>> >>> You also need to be slightly smart to prevent DoS attacks if the other side decides to send you a stream of packets with a different, random, SSRC in each, but that's just basic robustness, and there are plenty of other ways to DoS a poorly engineered receiver at the RTP layer without playing tricks with SSRCs. >>> >>>> In some cases it may be that specific SSRCs are expected, and others can be ignored (or whatever). In other cases the recipient may not know what SSRCs to expect, but may have some other way of deciding which it wants to process. >>> >>> Sure - if you know what SSRCs you're expecting, you can pre-populate some of the state at the RTP level, and tell that layer that unknown SSRCs can be discarded. None of that changes the basic approach to de-multiplexing. >>> >>>> That was the point of my thread about associating packets to m-lines. If you can at least associate a packet with one of the bundled m-lines, even if it is by a means other than SSRC, then it becomes easier to decide what to do with it. For instance, I think Cullen intends that in plan A you could associate packets with m-lines via the PT, and then for each m-line process only packets for the most recently seen SSRC. (So when a new SSRC is received, drop all state for the prior SSRC and establish a new state for the new one.) >>> >>> I would suggest instead: de-multiplex into sources based on the SSRC and keep state for those according to the RTP timing rules. If you want to associate sources with m= lines via the PT, and determine what to render based on most recently active, that works fine, and works with all the various RTP and RTCP extensions (unlike de-multiplexing sources based on the PT), and gives you many more possible sources since the SSRC space is larger than the PT space. >>> >>>> The same approach can work using a header extension identifying a clue capture encoding to map to an m-line. When doing that, it won't be necessary for the PT to be unique across m-lines. >>> >>> The combination of an RTP Header Extension and/or RTCP SDES packet to identify an m= line would also work, and associates with the stream based on the SSRC. You don't need to use the PT to demultiplex for this. >> >> One of my points is that if SSRC and/or header extension value is known in advance, then putting that in the SDP and using it to associate to an m-line can relax the requirement that PTs be unique per-m-line. That makes it possible to support more m-lines in a bundle. This could be advantageous for plan A. > > I don't see any problem using the a=ssrc: or RTP header extension based methods to determine what m= line an RTP source maps to. > I don't think you need to relax the requirement that PTs be unique per m= line to do this. I agree there is no *need* to relax the PT uniqueness requirement in order to map the packets (or sources if you prefer) to m-lines. But (at least with plan A) there is a concern that there will be insufficient PTs to keep them unique per-m-line. What I am saying is that if you do the mapping to m-line *before* the mapping from PT to payload format, then you *can* relax the PT uniqueness requirement. This isn't violating precedent, because there is no precedent. Neither the problem nor the solution are present without bundling. Thanks, Paul > As I said in the other thread, how you decide how to render an RTP source is separate to how you demultiplex RTP sources. Most of this confusion is coming from trying to combine the two operations. > From csp@csperkins.org Mon May 27 13:12:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEBD21F9684 for ; Mon, 27 May 2013 13:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1RO+A8OvMaP for ; Mon, 27 May 2013 13:12:54 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6398A21F8FA5 for ; Mon, 27 May 2013 13:12:54 -0700 (PDT) Received: from [81.187.2.149] (port=46150 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uh3mh-0007gG-Kq; Mon, 27 May 2013 21:12:53 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51A3B5E3.6010404@alum.mit.edu> Date: Mon, 27 May 2013 21:12:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79E64A40-452B-47C3-85B1-F037FD231E0F@csperkins.org> References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> <51A39870.7040708@alum.mit.edu> <6E11F505-6808-4E09-9359-8494B795BEDD@csperkins.org> <51A3AF2A.6030302@alum.mit.edu> <51A3B5E3.6010404@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 20:12:59 -0000 On 27 May 2013, at 20:37, Paul Kyzivat wrote: ... > I agree there is no *need* to relax the PT uniqueness requirement in = order to map the packets (or sources if you prefer) to m-lines. >=20 > But (at least with plan A) there is a concern that there will be = insufficient PTs to keep them unique per-m-line. >=20 > What I am saying is that if you do the mapping to m-line *before* the = mapping from PT to payload format, then you *can* relax the PT = uniqueness requirement. That would mean using signalled SSRC values to map from an RTP source to = an m=3D line. Once you've done that, though, it's not clear that you = need that many unique payload types (since if you're using the same = payload format in two m=3D lines you can use the same payload type in = both, when using a signalled SSRC to distinguish the m=3D lines).=20 > This isn't violating precedent, because there is no precedent. Neither = the problem nor the solution are present without bundling. There's precedent in that the RTP specifications assume the mapping is = fixed in a single RTP session.=20 --=20 Colin Perkins http://csperkins.org/ From harald@alvestrand.no Mon May 27 13:49:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D216D21F8EB1 for ; Mon, 27 May 2013 13:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igMs3pIiIAcE for ; Mon, 27 May 2013 13:49:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A3B2721F8EAF for ; Mon, 27 May 2013 13:49:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C67339E129 for ; Mon, 27 May 2013 22:49:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a16qllBAqj8L for ; Mon, 27 May 2013 22:49:14 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:617e:a2cf:458e:2a0d] (unknown [IPv6:2001:470:de0a:27:617e:a2cf:458e:2a0d]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DC45539E0D7 for ; Mon, 27 May 2013 22:49:13 +0200 (CEST) Message-ID: <51A3C6C9.6050606@alvestrand.no> Date: Mon, 27 May 2013 22:49:13 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] The pick-a-config debate - perhaps an useful example X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 20:49:23 -0000 I don't like the name "demux", as I've said before. Neither do I like the term "select an m-line", because I don't think that's the only possible solution to the problem we're facing. I think the problem we're facing can be illustrated like this: What resolution is permitted in the following config? (apologies in advance for syntactic brokenness) a=group:BUNDLE foo bar m=video a=mid:foo a=imageattr:* [x=160,y=100] a=rtpmap:96:vp8 m=video a=mid:bar a=imageattr:* [x=640,y=480] a=rtpmap:96:vp8 Now, the video is the same. The payload type is the same. But the sender of this SDP has stated an opinion about the image size that is in the form of M-line-related attributes. Query: Is this the problem we're discussing? Some solutions that have been suggested: My interpretation of Plan A: Create two payload types that both mean "vp8". m=video a=imageattr:* [x=160,y=100] a=rtpmap:96:vp8 m=video a=imageattr:* [x=640,y=480] a=rtpmap:97:vp8 My interpretation of a pure Plan B: Do SSRC-related signalling. m=video a=ssrc:4378 imageattr:* [x=160,y=100] a=rtpmap:96:vp8 a=ssrc:9736 imageattr:* [x=640,y=480] (we don't need a second m-line here) For this particular attribute, there's also a plan with features of both: m=video a=imageattr:96 [x=160,y=100] a=rtpmap:96:vp8 a=imageattr:97 [x=640,y=480] a=rtpmap:97:vp8 but this one works only with a=imageattr because imageattr has a payload type. A fourth solution is to decode the first frame, figure out how big it is, and see if we have a config it fits into. That sounds bizarre. A fifth solution is to declare a complete ban on conflicting attributes in bundled M-lines. Just Don't Do It. That reduces the expressive power of M-lines to what I was thinking about when I wrote the first bundle proposal: It's a way to describe a single RTP session, and what you can't say about a single RTP session, you can't say about a bundle describing a single RTP session either. But that might not be what people want. From pkyzivat@alum.mit.edu Mon May 27 14:23:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9225121F8EC2 for ; Mon, 27 May 2013 14:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfa9gkEJMB3Y for ; Mon, 27 May 2013 14:23:24 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89421F8EBE for ; Mon, 27 May 2013 14:23:24 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta14.westchester.pa.mail.comcast.net with comcast id h8u41l0061GhbT85E9PPZv; Mon, 27 May 2013 21:23:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id h9PP1l00g3ZTu2S3T9PPh6; Mon, 27 May 2013 21:23:23 +0000 Message-ID: <51A3CECA.1080705@alum.mit.edu> Date: Mon, 27 May 2013 17:23:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Colin Perkins References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> <51A39870.7040708@alum.mit.edu> <6E11F505-6808-4E09-9359-8494B795BEDD@csperkins.org> <51A3AF2A.6030302@alum.mit.edu> <51A3B5E3.6010404@alum.mit.edu> <79E64A40-452B-47C3-85B1-F037FD231E0F@csperkins.org> In-Reply-To: <79E64A40-452B-47C3-85B1-F037FD231E0F@csperkins.org> 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=1369689803; bh=uLXca/WNrGxEzWfOu60bI3druwqdNaxmzwzWgNp/7Ok=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=flIxYEuQZGqFjWZMgT+6aSQg/Bq6HNfwQUlkgEQiM4gcGoIPUI6wtY0Tq7j9jo1h2 mYSE0IO6qyrBS37BgM1PvmNMFbduBu+sIotzMqMr0cmS0RvJjzqTD+zH0rrbAj4HNj np5FgEBmHWy/eqPRuzl3rPyeJnihyuMVsttHu9DD4Igbm0vMQ+QvjxqXnCLJ5gpuz0 auSV7tDUDE4IKrd6C+EeVfIXyUSSyXK8msm0O4QKzblAnHOnum7wV/eO2/7lcpJ7hx 6l/sP0umN7/ql1UGU94ML6pRgA6z1VI/ht7JzHYHt5Ogxy4BD4xRj8quYhoVBpRt0I HnfFsNb9ezMcg== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 21:23:30 -0000 On 5/27/13 4:12 PM, Colin Perkins wrote: > On 27 May 2013, at 20:37, Paul Kyzivat wrote: > ... >> I agree there is no *need* to relax the PT uniqueness requirement in order to map the packets (or sources if you prefer) to m-lines. >> >> But (at least with plan A) there is a concern that there will be insufficient PTs to keep them unique per-m-line. >> >> What I am saying is that if you do the mapping to m-line *before* the mapping from PT to payload format, then you *can* relax the PT uniqueness requirement. > > That would mean using signalled SSRC values to map from an RTP source to an m= line. Once you've done that, though, it's not clear that you need that many unique payload types (since if you're using the same payload format in two m= lines you can use the same payload type in both, when using a signalled SSRC to distinguish the m= lines). Yes, that may be true. If that is sufficient for people its ok with me. But it does still mean, in response to Christer, that the same PT might be in multiple m-lines in the bundle. >> This isn't violating precedent, because there is no precedent. Neither the problem nor the solution are present without bundling. > > There's precedent in that the RTP specifications assume the mapping is fixed in a single RTP session. There is also precedent that you don't have audio and video in the same RTP session. We are going to be breaking *some* precedents. Its just a matter of which ones are sacred. Thanks, Paul From bernard_aboba@hotmail.com Mon May 27 17:10:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2CE21F9021 for ; Mon, 27 May 2013 17:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDgtPbb2lqyI for ; Mon, 27 May 2013 17:10:34 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3CF21F8FDD for ; Mon, 27 May 2013 17:10:34 -0700 (PDT) Received: from BLU169-W5 ([65.55.111.72]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 May 2013 17:10:34 -0700 X-TMN: [LX8nOgmGmD8YwVwblDMhJn7foVDtrz2M] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_75c751b4-5f9b-4886-bca6-4dd4da63ba7c_" From: Bernard Aboba To: Colin Perkins Date: Mon, 27 May 2013 17:10:33 -0700 Importance: Normal In-Reply-To: References: <519E5F54.3000806@alum.mit.edu> <51A381E2.9040203@alum.mit.edu>, MIME-Version: 1.0 X-OriginalArrivalTime: 28 May 2013 00:10:34.0445 (UTC) FILETIME=[C60DDFD0:01CE5B37] Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 00:10:40 -0000 --_75c751b4-5f9b-4886-bca6-4dd4da63ba7c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Colin Perkins said:=20 RTCP operates at a different level=2C so it's not clear why it needs to be = bound to an m=3D line. Use the SSRC to group related RTP and RTCP packets a= ccording to source=2C and match them to a de-jitter buffer and the state fo= r RTCP processing. Use the PT to match those sources with the payload forma= t=2C m=3D line and the corresponding decoding and rendering context. [BA] I believe that the stats API requires the mapping of received RTCP pac= kets to a peerConnection object. Without BUNDLE=2C there is no issue. Wi= th BUNDLE and without a=3Dssrc lines=2C it is possible to receive RTCP RRs = from SSRCs that have not yet sent packets=2C so that it wouldn't be possibl= e yet to group the RTCP and RTP packets according to source and match those= sources with the PT and payload format. So if you had more than one peerC= onnection object=2C it might not be clear which object the RTCP packet rela= ted to.=20 Colin also said:=20 Match the RTCP to the RTP based on the SSRC=2C and process it. There is no = need to discard the RTCP in this case. [BA] What if no RTP has been received from that SSRC=2C but an RTCP RR arri= ves? This is the case I was referring to. I agree that there is no need = to discard the RTCP assuming that an RTP packet from that SSRC arrives firs= t=2C permitting a mapping of SSRC to PT=2C corresponding m line and peerCon= nection object. = --_75c751b4-5f9b-4886-bca6-4dd4da63ba7c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Colin Perkins said: =3B
<= br>
RTCP operates at a different level=2C so it's not clear why it need= s to be bound to an m=3D line. Use the SSRC to group related RTP and RTCP p= ackets according to source=2C and match them to a de-jitter buffer and the = state for RTCP processing. Use the PT to match those sources with the paylo= ad format=2C m=3D line and the corresponding decoding and rendering context= .

[BA] I believe that the stats API requires the m= apping of received RTCP packets to a peerConnection object.  =3B Withou= t BUNDLE=2C there is no issue.  =3BWith BUNDLE and without a=3Dssrc lin= es=2C it is possible to receive RTCP RRs from SSRCs that have not yet sent = packets=2C so that it wouldn't be possible yet to group the RTCP and RTP pa= ckets according to source and match those sources with the PT and payload f= ormat.  =3BSo if you had more than one peerConnection object=2C it migh= t not be clear which object the RTCP packet related to. =3B
<= br>
Colin also said: =3B

Match the RTCP to the = RTP based on the SSRC=2C and process it. There is no need to discard the RT= CP in this case.

[BA] What if no RTP has been rece= ived from that SSRC=2C but an RTCP RR arrives?  =3BThis is the case I w= as referring to.  =3B I agree that there is no need to discard the RTCP= assuming that an RTP packet from that SSRC arrives first=2C permitting a m= apping of SSRC to PT=2C corresponding m line and peerConnection object.
= --_75c751b4-5f9b-4886-bca6-4dd4da63ba7c_-- From christer.holmberg@ericsson.com Tue May 28 00:58:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFACB21F925A for ; Tue, 28 May 2013 00:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhGyTnFWZ+xV for ; Tue, 28 May 2013 00:58:31 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5386121F91BF for ; Tue, 28 May 2013 00:58:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-76-51a463a56491 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BD.93.28930.5A364A15; Tue, 28 May 2013 09:58:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Tue, 28 May 2013 09:58:29 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Updated offer procedures Thread-Index: Ac5beKfpSruus8OIRHSvbTVCpmVX7Q== Date: Tue, 28 May 2013 07:58:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37A880@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvre7S5CWBBscvy1tMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGdduXWUuuMBTsWfxRuYGxhecXYwcHBICJhItvyS7GDmBTDGJ C/fWs3UxcnEICRxmlLj89QA7SEJIYAmjxIp13CD1bAIWEt3/tEHCIgLqEl/39jCD2MICmhLf Tl9hh4jrSWzcfoQVpBzE/rOuFCTMIqAqMf3dIyYQm1fAV+L78ftgNiPQ2u+n1oDZzALiEree zGeCOEdAYsme88wQtqjEy8f/WCEuVpRY3i8HUa4jsWD3JzYIW1ti2cLXzBDjBSVOznzCMoFR eBaSqbOQtMxC0jILScsCRpZVjOy5iZk56eWGmxiB4Xtwy2/dHYynzokcYpTmYFES59XjXRwo JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVF9dY/y1yUrn5/7GeiyrCI867pzmeJrzaobbxLC +bdP/WnReWpj7rvO9OdzW9f8m+jBXH2O53mrenjxjnm2HQxbPtrsuJzkWVC0XaXh1OfgBS+O 7n1m8UBOcvEKrmsTtW5v6F/rXslvNyMxR23lZ0mxJXxRW5b3/p7XI372vLtyvMIZ+Qk72HSV WIozEg21mIuKEwEX/hXILQIAAA== Subject: [MMUSIC] BUNDLE: Updated offer procedures X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 07:58:38 -0000 Hi, There has been some discussions about updated bundle offers, especially in = cases where a new m- line is added to a bundle group, or when a port-zero-m= -line within a bundle group is "taken back to use". In this e-mail, I refer= to both cases as "adding a new m- line". When the updated offer is sent, the offerer has two choices: 1) The port value of the new m- line is identical to the port values of the= other m- lines in the bundle: This should be rather straight forward. According to answer restriction #4,= the answerer can either accept the new m- line within the bundle group, or= reject the m- line by setting the port to zero. =20 2) The port value of the new m- line is NOT identical to the port values of= the other m- lines in the bundle: In this case, the answer has the possibility to remove the m- line from the= bundle group, as it has a individual port number in the offer. Now, there are two "sub cases": 2a) The new m- line(s) have individual port numbers, but the old m- lines h= ave the previously negotiated single bundle port value I guess this case is the one we need to focus most on. In my opinion, if the answerer accepts the new m- line, it must use the pre= viously negotiated bundle port. IF the offerer (or answerer) wants to re-ne= gotiate the bundle port, it must act according to 2b (see below). 2b) The new m- line(s), AND, the old ones, have individual port numbers In my opinion, this is a "bundle restart", where the port (and, then bundle= in general) is re-negotiated. Comments? Regards, Christer From csp@csperkins.org Tue May 28 03:11:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BE921F91B8 for ; Tue, 28 May 2013 03:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWD4wr2t4SOK for ; Tue, 28 May 2013 03:11:30 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id BA99521F85BF for ; Tue, 28 May 2013 03:11:29 -0700 (PDT) Received: from [130.209.247.112] (port=56627 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UhGsC-0004Ef-Rq; Tue, 28 May 2013 11:11:23 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: Date: Tue, 28 May 2013 11:11:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <77D67F21-E702-448C-9E67-DB59C9A5E0F9@csperkins.org> References: <519E5F54.3000806@alum.mit.edu> <51A381E2.9040203@alum.mit.edu>, To: Bernard Aboba X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 10:11:35 -0000 On 28 May 2013, at 01:10, Bernard Aboba wrote: > Colin Perkins said:=20 >> RTCP operates at a different level, so it's not clear why it needs to = be bound to an m=3D line. Use the SSRC to group related RTP and RTCP = packets according to source, and match them to a de-jitter buffer and = the state for RTCP processing. Use the PT to match those sources with = the payload format, m=3D line and the corresponding decoding and = rendering context. >=20 > [BA] I believe that the stats API requires the mapping of received = RTCP packets to a peerConnection object. Without BUNDLE, there is no = issue. With BUNDLE and without a=3Dssrc lines, it is possible to = receive RTCP RRs from SSRCs that have not yet sent packets, so that it = wouldn't be possible yet to group the RTCP and RTP packets according to = source and match those sources with the PT and payload format. So if = you had more than one peerConnection object, it might not be clear which = object the RTCP packet related to.=20 Agreed.=20 > Colin also said:=20 >> Match the RTCP to the RTP based on the SSRC, and process it. There is = no need to discard the RTCP in this case. >=20 > [BA] What if no RTP has been received from that SSRC, but an RTCP RR = arrives? This is the case I was referring to. I agree that there is = no need to discard the RTCP assuming that an RTP packet from that SSRC = arrives first, permitting a mapping of SSRC to PT, corresponding m line = and peerConnection object. Unless you've signalled SSRC values, you won't be able to map an RTCP = packet that arrives before the corresponding RTP packet onto an m=3D = line and peerConnection object. However, you'd know that the SSRC of the = RTCP packet existed, and is to be avoided for collisions, and you could = begin to setup some RTP layer state in the receiver. You'd also mention = the SSRC of the RTCP packet in the RTCP RR packets you send (this can be = a useful diagnostic if the other side is actually sending RTP, but = you're not receiving it for some reason; it's one of the conditions the = circuit breaker algorithm checks to detect some types of path failure).=20= In summary, you might not be able to make an RTCP packet that arrives = before the corresponding RTP packet available to the higher layers of = your application (depending on what was signalled), but there is useful = processing that can be done with that packet when it's received, and it = shouldn't be discarded.=20 --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Tue May 28 06:31:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D373321F8976 for ; Tue, 28 May 2013 06:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8ZMG2DysTKl for ; Tue, 28 May 2013 06:31:02 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 0656521F8956 for ; Tue, 28 May 2013 06:31:01 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta01.westchester.pa.mail.comcast.net with comcast id hPEf1l0021uE5Es51RX1mG; Tue, 28 May 2013 13:31:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id hRX11l00F3ZTu2S3cRX10B; Tue, 28 May 2013 13:31:01 +0000 Message-ID: <51A4B194.6010800@alum.mit.edu> Date: Tue, 28 May 2013 09:31:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <51A3C6C9.6050606@alvestrand.no> In-Reply-To: <51A3C6C9.6050606@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369747861; bh=kpfaKFMqVNr23w+p593vK8J1TonEAzq+Wck9vdEu9FM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GJYWxfFQ65LK9J+Jtn2IW0gYgJaYIHAw1jMr2v00VPLzFhTbDBvRZ8YTAHXVaL8oE ixbvde/P32RUK3cYDPQlTE6viinqUKX+lTdvLE81yRb4Cx8i3CL5UIZIT/oUWTsB9W LH/sMpEjsnO4ixikndagcwuoGX2mTa5Echjq+XDfmgiYdI5fbSWrY1UlfMveipVfPU 0uQvGadjXDQMTMYsAawwqkNmVHrqJjqBNug7W+cUcYfEjB7spy8IFVbh54+Kk2UPu5 +5+QrQGYozJz1pWAnHLF7oC1llROxUIJDNCR49FwORrfzMXdzD4qIoXMxmn1DQm6zO PGhH3GPVkgxBg== Subject: Re: [MMUSIC] The pick-a-config debate - perhaps an useful example X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 13:31:06 -0000 Harald, On 5/27/13 4:49 PM, Harald Alvestrand wrote: > I don't like the name "demux", as I've said before. > Neither do I like the term "select an m-line", because I don't think > that's the only possible solution to the problem we're facing. IMO "select an m-line" is not the whole problem, but it is part of the chosen solution. If we are going to use SDP, and in particular we are going to use the bundling of m-lines as a way to describe more complex usage of an RTP session, then it must be possible to associate packets with m-lines. (Or, as Colin prefers, to associate sources to m-lines based on what is received in the packets associated with a source.) Once that is done, it provides more data that can be used to solve whatever problem you want to solve - to associate sources with MediaStreamTracks or CLUE capture encodings, or whatever. > I think the problem we're facing can be illustrated like this: What > resolution is permitted in the following config? (apologies in advance > for syntactic brokenness) > > a=group:BUNDLE foo bar > > m=video > a=mid:foo > a=imageattr:* [x=160,y=100] > a=rtpmap:96:vp8 > > m=video > a=mid:bar > a=imageattr:* [x=640,y=480] > a=rtpmap:96:vp8 > > Now, the video is the same. The payload type is the same. But the sender > of this SDP has stated an opinion about the image size that is in the > form of M-line-related attributes. > > Query: Is this the problem we're discussing? It is a (small) piece of the problem. > Some solutions that have been suggested: > > My interpretation of Plan A: Create two payload types that both mean "vp8". > > m=video > a=imageattr:* [x=160,y=100] > a=rtpmap:96:vp8 > > m=video > a=imageattr:* [x=640,y=480] > a=rtpmap:97:vp8 > > My interpretation of a pure Plan B: Do SSRC-related signalling. > > m=video > a=ssrc:4378 imageattr:* [x=160,y=100] > a=rtpmap:96:vp8 > a=ssrc:9736 imageattr:* [x=640,y=480] > > (we don't need a second m-line here) > > For this particular attribute, there's also a plan with features of both: > > m=video > a=imageattr:96 [x=160,y=100] > a=rtpmap:96:vp8 > a=imageattr:97 [x=640,y=480] > a=rtpmap:97:vp8 > > but this one works only with a=imageattr because imageattr has a payload > type. As I am framing it (after some education by Colin), this can be accomplished by: - get a first packet with a particular SSRC - because it is new, set up a new "source" data structure for it - use info in the packet (e.g., SSRC and/or PT) to associate the source to a particular m-line in the bundle - use the imageattr(s) associated with that m-line to obtain the image size for this source Thanks, Paul > A fourth solution is to decode the first frame, figure out how big it > is, and see if we have a config it fits into. That sounds bizarre. > > A fifth solution is to declare a complete ban on conflicting attributes > in bundled M-lines. Just Don't Do It. > That reduces the expressive power of M-lines to what I was thinking > about when I wrote the first bundle proposal: It's a way to describe a > single RTP session, and what you can't say about a single RTP session, > you can't say about a bundle describing a single RTP session either. > > But that might not be what people want. > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From martin.thomson@gmail.com Tue May 28 09:10:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C968521F9539 for ; Tue, 28 May 2013 09:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZq6a6o6-8Hc for ; Tue, 28 May 2013 09:10:24 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2CA21F9007 for ; Tue, 28 May 2013 09:10:23 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hn14so3361718wib.4 for ; Tue, 28 May 2013 09:10:22 -0700 (PDT) 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=YjzRKOEbC0CniT21St5iFpJP/nwlDNfR5Sbzw34M97o=; b=xQWVVl89s4YvixgUBLOUUND4Fv4HpMyJasXwTKuny6EhOsuWVLeuaBKnuVEo33G2zc h89eT6HUFuBgnDDiRZ7VaebT4+3SQsAFNiB+W3ipx38LXgHEHfRWIav/vtyf4sg5mSff sLN82iAxCRXvpbnBxjQXJzDRru1g7exPG9KCiiZkWCQ6f6rMHxtR2bb4LaZAoFa7yp6a PMARgwIKd0DZ1zobnfzJMRMKpLKhJYC9r/OwISEJOvAC98BfkfLzdRaSUnmSQ+UGtK9T Z/Cs1fHfoLPc9IlQSfmsHTk0F4yQqTU2sEaeRjLi3ggOpZGVJjQtqjJAlDz47Q/bUwQR S4xg== MIME-Version: 1.0 X-Received: by 10.180.90.70 with SMTP id bu6mr12692984wib.34.1369757422591; Tue, 28 May 2013 09:10:22 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Tue, 28 May 2013 09:10:22 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C379AEC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C379AEC@ESESSMB209.ericsson.se> Date: Tue, 28 May 2013 09:10:22 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 16:10:24 -0000 On 27 May 2013 07:28, Christer Holmberg wrote: > But, if you disagree with 4, which port do you think the offerer shall use for receiving media? It cannot use the "bundle port", as the answerer removed the m- line from the bundle group. I think that you need to be clearer in your description of 4. Rather than: > 4) an m- line MUST NOT be removed from a BUNDLE group if, in the associated offer, an identical port number was indicated for all m- lines in a BUNDLE group Use words like unbundled instead perhaps. And it's not MUST NOT, it's simply "cannot". From pkyzivat@alum.mit.edu Tue May 28 09:15:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD2621F9837 for ; Tue, 28 May 2013 09:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLKn6dqX5if8 for ; Tue, 28 May 2013 09:15:45 -0700 (PDT) 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 A92A521F9839 for ; Tue, 28 May 2013 09:15:44 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta10.westchester.pa.mail.comcast.net with comcast id hPFJ1l0021YDfWL5AUFkai; Tue, 28 May 2013 16:15:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id hUFk1l00R3ZTu2S3gUFk7R; Tue, 28 May 2013 16:15:44 +0000 Message-ID: <51A4D82F.6040806@alum.mit.edu> Date: Tue, 28 May 2013 12:15:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C37A880@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37A880@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369757744; bh=5R8MGsoft+TTRls8oN4Aw54pJ05Cb/oEsDjyYOP1tEY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VKXjraPXiziq1qWeLzEZ8YMN3MQiQPO4mlgA/JpeeApNEXKoGHI/xG2kfIru0OMv9 2v6RXkjiEz3ATdnPP8e08Yt0GtdYsQf/PIiJaUZ/IMVFfLKIYAqI7e0GcZADTmbXhj 4HmxSwh3hPq2vnhdRQO7k2/ANrFE8p1ilqS2lioIYRmA9lKQAR/wU3p3sM5CKGBGDr F5ZcwIcahZ3LswTSgLgB3+eagxEgNKmepqNMQqFqu3st5DffqRzSCMbM2PXIQaRWrR AAxCx7TUjVEF/dpkmUQ/1ARfdtl25WTFCgSt4RkizRB9TJEi3gSTmxvsidXnrukWYz Il6V85SGw9GsQ== Subject: Re: [MMUSIC] BUNDLE: Updated offer procedures X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 16:15:52 -0000 On 5/28/13 3:58 AM, Christer Holmberg wrote: > Hi, > > There has been some discussions about updated bundle offers, especially in cases where a new m- line is added to a bundle group, or when a port-zero-m-line within a bundle group is "taken back to use". In this e-mail, I refer to both cases as "adding a new m- line". > > When the updated offer is sent, the offerer has two choices: > > 1) The port value of the new m- line is identical to the port values of the other m- lines in the bundle: > > This should be rather straight forward. According to answer restriction #4, the answerer can either accept the new m- line within the bundle group, or reject the m- line by setting the port to zero. > > > 2) The port value of the new m- line is NOT identical to the port values of the other m- lines in the bundle: > > In this case, the answer has the possibility to remove the m- line from the bundle group, as it has a individual port number in the offer. > > Now, there are two "sub cases": > > 2a) The new m- line(s) have individual port numbers, but the old m- lines have the previously negotiated single bundle port value > > I guess this case is the one we need to focus most on. > > In my opinion, if the answerer accepts the new m- line, it must use the previously negotiated bundle port. IF the offerer (or answerer) wants to re-negotiate the bundle port, it must act according to 2b (see below). > > > 2b) The new m- line(s), AND, the old ones, have individual port numbers > > In my opinion, this is a "bundle restart", where the port (and, then bundle in general) is re-negotiated. I agree with all you say above. But those aren't all the cases. Some other possibilities: - new offer has all m-lines with identical ports, but answerer wants to replace its own addr/port while preserving the bundle. So it puts the (new) identical addr/port in all m-lines. - hybrids of the above with your other cases. Also, a somewhat different aspect of this: In the first answer establishing a bundle the a=group identifies which m-line contains the bundle port. Then a new O/A fills in that single port value in all the m-lines of the bundle. Is there any significance to the order of the mid values in that offer and answer? (No matter which one it is, it presumably still points to an m-line with identical port, so I don't see any need for rules.) Then in a subsequent O/A that changes the bundle in some way, are there rules for which m-line the first mid points to? E.g., consider your case (2) above. Can the offer or answer designate one of the new m-lines (with unique ports) as the bundle port? (I can argue this one either way.) Thanks, Paul From martin.thomson@gmail.com Tue May 28 09:16:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259DF21F97A8 for ; Tue, 28 May 2013 09:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E38-iTPpKB-c for ; Tue, 28 May 2013 09:16:27 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F85721F976F for ; Tue, 28 May 2013 09:16:27 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hq7so2655251wib.6 for ; Tue, 28 May 2013 09:16:26 -0700 (PDT) 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=kh7dT+8d7AghoA9Y4fNIX1Lw1Jhnd3cLkJYFBQG0wtQ=; b=T2U227yMvcG31PIrbDC/C0f5JCgGaB4VRzlIEC8ndMsGJ2jJ/4e29yEf6iilgWzi7R giIklwzr7VXiE6knGgvfLHX10SJsbf4+XJoH76KBylFVsRbUB/Lv0+9TFaU9JzAFu/EY QqAG0yhK8aZPsoLEzqMWw1WUnjPnJjemouwssURm3LJjZEEc1sQ1aaS8j8E+CExLqqHq fTylehbqxtaRzyovQ7MOA1DoNMfYSiXxKAJM6T3clwu1F71krWF2cLVNBrczcea8IWHV RniNRanp2XnIAvyI31z/vS3itOT8tzTZt2zAJjcQlv9/oYbHWTYbCtjVIYiNHodUODBa ntAg== MIME-Version: 1.0 X-Received: by 10.180.87.33 with SMTP id u1mr12867089wiz.34.1369757786505; Tue, 28 May 2013 09:16:26 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Tue, 28 May 2013 09:16:26 -0700 (PDT) In-Reply-To: <51A3802A.1090203@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> <519E8CA6.1090009@alum.mit.edu> <51A3802A.1090203@alum.mit.edu> Date: Tue, 28 May 2013 09:16:26 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , Christer Holmberg , mmusic Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 16:16:28 -0000 On 27 May 2013 08:47, Paul Kyzivat wrote: > no From martin.thomson@gmail.com Tue May 28 09:34:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E3221F9895 for ; Tue, 28 May 2013 09:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDUtrxAb2F6o for ; Tue, 28 May 2013 09:34:54 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F14EE21F988B for ; Tue, 28 May 2013 09:34:52 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hr14so3389082wib.5 for ; Tue, 28 May 2013 09:34:52 -0700 (PDT) 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=qauuvAeuUbzYWSVsU/okVz/55GaEYdeKH9TvBn4sUU4=; b=G+I4PIxEG0emzOl7O9L5g2MuO0UaAbpjmiUopSZwwhM2wHlF5pYjjN9iu0mZ1tHIIv UhiB5R/1AS69NOnwURR8rc4MW6zBNMSYYsqG1DvmN6pc0DrY3QVDhU0+yULm2kUH1CI8 AJokQD15sEXEbXzmSf4z1deHG27Ugj9ToklMy9mBYt64uf5+5pJ+yjkiEMfpfLyjrvb3 tVbrrDGxWUqJiy8XVMIFBaPdVLJT9LdVbONuU43QUVGlbGWFy1gJw8ghJkFGNuM0vElB Y5epfL1pwjgyZvXMhEHIi5RS97Q+1I9Bh6/CtWpt0ESSH0iwYr64SH6SrqRBVkiRF8TA oTRw== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr12848698wic.32.1369758890950; Tue, 28 May 2013 09:34:50 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Tue, 28 May 2013 09:34:50 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> <519E8CA6.1090009@alum.mit.edu> <51A3802A.1090203@alum.mit.edu> Date: Tue, 28 May 2013 09:34:50 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , Christer Holmberg , mmusic Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 16:34:55 -0000 On 28 May 2013 09:16, Martin Thomson wrote: > On 27 May 2013 08:47, Paul Kyzivat wrote: >> no FWIW, I can live with that. (Sorry about the earlier empty email.) I was simply trying to be aggressively minimalist. This model requires that each m-line has two independently negotiable properties: - accepted/rejected (signaled using zero port) - bundle membership (signaled using a=group) (and yes, this requires an update to 5888) Then we need, as you describe, rules for transitioning between states. Transition between accepted and rejected is always possible in both offers and answers. It seems like we are saying that bundle membership can transition in the following ways: Any group to no group: - In an offer, under all circumstances. - In an answer, if the m-line is rejected. - In an answer, if unique transport parameters are provided in the offer. No group to any group: - In an offer, under all circumstances. - In an answer, never. Any group to any other group: - In an offer, if the m-line was previously rejected. - In an answer, if the lines were offered as a bundle and there are sufficient transport parameters on offer. Is that the rules you would like to see? I think that the last option (splitting) is the only one that I haven't seen anyone else slavering for. The model permits it, but I'd rather prohibit features fix it up later than start with something that ends up too permissive. For example, it would be possible to split a bundle that had multiple m-lines and only two sets of transport parameters like the following: offer: BUNDLE 1 2 3 4 mid:1 transport A mid:2 transport A mid:3 transport A mid:4 transport B answer: BUNDLE 1 2 BUNDLE 4 3 Despite a (possible) preference from the offerer for bundling 1-3 together, 3 has been split off. I'm sure that we can get the rules right, but I like avoiding these sorts of little complications. From prvs=3860d0bb4d=christer.holmberg@ericsson.com Tue May 28 09:51:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B07A21F9735 for ; Tue, 28 May 2013 09:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy36Hdf7osi0 for ; Tue, 28 May 2013 09:51:50 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0179D21F9734 for ; Tue, 28 May 2013 09:51:49 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-30-51a4e0a49bfc Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 99.A1.06701.4A0E4A15; Tue, 28 May 2013 18:51:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Tue, 28 May 2013 18:51:48 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions Thread-Index: Ac5YdJNWNYfYqobOTueV815jNgS21wCWRNCAAAYVf+EAMcazAAAFl7AA Date: Tue, 28 May 2013 16:51:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37AF52@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C377967@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C379AEC@ESESSMB209.ericsson.se> 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.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre6SB0sCDd5P0LfomMxmce3MP0aL qcsfszgwe0z5vZHVY+esu+weS5b8ZApgjuK2SUosKQvOTM/Tt0vgznhy7BtzwTW2infvChoY D7B1MXJwSAiYSPy4Y93FyAlkiklcuLceKMzFISRwmFFiwZWd7BDOEkaJ5k9HwBrYBCwkuv9p gzSICOhKLDr7gB3EZhaIkJi/eyuYLSxgL3Hp/gc2iBoHiWnHF7ND2G4Sr9+9A4uzCKhKzDv2 jxXE5hXwlZj+7B4rxK7ZTBLvtl9iBklwCgRKnL/7jwXEZgS67vupNUwQy8QlPhy8zgxxtYDE kj3noWxRiZePIYZKCChJ/NhwiQXkZmYBTYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMYrOQTJ2F 0DELSccsJB0LGFlWMbLnJmbmpJebb2IERszBLb8NdjBuui92iFGag0VJnFefd3GgkEB6Yklq dmpqQWpRfFFpTmrxIUYmDk4QwSXVwGg9zfP8t2UcM/YZPyrU0PvC4XY0qkI4/eU//xniVzdV PFwQsvTVfYej+28fez0v+kbq4/RnLZefbGKI0JzBbpyqsey5QGpCo9SZ5otqdiWav6L+tSvn Xan0j1435SUXc+QSM4OHUhn1IgU/gl7cs/S8XHK677zK7MU1n3wn5U7ekM0taf3/6m4lluKM REMt5qLiRADKcRovawIAAA== Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISSION: SDP Answer Restrictions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 16:51:57 -0000 SGksDQogDQo+PiBCdXQsIGlmIHlvdSBkaXNhZ3JlZSB3aXRoIDQsIHdoaWNoIHBvcnQgZG8geW91 IHRoaW5rIHRoZSBvZmZlcmVyIHNoYWxsIHVzZSBmb3IgcmVjZWl2aW5nIG1lZGlhPyBJdCBjYW5u b3QgdXNlIHRoZSAiYnVuZGxlIHBvcnQiLCBhcyB0aGUgYW5zd2VyZXIgcmVtb3ZlZCB0aGUgbS0g bGluZSBmcm9tIHRoZSBidW5kbGUgZ3JvdXAuDQo+DQo+SSB0aGluayB0aGF0IHlvdSBuZWVkIHRv IGJlIGNsZWFyZXIgaW4geW91ciBkZXNjcmlwdGlvbiBvZiA0LiAgUmF0aGVyIHRoYW46DQo+IDQp ICAgICAgYW4gbS0gbGluZSBNVVNUIE5PVCBiZSByZW1vdmVkIGZyb20gYSBCVU5ETEUgZ3JvdXAg aWYsIGluIHRoZSBhc3NvY2lhdGVkIG9mZmVyLCBhbiBpZGVudGljYWwgcG9ydCBudW1iZXIgd2Fz IGluZGljYXRlZCBmb3IgYWxsIG0tIGxpbmVzIGluIGEgQlVORExFIGdyb3VwDQo+DQo+IFVzZSB3 b3JkcyBsaWtlIHVuYnVuZGxlZCBpbnN0ZWFkIHBlcmhhcHMuICBBbmQgaXQncyBub3QgTVVTVCBO T1QsIGl0J3Mgc2ltcGx5ICJjYW5ub3QiLg0KDQpNeSBpbnRlbnRpb24gd2FzIHRvIGFkZCBhIE5P VEUsIHdpdGggc29tZSAiY2Fubm90IiB0ZXh0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From mary.ietf.barnes@gmail.com Tue May 28 10:36:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF69421F91B1 for ; Tue, 28 May 2013 10:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nK5sZdX52kL for ; Tue, 28 May 2013 10:36:36 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3221521F910D for ; Tue, 28 May 2013 10:36:36 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id bn16so1651437qab.2 for ; Tue, 28 May 2013 10:36:35 -0700 (PDT) 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:content-transfer-encoding; bh=4Ynd3Mud5UqQOyUFGWCkWw3D3XD4g2tRB0JbahgMUNE=; b=F9TtmknCrpvbhVjbHTC3QGgJNeN/w7FQX4ZzyxtIbbp+G6fJvo1IeX/p78M5PTeWH3 xntLUQBK/R8JONcafG6zx27o5PXq+Z82W8yOY0dGW4B17c33kPjpCSGSjzfVaHU3pRhE JSDx8FHngw/YPq09UOSV4htBabKXIkSOwIMC4oGVM4vqFtsKrXOD1Wu6J8g+ggplut2i 5yqhvJ/6KQHFJzu0LqmAQmHn1vFDe9DhTU6rUB9qTEmHYgeXh+lBOapt+2Fzg93sWbZ8 5+DbCXU/IYQlG0oEDlMpIT1W2A5HsgAsEMdI1U4Xpzn+oE5rlKGx5VPqyquhC1IuOU65 n7LA== MIME-Version: 1.0 X-Received: by 10.49.35.49 with SMTP id e17mr38328126qej.61.1369762595667; Tue, 28 May 2013 10:36:35 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Tue, 28 May 2013 10:36:35 -0700 (PDT) In-Reply-To: References: <519E6265.4090102@alum.mit.edu> <519E8B58.9030604@alum.mit.edu> Date: Tue, 28 May 2013 12:36:35 -0500 Message-ID: From: Mary Barnes To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 17:36:36 -0000 On Mon, May 27, 2013 at 8:15 AM, Cullen Jennings (fluffy) wrote: > > On May 23, 2013, at 3:34 PM, Paul Kyzivat wrote: > >> >> For instance, we have a clue case where we can have two clue switched ca= ptures, one representing the video for loudest speaker, and one for the 2nd= loudest speaker. A single SSRC can move from one of those captures to the = other. Its the capture (identified by an rtp header extension) that selects= the processing pipeline. > > Note my proposal put the RTP header extension ahead of looking at SSRC to= meet needs of CLUE and also possible stuff from UCIF. > [MB] Cullen, when you are talking about UCIF, you are explicitly talking about SVC - is that correct? [/MB] > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From prvs=386130907d=christer.holmberg@ericsson.com Wed May 29 00:35:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1049021F8555 for ; Wed, 29 May 2013 00:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.618 X-Spam-Level: X-Spam-Status: No, score=-5.618 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEKTiPxp4xKD for ; Wed, 29 May 2013 00:35:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8536121F8F29 for ; Wed, 29 May 2013 00:35:47 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-85-51a5afd232c7 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 85.F4.06701.2DFA5A15; Wed, 29 May 2013 09:35:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Wed, 29 May 2013 09:35:46 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Updated offer procedures Thread-Index: Ac5beKfpSruus8OIRHSvbTVCpmVX7QANS7OAAAbsi4A= Date: Wed, 29 May 2013 07:35:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37B684@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37A880@ESESSMB209.ericsson.se> <51A4D82F.6040806@alum.mit.edu> In-Reply-To: <51A4D82F.6040806@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvre6l9UsDDVonaVpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFLdNUmJJWXBmep6+XQJ3xrqT9xgL9ktXfH3Sw9rAuF+0i5GTQ0LA RKLl9F5mCFtM4sK99WxdjFwcQgKHGSU2n93CApIQEljCKHG43auLkYODTcBCovufNkhYRCBQ 4sr1W4wgtrCAmcTVbSC9IHFziduv1zJC2FYSs9ubmEBsFgFViZs3j7GCjOEV8JVY/sUYYnq+ xPPdX8FKOAV0JE7M2ALWygh0zvdTa8DizALiEreezGeCOFNAYsme81Ani0q8fPwPbKSEgKLE 8n45iHIdiQW7P7FB2NoSyxa+BivnFRCUODnzCcsERtFZSKbOQtIyC0nLLCQtCxhZVjGy5yZm 5qSXm29iBMbBwS2/DXYwbrovdohRmoNFSZxXn3dxoJBAemJJanZqakFqUXxRaU5q8SFGJg5O EMEl1cDYHaL3TffBLDVjzf1O7fY7/6zfKdPfb/f0TWf8l589MZImh+5PnDaVwzl++WLr9qaP mio9Xk9ubHZSv8Nxx107JOWSU0dhfvIetj7bxk6RhU0fxUIOpb48neYv3nHzeVrF7P9i7v1v W8JDqpi/6Lnxys3V8vtzW41Za7e6w72YJzy2kcs9EpVYijMSDbWYi4oTAQe6Kt5WAgAA Subject: Re: [MMUSIC] BUNDLE: Updated offer procedures X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 07:35:55 -0000 Hi, >> There has been some discussions about updated bundle offers, especially = in cases where a new m- line is added to a bundle group, or when a port-zer= o-m-line within a bundle group is "taken back to use". In this e-mail, I re= fer to both cases as "adding a new m- line". >> >> When the updated offer is sent, the offerer has two choices: >> >> 1) The port value of the new m- line is identical to the port values of = the other m- lines in the bundle: >> >> This should be rather straight forward. According to answer restriction = #4, the answerer can either accept the new m- line within the bundle group,= or reject the m- line by setting the port to zero. >> >> >> 2) The port value of the new m- line is NOT identical to the port values= of the other m- lines in the bundle: >> >> In this case, the answer has the possibility to remove the m- line from = the bundle group, as it has a individual port number in the offer. >> >> Now, there are two "sub cases": >> >> 2a) The new m- line(s) have individual port numbers, but the old m- line= s have the previously negotiated single bundle port value >> >> I guess this case is the one we need to focus most on. >> >> In my opinion, if the answerer accepts the new m- line, it must use the = previously negotiated bundle port. IF the offerer (or answerer) wants to re= -negotiate the bundle port, it must act according to 2b (see below). >> >> >> >> 2b) The new m- line(s), AND, the old ones, have individual port numbers >> >> In my opinion, this is a "bundle restart", where the port (and, then bun= dle in general) is re-negotiated. > >I agree with all you say above. > >But those aren't all the cases. Some other possibilities: > >- new offer has all m-lines with identical ports, but answerer wants to > replace its own addr/port while preserving the bundle. So it puts > the (new) identical addr/port in all m-lines. That's a good catch. But, I think it's more related to the "answer procedur= es", so I'll move it to that thread :) I guess the question is whether we want to allow the answerer to change its= bundle port in other than "bundle restart" cases (2b). > - hybrids of the above with your other cases. > > Also, a somewhat different aspect of this: > >In the first answer establishing a bundle the a=3Dgroup identifies which m= -line contains the bundle port. > >Then a new O/A fills in that single port value in all the m-lines of the b= undle. Is there any significance to the order=20 >of the mid values in that offer and answer? (No matter which one it is, it= presumably still points to an m-line with identical=20 >port, so I don't see any need for rules.) I agree. I don't think the order is significant, as all mids are associated= with the same port in the new O/A. >Then in a subsequent O/A that changes the bundle in some way, are there ru= les for which m-line the first mid points to? E.g., consider your case >(2) above. Can the offer or answer designate one of the new m-lines (with = unique ports) as the bundle port? (I can argue this one either way.) 2b allows the answerer to designate one of the new m- lines as the offerer = bundle port (2b also allows to answerer to reject the whole bundle group). We COULD allow the answerer to designate a new port also in case 2a. In the= case of 2a, however, the answerer cannot reject the whole bundle group, as= only the new m- line has a unique port. Regards, Christer From prvs=08612b889a=christer.holmberg@ericsson.com Wed May 29 02:35:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F01E21F90CD for ; Wed, 29 May 2013 02:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivZtecrmEwoh for ; Wed, 29 May 2013 02:35:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4638C21F9121 for ; Wed, 29 May 2013 02:35:36 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-76-51a5cbe753a5 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1F.56.15700.7EBC5A15; Wed, 29 May 2013 11:35:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Wed, 29 May 2013 11:35:35 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Allowed to change local bundle port in SDP Answer? Thread-Index: Ac5cT7iTJh+UkTvAQrimrMBFim1gCA== Date: Wed, 29 May 2013 09:35:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37B7B6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C37B7B6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvre6L00sDDb6dYbSYuvwxiwOjx5Il P5kCGKO4bZISS8qCM9Pz9O0SuDMezFzHVvBfvuJd4ymWBsYP0l2MnBwSAiYSE/ovM0HYYhIX 7q1nA7GFBA4zSkyYHtLFyAVkL2GU+P/lDnsXIwcHm4CFRPc/bZAaEQF1ia97e5hBbGEBZ4nn q/cwQsQ9JG69b2GCsPUk3jzZDWazCKhKtO27BzafV8BXov14DzuIzQi09/upNWA1zALiEree zIe6R0BiyZ7zzBC2qMTLx/9YQU6QEFCUWN4vB1GeL/F16UVWiJGCEidnPmGZwCg0C8mkWUjK ZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsY2XMTM3PSyw03MQKD/uCW37o7GE+d EznEKM3BoiTOq8e7OFBIID2xJDU7NbUgtSi+qDQntfgQIxMHJ4jgkmpgLPj9eOazAAuuk6ti ZhgvLPzIVyzR47oiL+1Fm8D7F0FtNTNmnmbmnmnnFvlRSqTswA0RjzXfl56bqDu7Rrzie2r0 rrDwInux1OksM++sfszI9iuX8U/FpcqNW8s/ZIndmmn+dyfD03sJ7Fnzujd/eZaUfrG3s1Pr s3b8lVQeybJbmt7eZ2/OUmIpzkg01GIuKk4EALFh1ZJNAgAA Subject: [MMUSIC] BUNDLE: Allowed to change local bundle port in SDP Answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 09:35:44 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C37B7B6ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, When the answerer receives the first bundle offer, it will assign a local b= undle port. Nothing strange there. Paul raised a question whether, when an updated offer is received, the answ= erer is allowed to change the local bundle port in the associated answer. Personally, I can't think of a reason why it should not be allowed - no mat= ter whether the offer contains different bundle ports or not - it would be = according to normal O/A procedures. If NOT allowed, if the answerer wants to change its local bundle port, it w= ould have to send a new offer by itself (the details of such offer is discu= ssed in another tread). Comments? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C37B7B6ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

When the answerer receives the first bundle offer, i= t will assign a local bundle port. Nothing strange there.

 

Paul raised a question whether, when an updated offe= r is received, the answerer is allowed to change the local bundle port in t= he associated answer.

 

Personally, I can’t think of a reason why it s= hould not be allowed – no matter whether the offer contains different= bundle ports or not – it would be according to normal O/A procedures= .

 

If NOT allowed, if the answerer wants to change its = local bundle port, it would have to send a new offer by itself (the details= of such offer is discussed in another tread).

 

Comments?

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C37B7B6ESESSMB209erics_-- From prvs=886125c88c=ari.keranen@ericsson.com Wed May 29 02:51:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE5721F8FAF for ; Wed, 29 May 2013 02:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eHm9AmZvBnR for ; Wed, 29 May 2013 02:51:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5404321F85BF for ; Wed, 29 May 2013 02:51:33 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-c1-51a5cfa332a5 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 74.49.18006.3AFC5A15; Wed, 29 May 2013 11:51:32 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 29 May 2013 11:51:32 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 97A97247A; Wed, 29 May 2013 12:51:31 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F3E235515E; Wed, 29 May 2013 12:51:29 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A84AB54A35; Wed, 29 May 2013 12:51:29 +0300 (EEST) Message-ID: <51A5CFA2.30801@ericsson.com> Date: Wed, 29 May 2013 12:51:30 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Magnus Westerlund References: <518BB81A.8090608@cisco.com> <51965190.10900@ericsson.com> <519E2BF8.7040500@ericsson.com> <519E58D1.6080600@ericsson.com> <51A3278D.8060402@ericsson.com> In-Reply-To: <51A3278D.8060402@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvre6S80sDDe5MYLe42/uCyWLq8scs DkweS5b8ZPL4cvkzWwBTFLdNUmJJWXBmep6+XQJ3xo79T5gLFgpXHHg6mbGBsY+/i5GDQ0LA RGLFXIcuRk4gU0ziwr31bCC2kMApRommb0VdjFxA9gZGiadrNrFDOLsZJV4dusAG4axjlFj0 eD2Us4JR4vucrcwgY3kFNCV6t6qCjGIRUJXo/3edFcRmE7CXuDnhOjuILSqQLDF56goWEJtX QFDi5MwnYLaIgJnEwwn7wc5gFgiV+HNxDZgtLOAn0XdoJxPErmWMEmfOrmMCSXAK6Ei8ODmD FaLBVuLCnOssELa8RPPW2cwQv6lJXD23iRniN1WJq/9eMU5gFJ2FZPcsJO2zkLQvYGRexcie m5iZk15utIkRGPgHt/xW3cF455zIIUZpDhYlcV493sWBQgLpiSWp2ampBalF8UWlOanFhxiZ ODhBBJdUA2MDR9r+hbf7Y2dp5BVfiTjxabnmXS81dUU5b8Y3Fw57ar+fyBGRYTP35oaWnSc7 OnfP+Sh8NW+ZtswbtyLXF8/TBdX8RZqCs2emTWb4Uf9osc/GbEaNyYru799msj1Z2fhk1e/i qRY1rCU1cZNPFS89ojUrxFpeO6yrpaHV5kHo3Zl71WY9slJiKc5INNRiLipOBADDOrSETwIA AA== Cc: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 09:51:46 -0000 Hi Magnus, The diff looked good. Couple of quick nits: 5. The RTSP Client uses the RTSP Servers response to create TURN s/Servers/Server's/ 7. The first media packet to arrive at the TURN server on the external port; If matching established permissions the TURN server forwards the media packets to the RTSP client. s/If matching/If there exists a matching/ or /If the packet matches an/ Cheers, Ari On 5/27/13 12:29 PM, Magnus Westerlund wrote: > Hi, > > Sorry for missing the other changes. I think I gotten all the lock down > changed now. This has resulted in some significant changes in the text > for TURN relays, including a server implementation requirement. I > recommend that people do take a look at the diff: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-08 > > Cheers > > Magnus > > > On 2013-05-23 19:58, Ari Keränen wrote: >> On 5/23/13 5:47 PM, Magnus Westerlund wrote: >>> On 2013-05-17 17:49, Ari Keränen wrote: >>> >>>> >>>> >>>> 4.9.1. [TURN] Introduction >>>> >>>> On the external side this is >>>> limited to the source address/port pair of the first packet arriving >>>> on the binding. After the first packet has arrived the mapping is >>>> "locked down" to that address. Packets from any other source on >>>> this >>>> address will be discarded. >>>> >>>> This doesn't sound right. This behavior was changed (eventually into >>>> using permissions) somewhere back in draft-rosenberg-midcom-turn-06. See >>>> http://tools.ietf.org/html/rfc5766#section-2.3 for up-to-date behavior. >>>> Check also steps 5 & 7 in the next section and section 4.9.4 for more >>>> lock down text. >>> >>> I changed this to: >>> >>> To prevent DoS attacks on either recipient, the packets forwarded are >>> restricted to the specific source address. On the client side it is >>> restricted to the source setting up the allocation. On the external side >>> this is limited to the source address/port pair that have been given >>> permission by the TURN client creating the allocation. Packets from any >>> other source on this address will be discarded. >>> >>> I will shortly submit an updated draft. >> >> Looks good to me. However, also the following sections had some "lock >> down" text that should be updated (see details on my original mail above). >> >> >> Cheers, >> Ari >> >> >> > > From prvs=5861490072=ari.keranen@ericsson.com Wed May 29 02:53:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232A721F85BF for ; Wed, 29 May 2013 02:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBO4HIiQSpCs for ; Wed, 29 May 2013 02:53:30 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1404E21F8FAF for ; Wed, 29 May 2013 02:53:29 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-a4-51a5d01830b6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 34.99.18006.810D5A15; Wed, 29 May 2013 11:53:29 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 29 May 2013 11:53:28 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 864FC247A; Wed, 29 May 2013 12:53:28 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E45C85515E; Wed, 29 May 2013 12:53:26 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 83F1554A35; Wed, 29 May 2013 12:53:26 +0300 (EEST) Message-ID: <51A5D017.6070102@ericsson.com> Date: Wed, 29 May 2013 12:53:27 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Magnus Westerlund References: <519638D5.9030301@cisco.com> <51A28787.3090709@ericsson.com> <51A32E8B.7030909@ericsson.com> In-Reply-To: <51A32E8B.7030909@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvra7khaWBBqvXcVu0vznCZDF1+WMW ByaPJUt+Mnl8ufyZLYApitsmKbGkLDgzPU/fLoE7o+/RN/aCbxwV07s7WRoYP7B1MXJySAiY SOxp2gNli0lcuLceyObiEBI4xShx7Mp0JghnA6PExM+HoTK7GSXOnuxihXDWMUpM2LOLHcJZ wSjR8u84I8gwXgFtiSP/NjGD2CwCqhIP775lBbHZBOwlbk64zg5iiwokS0yeuoIFol5Q4uTM J2C2iICZxMMJ+8GOYhZwlzh66DvQHA4OYQFniU1rckDCQgIZEl8aH4Gt4hTQkTj19ywzRLmt xIU511kgbHmJ5q2zmSF+U5O4eg7iHCGgc67+e8U4gVF0FpLNs5C0z0LSvoCReRUje25iZk56 udEmRmDoH9zyW3UH451zIocYpTlYlMR59XgXBwoJpCeWpGanphakFsUXleakFh9iZOLgBBFc Ug2Mc18mn/n8RIzb9pbJLuPCyFMp70Pt3/cueXnoRv9q3+3hmRvmyhgyXjscOztqRY3wxQUC iVttFC3LGHIn+WZ8MbktEP24sTn1QM3lGetuPLo0c+WL7532a6Lfib7fL7S8VIpB9ZdJYODF LZZT3EL/Pnv6/d+uvrVLbSZvSNl47eud2dfLm1OOXVJiKc5INNRiLipOBAC58Wh2UAIAAA== Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 09:53:36 -0000 Hi Magnus, The changes look good to me. Thanks, Ari On 5/27/13 12:59 PM, Magnus Westerlund wrote: > Hi Ari, > > Thanks for these fixes. I have implemented them: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-16 > > Cheers > > Magnus > > On 2013-05-27 00:07, Ari Keränen wrote: >> Hi, >> >> Here's a few editorial things worth considering fixing. >> >> >> 3. Solution Overview >> >> 9. When the client has concluded its connectivity checks, including >> promoting candidates, and has correspondingly received the >> >> s/promoting candidates/nominating candidate pairs/ >> (using "promoting/promoted" also later in the document) >> >> >> 4.2. ICE Candidate Transport Header Parameter >> >> : [...] >> It MUST start at 1 and MUST increment by 1 for each component >> of a particular candidate >> >> s/of a particular candidate/of a particular media stream/ >> >> >> In section 6.4 you talk about "SO" connection types; makes sense to >> expand that into "Simultaneous Open". >> >> >> Cheers, >> Ari (as individual) >> >> > > From andrew.hutton@siemens-enterprise.com Wed May 29 03:05:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B9621F9360 for ; Wed, 29 May 2013 03:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2fW3r46FRFL for ; Wed, 29 May 2013 03:05:42 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 98A4F21F937A for ; Wed, 29 May 2013 03:05:40 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3EB6323F0464; Wed, 29 May 2013 12:05:39 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 29 May 2013 12:05:39 +0200 From: "Hutton, Andrew" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: BUNDLE: Allowed to change local bundle port in SDP Answer? Thread-Index: Ac5cT7iTJh+UkTvAQrimrMBFim1gCAAAyq1A Date: Wed, 29 May 2013 10:05:38 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115B4EAE@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B1C37B7B6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37B7B6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF115B4EAEMCHP04MSXglobal_" MIME-Version: 1.0 Subject: Re: [MMUSIC] BUNDLE: Allowed to change local bundle port in SDP Answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 10:05:47 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF115B4EAEMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cannot see why the answerer should be prevented from changing the port and = even the connection address and candidates etc. in any new answer any such = restriction would seem to be a major diversion from existing offer/answer p= rocedures and I cannot see why we would want to consider it. We need to maintain the existing offer/answer procedures as much as possibl= e. Andy From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 29 May 2013 10:36 To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE: Allowed to change local bundle port in SDP Answer= ? Hi, When the answerer receives the first bundle offer, it will assign a local b= undle port. Nothing strange there. Paul raised a question whether, when an updated offer is received, the answ= erer is allowed to change the local bundle port in the associated answer. Personally, I can't think of a reason why it should not be allowed - no mat= ter whether the offer contains different bundle ports or not - it would be = according to normal O/A procedures. If NOT allowed, if the answerer wants to change its local bundle port, it w= ould have to send a new offer by itself (the details of such offer is discu= ssed in another tread). Comments? Regards, Christer --_000_9F33F40F6F2CD847824537F3C4E37DDF115B4EAEMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Cannot see why the ans= werer should be prevented from changing the port and even the connection ad= dress and candidates etc. in any new answer any such restriction would seem= to be a major diversion from existing offer/answer procedures and I cannot see why we would want to consider it.=

 

We need to maintain th= e existing offer/answer procedures as much as possible.

 

Andy=

 

 

From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 29 May 2013 10:36
To: mmusic@ietf.org
Subject: [MMUSIC] BUNDLE: Allowed to change local bundle port in SDP= Answer?

 

Hi,

 

When the answerer receives the first bundle offer, i= t will assign a local bundle port. Nothing strange there.

 

Paul raised a question whether, when an updated offe= r is received, the answerer is allowed to change the local bundle port in t= he associated answer.

 

Personally, I can’t think of a reason why it s= hould not be allowed – no matter whether the offer contains different= bundle ports or not – it would be according to normal O/A procedures= .

 

If NOT allowed, if the answerer wants to change its = local bundle port, it would have to send a new offer by itself (the details= of such offer is discussed in another tread).

 

Comments?

 

Regards,

 

Christer

 

--_000_9F33F40F6F2CD847824537F3C4E37DDF115B4EAEMCHP04MSXglobal_-- From prvs=98619573fd=christer.holmberg@ericsson.com Wed May 29 03:10:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF02221F938E for ; Wed, 29 May 2013 03:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKr-J9PLgdlm for ; Wed, 29 May 2013 03:10:18 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F102221F9360 for ; Wed, 29 May 2013 03:10:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-d0-51a5d4087b27 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C0.0D.15700.804D5A15; Wed, 29 May 2013 12:10:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Wed, 29 May 2013 12:10:16 +0200 From: Christer Holmberg To: "Hutton, Andrew" , "mmusic@ietf.org" Thread-Topic: BUNDLE: Allowed to change local bundle port in SDP Answer? Thread-Index: Ac5cT7iTJh+UkTvAQrimrMBFim1gCAAAyq1AAABvM6A= Date: Wed, 29 May 2013 10:10:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37B846@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37B7B6@ESESSMB209.ericsson.se> <9F33F40F6F2CD847824537F3C4E37DDF115B4EAE@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115B4EAE@MCHP04MSX.global-ad.net> 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+NgFjrMLMWRmVeSWpSXmKPExsUyM+JvrS7HlaWBBkd2GVqc7etit5i6/DGL A5PHkiU/mTxu3H7PHMAUxW2TlFhSFpyZnqdvl8CdsfXUVPaCi1wVi9s/MzUwbuboYuTkkBAw kdjR8IIVwhaTuHBvPVsXIxeHkMBhRokDZ7vZIZwljBKHj60BynBwsAlYSHT/0wZpEBFIkvj9 aTkLSFhYwF3i/gULiLCHxK33LUwgYREBK4m+NUkgYRYBVYkDa4+wgdi8Ar4SF6atYQexhQQm MUpcvCEBYnMK+Eu8Pv+eGcRmBDrn+6k1TCA2s4C4xK0n85kgzhSQWLLnPDOELSrx8vE/VpBV EgKKEsv75SDKdSQW7P7EBmFrSyxb+JoZYq2gxMmZT1gmMIrOQjJ1FpKWWUhaZiFpWcDIsoqR PTcxMye93HATIzAODm75rbuD8dQ5kUOM0hwsSuK8eryLA4UE0hNLUrNTUwtSi+KLSnNSiw8x MnFwggguqQZGpSVL2fY1OT3esSfklNoNXx2F+wtWzwzhUdjsqGFnpyL14xZXNufsVQ3fV38V 7XGziT79avrp53rTFFZukBC80lnKsn1/Q321l9fVxNbcts/HH4a0TKnj3fRp46znfGXt/3Y3 pG4992WVnOzh8NvFj9LyhWYoyyw45J6ZKXrNYVK06WTvL2d8lViKMxINtZiLihMBeJYg+1YC AAA= Subject: Re: [MMUSIC] BUNDLE: Allowed to change local bundle port in SDP Answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 10:10:24 -0000 Hi, > Cannot see why the answerer should be prevented from changing the port an= d even the connection address and=20 > candidates etc. in any new answer any such restriction would seem to be a= major diversion from existing offer/answer=20 > procedures and I cannot see why we would want to consider it. > > We need to maintain the existing offer/answer procedures as much as possi= ble. Agree. Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 29 May 2013 10:36 To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE: Allowed to change local bundle port in SDP Answer= ? Hi, When the answerer receives the first bundle offer, it will assign a local b= undle port. Nothing strange there. Paul raised a question whether, when an updated offer is received, the answ= erer is allowed to change the local bundle port in the associated answer. Personally, I can't think of a reason why it should not be allowed - no mat= ter whether the offer contains different bundle ports or not - it would be = according to normal O/A procedures. If NOT allowed, if the answerer wants to change its local bundle port, it w= ould have to send a new offer by itself (the details of such offer is discu= ssed in another tread). Comments? Regards, Christer From prvs=58610ee6a3=christer.holmberg@ericsson.com Wed May 29 04:40:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA7921F9408 for ; Wed, 29 May 2013 04:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY3z-EoYE6ZM for ; Wed, 29 May 2013 04:39:58 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5D39921F93EF for ; Wed, 29 May 2013 04:39:57 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-be-51a5e90bbae5 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3F.6C.09795.B09E5A15; Wed, 29 May 2013 13:39:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Wed, 29 May 2013 13:39:55 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE TEXT: Answerer Procedures (29th May) Thread-Index: Ac5cYL6Xjkqad1ozQWuoyGt6QctbSA== Date: Wed, 29 May 2013 11:39:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C37B973ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+JvrS7Py6WBBnumc1lMXf6YxYHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3Bl7/ixnLZhxgLFi0XGVBsbjKxm7GDk5JARMJC4v2MsOYYtJ XLi3nq2LkYtDSOAwo8SVI3tZIJwljBJv/7UDZTg42AQsJLr/aYM0iAioS3zd28MMYgsDDeqa 8p0NIm4pcfnmMxYIW0/iwKqrYDaLgKrElAc/WUFsXgFfiTMrToLFGYEWfz+1hgnEZhYQl7j1 ZD4TxEECEkv2nGeGsEUlXj7+xwpygoSAosTyfjmI8nyJ7j0XoUYKSpyc+YRlAqPQLCSTZiEp m4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iZM9NzMxJLzffxAgM/INbfhvsYNx0 X+wQozQHi5I4rz7v4kAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBUcj4/dztkkLdTxov rbsXVWu7OvaVuKqldUpszbdqzW9az54KL/6p8NPp0rb1TLs87t2Y8FDyk/Qv5c3TNv6wfaGf Y8/NybGMd8GEC2c2uS+YxuGiLvs3vndRQofRlQTGs1a7XOdz1retK3lb9WzlHJat+ku+bgrY MmdtqLxSz5N7hyxu5wnZpiuxFGckGmoxFxUnAgBybWSfTwIAAA== Subject: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 11:40:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C37B973ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the e-mail and interim discussions, I've tried together some "Answ= erer Procedures" text for BUNDLE. For now, I would request that people mainly focus on the technical stuff, a= nd if some text is unclear. I WILL align the usage of "m=3D" line and "medi= a description" :) Also note that examples will be added later. Regards, Christer ----------------------------------------------------- 6.4. Answerer Procedures 6.4.1. General This section describes how an Answerer, when it receives an SDP Offer including a BUNDLE group, generates the associated SDP Answer. When an Answerer receives an SDP Offer which includes a BUNDLE group, and the Answerer accepts the offered BUNDLE group, the Answerer MUST generate an SDP Answer according to the procedures in Section 6.1 and this section. 6.4.2. RFC 5888 restrictions Based on the rules and procedures in RFC 5888, the following restrictions also apply to BUNDLE groups in SDP Answers: o 1) A BUNDLE group must not be added to an SDP Answer, unless the same BUNDLE group was included in the associated SDP Offer; and o 2) An SDP "m=3D" line must not be added to a BUNDLE group in the SDP Answer, unless it in the associated SDP Offer was included in the same BUNDLE group. 6.4.3. Offerer Bundle Address Selection In the SDP Answer, the Answerer selects the bundle address for the Offerer, based on the address information received in the associated SDP Offer, using the mid value. The mid value associated with the "m=3D" line in the SDP Offer that represents the bundle address MUST in the SDP Answer be located first in the mid value list added to SDP group:BUNDLE attribute associated with the BUNDLE group. From the associated SDP Offer, the Answerer SHOULD choose the bundle address associated with the mid value located first in the mid value list included in the SDP group:BUNDLE attribute associated with the BUNDLE group, unless: o 1) The mid value represents an "m=3D" line with a port zero value in the SDP Offer; or o 2) The mid value represents an "m=3D" line with a port zero value in the SDP Answer. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. 6.4.4. Answerer Bundle Address Selection In the SDP Answer, the Answerer selects its local bundle address. Each "m=3D" line included in a BUNDLE group MUST contain identical address information. The only exception is the usage of a zero port value for an "m=3D" line, which is allowed eventhough another port value number is used for other "m=3D" lines in the BUNDLE group. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. In a subsequent SDP Answer, the Answerer MAY change its local bundle address, as long as each "m=3D" line included the BUNDLE group contain identical address information. For a given BUNDLE group, the Answerer MUST NOT assign the bundle address to "m=3D" lines that are not included the BUNDLE group, or to "m=3D" lines that are included in another BUNDLE group. 6.4.5. Rejecting A BUNDLE Media Description When generating the SDP Answer, if the Answerer wants to reject media associated with an "m=3D" line in the BUNDLE group, it will add a zero port number value to the "m=3D" line, according to the procedures defined in RFC 3264. OPEN ISSUE: It is FFS whether it is allowed to include a port zero media descriptions in a BUNDLE group. 6.4.6. Removing a media description from a BUNDLE group When generating the SDP Answer, if the Answerer wants to remove an "m=3D" line from a BUNDLE group (without rejecting the "m=3D" line),it MUST NOT include the "m=3D" line in a BUNDLE group. In addition, the SDP Answer MUST not add its local bundle address to the "m=3D" line. An Answerer MUST NOT, in the SDP Answer, remove an "m=3D" line from a BUNDLE group, unless the "m=3D" line had unique address information in the associated SDP Offer. NOTE: The reason for the restriction above is that, if the "m=3D" line would be removed from the BUNDLE group, the address information would be identical to the "m=3D" lines remaining in the BUNDLE group. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. --_000_7594FB04B1934943A5C02806D1A2204B1C37B973ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the e-mail and interim discussions, I’= ;ve tried together some ”Answerer Procedures” text for BUNDLE.<= o:p>

 

For now, I would request that people mainly focus on= the technical stuff, and if some text is unclear. I WILL align the usage o= f “m=3D” line and “media description” :)=

 

Also note that examples will be added later.

 

Regards,

 

Christer

 

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

 

 

6.4.  Answerer Procedures

 

6.4.1.  General

 

   This section describes how an Answerer, when = it receives an SDP Offer

   including a BUNDLE group, generates the assoc= iated SDP Answer.

 

   When an Answerer receives an SDP Offer which = includes a BUNDLE group,

   and the Answerer accepts the offered BUNDLE g= roup, the Answerer MUST

   generate an SDP Answer according to the proce= dures in Section 6.1 and

   this section.

 

6.4.2.  RFC 5888 restrictions

 

   Based on the rules and procedures in RFC 5888= , the following

   restrictions also apply to BUNDLE groups in S= DP Answers:

 

   o  1) A BUNDLE group must not be added t= o an SDP Answer, unless the

      same BUNDLE group was inclu= ded in the associated SDP Offer; and

 

   o  2) An SDP "m=3D" line must = not be added to a BUNDLE group in the SDP

      Answer, unless it in the as= sociated SDP Offer was included in the

      same BUNDLE group.

 

6.4.3.  Offerer Bundle Address Selection

 

   In the SDP Answer, the Answerer selects the b= undle address for the

   Offerer, based on the address information rec= eived in the associated

   SDP Offer, using the mid value.  The mid= value associated with the

   "m=3D" line in the SDP Offer that r= epresents the bundle address MUST in

   the SDP Answer be located first in the mid va= lue list added to SDP

   group:BUNDLE attribute associated with the BU= NDLE group.

 

   From the associated SDP Offer, the Answerer S= HOULD choose the bundle

   address associated with the mid value located= first in the mid value

   list included in the SDP group:BUNDLE attribu= te associated with the

   BUNDLE group, unless:

 

   o  1) The mid value represents an "= m=3D" line with a port zero value in

      the SDP Offer; or

 

   o  2) The mid value represents an "= m=3D" line with a port zero value in

      the SDP Answer.<= /span>

 

   OPEN: The decision for allowing a media descr= iption with port zero

   values inside a BUNDLE group is pending on up= date for RFC 5888.

 

6.4.4.  Answerer Bundle Address Selection<= /span>

 

   In the SDP Answer, the Answerer selects its l= ocal bundle address.

   Each "m=3D" line included in a BUND= LE group MUST contain identical

   address information.  The only exception= is the usage of a zero port

   value for an "m=3D" line, which is = allowed eventhough another port

   value number is used for other "m=3D&quo= t; lines in the BUNDLE group.

 

   OPEN: The decision for allowing a media descr= iption with port zero

   values inside a BUNDLE group is pending on up= date for RFC 5888.

 

   In a subsequent SDP Answer, the Answerer MAY = change its local bundle

   address, as long as each "m=3D" lin= e included the BUNDLE group contain

   identical address information.

 

   For a given BUNDLE group, the Answerer MUST N= OT assign the bundle

   address to "m=3D" lines that are no= t included the BUNDLE group, or to

   "m=3D" lines that are included in a= nother BUNDLE group.

 

6.4.5.  Rejecting A BUNDLE Media Description

 

   When generating the SDP Answer, if the Answer= er wants to reject media

   associated with an "m=3D" line in t= he BUNDLE group, it will add a zero

   port number value to the "m=3D" lin= e, according to the procedures

   defined in RFC 3264.

 

   OPEN ISSUE: It is FFS whether it is allowed t= o include a port zero

   media descriptions in a BUNDLE group.

 

6.4.6.  Removing a media description from a BUNDLE gr= oup

 

   When generating the SDP Answer, if the Answer= er wants to remove an

   "m=3D" line from a BUNDLE group (wi= thout rejecting the "m=3D" line),it

   MUST NOT include the "m=3D" line in= a BUNDLE group.  In addition, the

   SDP Answer MUST not add its local bundle addr= ess to the "m=3D" line.

 

   An Answerer MUST NOT, in the SDP Answer, remo= ve an "m=3D" line from a

   BUNDLE group, unless the "m=3D" lin= e had unique address information in

   the associated SDP Offer.

 

   NOTE: The reason for the restriction above is= that, if the "m=3D" line

   would be removed from the BUNDLE group, the a= ddress information would

   be identical to the "m=3D" lines re= maining in the BUNDLE group.

 

   OPEN: The decision for allowing a media descr= iption with port zero

   values inside a BUNDLE group is pending on up= date for RFC 5888.

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C37B973ESESSMB209erics_-- From internet-drafts@ietf.org Wed May 29 06:01:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E549B21F81FF; Wed, 29 May 2013 06:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTzs7ohMg119; Wed, 29 May 2013 06:01:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2EE21F85C0; Wed, 29 May 2013 06:00:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130529130047.4074.73290.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2013 06:00:47 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:01:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : The Evaluation of Different Network Address Translator (= NAT) Traversal Techniques for Media Controlled by Real-time Streaming Proto= col (RTSP) Author(s) : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-09.txt Pages : 40 Date : 2013-05-29 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 on 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 relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0. 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-evaluation-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=5861de56fe=magnus.westerlund@ericsson.com Wed May 29 06:02:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6355021F8B45 for ; Wed, 29 May 2013 06:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uR3vTPco7mqw for ; Wed, 29 May 2013 06:02:25 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AE7F421F8629 for ; Wed, 29 May 2013 06:02:24 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-3e-51a5fc5fa8b2 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BD.DA.09795.F5CF5A15; Wed, 29 May 2013 15:02:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 29 May 2013 15:02:23 +0200 Message-ID: <51A5FC6D.9010106@ericsson.com> Date: Wed, 29 May 2013 15:02:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= References: <518BB81A.8090608@cisco.com> <51965190.10900@ericsson.com> <519E2BF8.7040500@ericsson.com> <519E58D1.6080600@ericsson.com> <51A3278D.8060402@ericsson.com> <51A5CFA2.30801@ericsson.com> In-Reply-To: <51A5CFA2.30801@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+JvrW78n6WBBhO/qFrc7X3BZDF1+WMW ByaPJUt+Mnl8ufyZLYApitsmKbGkLDgzPU/fLoE7482EY6wFkzgqfj/eydLAuJGti5GTQ0LA RGJu1z52CFtM4sK99UBxLg4hgVOMEpdW7mGHcJYzSix4/4AJpIpXQFvi6oJpYN0sAqoSHZ/u sIDYbAIWEjd/NILFRQWCJY5s38wCUS8ocXLmEzBbRMBWYs7VtWDbmAVCJf5cXANWLyzgJ9F3 aCcTxLIjjBJX1h4CS3AKaEls/HmYGeI8SYktL9qhmvUkplxtYYSw5SWat84GqxECOq6hqYN1 AqPQLCS7ZyFpmYWkZQEj8ypG9tzEzJz0cvNNjMCAPbjlt8EOxk33xQ4xSnOwKInz6vMuDhQS SE8sSc1OTS1ILYovKs1JLT7EyMTBCSK4pBoYY/veXpvV52bC+fpU1v5pc5dtV2LbVMVSITr5 kOwiBTYD91sPq9/zH5+Q/eXA5fjzk5ben6smxXzHoKGrfu8k6Y3PT7anc64urN6b0qXT5bo0 Y8PELL95B1nbJgktzNi8Ks7y+2S/iWKvPl27pdTA3nE3Pirb7W+i9zO5mvIvOx7eiLBjLVy5 UImlOCPRUIu5qDgRADDLMEgrAgAA Cc: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:02:31 -0000 On 2013-05-29 11:51, Ari Keränen wrote: > Hi Magnus, > > The diff looked good. Couple of quick nits: > > 5. The RTSP Client uses the RTSP Servers response to create TURN > > s/Servers/Server's/ > > 7. The first media packet to arrive at the TURN server on the > external port; If matching established permissions the TURN > server forwards the media packets to the RTSP client. > > s/If matching/If there exists a matching/ > or /If the packet matches an/ > Thanks, I have updated the draft to resolve these issues. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From pkyzivat@alum.mit.edu Wed May 29 07:23:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E39221F9121 for ; Wed, 29 May 2013 07:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TewMZ-o3vGEN for ; Wed, 29 May 2013 07:23:20 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id DDA9421F9060 for ; Wed, 29 May 2013 07:23:14 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta12.westchester.pa.mail.comcast.net with comcast id hpF51l0040bG4ec5CqPEWE; Wed, 29 May 2013 14:23:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id hqPD1l0103ZTu2S3PqPDym; Wed, 29 May 2013 14:23:14 +0000 Message-ID: <51A60F50.9020902@alum.mit.edu> Date: Wed, 29 May 2013 10:23:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37B973@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=1369837394; bh=QauSHbfJp9oEHNEA77uWYWB/H1kCbZKb9/BCGVnmxOk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TP+9wEx3Hd9jRjL5ElTGuMF+ctj+kKtDMPDdN5gS8IqmBnkjEAvUa7lgoVmtfZFK7 miimvzW4dhllNIHtyklg/t/aJTT8yzWY/U/P/6nFoBjg86zexkcm8zc2sSPxPKS9yE ITvYHwKJb67Zl3r+PKey6E5FqvUnwX7LhwdzZUAN08xgmewxmA07F0x9jgH4rp74CU 0kyPaX2ntjMsJDsYXWJ48CU4yq9v4uo8+gHuvP+Rbf/nn/aKfGdshhvbvML0ipgxM3 rSNkT56DnrPRqyO0xqN5eiuFEOgGcvtDm6ysAhTjQUE8yJL37p+GCzAQdBt0hJy9vd Y1ChmMZmHyeOw== Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:23:29 -0000 Christer, This seems good to me, pending polishing the language. I trust when you say "address information" you mean: - the port in the m-line - the address in the c-line - associated ICE information Obviously it would be cumbersome to mention all of that each time you need to refer to address information. So I'm expecting you will coin a term (e.g., "address information") and provide a definition of it. Thanks, Paul On 5/29/13 7:39 AM, Christer Holmberg wrote: > Hi, > > Based on the e-mail and interim discussions, I’ve tried together some > ”Answerer Procedures” text for BUNDLE. > > For now, I would request that people mainly focus on the technical > stuff, and if some text is unclear. I WILL align the usage of “m=” line > and “media description” :) > > Also note that examples will be added later. > > Regards, > > Christer > > ----------------------------------------------------- > > 6.4. Answerer Procedures > > 6.4.1. General > > This section describes how an Answerer, when it receives an SDP Offer > > including a BUNDLE group, generates the associated SDP Answer. > > When an Answerer receives an SDP Offer which includes a BUNDLE group, > > and the Answerer accepts the offered BUNDLE group, the Answerer MUST > > generate an SDP Answer according to the procedures in Section 6.1 and > > this section. > > 6.4.2. RFC 5888 restrictions > > Based on the rules and procedures in RFC 5888, the following > > restrictions also apply to BUNDLE groups in SDP Answers: > > o 1) A BUNDLE group must not be added to an SDP Answer, unless the > > same BUNDLE group was included in the associated SDP Offer; and > > o 2) An SDP "m=" line must not be added to a BUNDLE group in the SDP > > Answer, unless it in the associated SDP Offer was included in the > > same BUNDLE group. > > 6.4.3. Offerer Bundle Address Selection > > In the SDP Answer, the Answerer selects the bundle address for the > > Offerer, based on the address information received in the associated > > SDP Offer, using the mid value. The mid value associated with the > > "m=" line in the SDP Offer that represents the bundle address MUST in > > the SDP Answer be located first in the mid value list added to SDP > > group:BUNDLE attribute associated with the BUNDLE group. > > From the associated SDP Offer, the Answerer SHOULD choose the bundle > > address associated with the mid value located first in the mid value > > list included in the SDP group:BUNDLE attribute associated with the > > BUNDLE group, unless: > > o 1) The mid value represents an "m=" line with a port zero value in > > the SDP Offer; or > > o 2) The mid value represents an "m=" line with a port zero value in > > the SDP Answer. > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > 6.4.4. Answerer Bundle Address Selection > > In the SDP Answer, the Answerer selects its local bundle address. > > Each "m=" line included in a BUNDLE group MUST contain identical > > address information. The only exception is the usage of a zero port > > value for an "m=" line, which is allowed eventhough another port > > value number is used for other "m=" lines in the BUNDLE group. > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > In a subsequent SDP Answer, the Answerer MAY change its local bundle > > address, as long as each "m=" line included the BUNDLE group contain > > identical address information. > > For a given BUNDLE group, the Answerer MUST NOT assign the bundle > > address to "m=" lines that are not included the BUNDLE group, or to > > "m=" lines that are included in another BUNDLE group. > > 6.4.5. Rejecting A BUNDLE Media Description > > When generating the SDP Answer, if the Answerer wants to reject media > > associated with an "m=" line in the BUNDLE group, it will add a zero > > port number value to the "m=" line, according to the procedures > > defined in RFC 3264. > > OPEN ISSUE: It is FFS whether it is allowed to include a port zero > > media descriptions in a BUNDLE group. > > 6.4.6. Removing a media description from a BUNDLE group > > When generating the SDP Answer, if the Answerer wants to remove an > > "m=" line from a BUNDLE group (without rejecting the "m=" line),it > > MUST NOT include the "m=" line in a BUNDLE group. In addition, the > > SDP Answer MUST not add its local bundle address to the "m=" line. > > An Answerer MUST NOT, in the SDP Answer, remove an "m=" line from a > > BUNDLE group, unless the "m=" line had unique address information in > > the associated SDP Offer. > > NOTE: The reason for the restriction above is that, if the "m=" line > > would be removed from the BUNDLE group, the address information would > > be identical to the "m=" lines remaining in the BUNDLE group. > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Wed May 29 07:42:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010C021F9007 for ; Wed, 29 May 2013 07:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gYNI+P9ZRQG for ; Wed, 29 May 2013 07:41:59 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id C72FE21F8AD8 for ; Wed, 29 May 2013 07:41:56 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta14.westchester.pa.mail.comcast.net with comcast id hoia1l0031ZXKqc5EqhwMM; Wed, 29 May 2013 14:41:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id hqhv1l01U3ZTu2S3hqhwoo; Wed, 29 May 2013 14:41:56 +0000 Message-ID: <51A613B2.70701@alum.mit.edu> Date: Wed, 29 May 2013 10:41:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> <519E8CA6.1090009@alum.mit.edu> <51A3802A.1090203@alum.mit.edu> In-Reply-To: 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=1369838516; bh=/Tp2eXqHKkG2nqsI/fqRfi/uIg9nLQENDVU5H8mA0IY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tjpXPj4s0h/zqknffVfQOtJoPW89vKuTQx4fepJLQOXDdnSh4rvkiO4+uQ7LslK37 99Wj6moStUjL8rdg0tXbEop33FaOcQJQgIeq7xn8mLessbEuuddp93HL2R56GKFpn0 Eh5NLpmF75KvE1jehfyhn//43zYSbcz/JB9TYMaQVVMOtjczw8fnqhs8psE6iIFM+0 JnMI5h1Ye2gx3UKrw7KMnD9fo6jTlY++ANpKCeMzFZMbdwS8aykyPUjA0D3OvILNMd lD+mDelwXu0qnocg8gvK+wYQByrUye9DQucPclKRIVo1XlJMc9K+40v26afgXy/ZSH JyQLd+5O1CloA== Cc: "Cullen Jennings \(fluffy\)" , Christer Holmberg , mmusic Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:42:05 -0000 Martin, On 5/28/13 12:34 PM, Martin Thomson wrote: > On 28 May 2013 09:16, Martin Thomson wrote: >> On 27 May 2013 08:47, Paul Kyzivat wrote: >>> no > > FWIW, I can live with that. (Sorry about the earlier empty email.) I > was simply trying to be aggressively minimalist. > > This model requires that each m-line has two independently negotiable > properties: > - accepted/rejected (signaled using zero port) > - bundle membership (signaled using a=group) > > (and yes, this requires an update to 5888) > > Then we need, as you describe, rules for transitioning between states. > > Transition between accepted and rejected is always possible in both > offers and answers. Agreed. > It seems like we are saying that bundle membership can transition in > the following ways: > > Any group to no group: > - In an offer, under all circumstances. > - In an answer, if the m-line is rejected. > - In an answer, if unique transport parameters are provided in the offer. Agreed. > No group to any group: > - In an offer, under all circumstances. > - In an answer, never. Agreed. > Any group to any other group: > - In an offer, if the m-line was previously rejected. Agreed. > - In an answer, if the lines were offered as a bundle and there are > sufficient transport parameters on offer. I don't understand what you mean here. What are "sufficient transport parameters on offer"? Do you mean when the addr/port in the offered m-line is unique? I hadn't considered that case. I'm thinking its a bad idea to allow this, because it creates a bundling situation that the offerer hasn't consented to and has no way of refusing. > Is that the rules you would like to see? Yes, aside from my comment about the last one. You describe it more clearly than I did. > I think that the last option > (splitting) is the only one that I haven't seen anyone else slavering > for. The model permits it, but I'd rather prohibit features fix it up > later than start with something that ends up too permissive. Without the last rule splitting is still possible, but it requires two O/A cycles. In the splitting case I have in mind, the initial offer puts a bunch of m-lines in one bundle. The answerer is decomposed so that it can't handle them all in one bundle. But perhaps it can handle them in two bundles. (The 2nd bundle has never been mentioned yet.) So in its answer it refuses the m-lines that it wants in a separate bundle. Then it sends another offer, reviving the previously refused m-lines and putting them into a new bundle. This can be accomplished with the rules you give above, dropping the last one. While it would be nice to accomplish this in a single O/A, I can see no way to accomplish that while giving both sides an opportunity to refuse what it can't do. Thanks, Paul > For example, it would be possible to split a bundle that had multiple > m-lines and only two sets of transport parameters like the following: > > offer: > BUNDLE 1 2 3 4 > mid:1 transport A > mid:2 transport A > mid:3 transport A > mid:4 transport B > > answer: > BUNDLE 1 2 > BUNDLE 4 3 > > Despite a (possible) preference from the offerer for bundling 1-3 > together, 3 has been split off. > > I'm sure that we can get the rules right, but I like avoiding these > sorts of little complications. > From martin.thomson@gmail.com Wed May 29 11:35:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9788821F8F87 for ; Wed, 29 May 2013 11:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ndvTa-7eNly for ; Wed, 29 May 2013 11:35:40 -0700 (PDT) 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 CB48F21F88A9 for ; Wed, 29 May 2013 11:35:37 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w62so6769185wes.17 for ; Wed, 29 May 2013 11:35:36 -0700 (PDT) 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=ACOEY7q1SYHJ12fmu1ZsSiIJwuBulBbGJHN0gXscobw=; b=oWie9OEqb1bw1ut2NTZmHOiaqAwN9mk2xpXWRCYqdlSmdus4Mjx2X+OP9aAEGM83+h R4S1tcHQwgA7X7kyn9HHVGMJ5Zcs71DBKPUQ96/xKfOicgz/ToX19khV2+WBT/ioWMcH z4ulMVWfZSf+PgQaNlDN0He065w3Dge2JGBMUyZsvwVx4kGLACGw8RMVy/3Qplm/cnTS HBzmwm/dWnw+ODZzGgWXNZg2HTwND0JOLwXvTtjIvf8p6kArQw4jlJOqlwvGUEW10DoN dPvQCucoZ8M5MxgX7CMYxFJLTaZp4z5EVVRjVcfe60tyA6nplziwzMPcwb0IDGld7AOG HcOQ== MIME-Version: 1.0 X-Received: by 10.194.174.137 with SMTP id bs9mr1078517wjc.59.1369852536647; Wed, 29 May 2013 11:35:36 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Wed, 29 May 2013 11:35:36 -0700 (PDT) In-Reply-To: <51A613B2.70701@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519CCE58.3000807@alum.mit.edu> <519E8CA6.1090009@alum.mit.edu> <51A3802A.1090203@alum.mit.edu> <51A613B2.70701@alum.mit.edu> Date: Wed, 29 May 2013 11:35:36 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , Christer Holmberg , mmusic Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 18:35:41 -0000 On 29 May 2013 07:41, Paul Kyzivat wrote: > This can be accomplished with the rules you give above, dropping the last > one. Oh good. I was worried that you might want to split on answer. The revised last rule set is: Any group to any other group: - In an offer, if the m-line was previously rejected. - In an answer, never. From fandreas@cisco.com Wed May 29 14:16:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C2921F96FE; Wed, 29 May 2013 14:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67jssf2KlQZc; Wed, 29 May 2013 14:15:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3921F96EC; Wed, 29 May 2013 14:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1278; q=dns/txt; s=iport; t=1369862157; x=1371071757; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=HScF0FcPhA9HulXcyFaeavZi4+wLM6AwogZw4PMWneY=; b=mq4TzzoeFtGXQpqG/sI4IU3nVDm5yNNFNj9pwkSshW9edx60uSr5VW4q Z2RDG3Oz4fp90BQLaY5WAAbih9RmldIt94hGim0JP1I9tymYmqg+BN8hq Yjt5zxe/avMHfLVF8zAd0m8LPKceZZen75lc13bNBIQgxP7P1moO0rBep U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokGAM9uplGtJV2b/2dsb2JhbABagwkwwgSBChZ0gmJBPDQCTA0BBwEBBYgEDLl9jxODXgOXO5FAgysg X-IronPort-AV: E=Sophos;i="4.87,766,1363132800"; d="scan'208";a="216454514" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 29 May 2013 21:15:56 +0000 Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4TLFtTs019149; Wed, 29 May 2013 21:15:56 GMT Message-ID: <51A6700B.40108@cisco.com> Date: Wed, 29 May 2013 17:15:55 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: IETF Announcement List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 21:16:02 -0000 Greetings This is to announce a(nother) virtual interim meeting for the MMUSIC Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari & Flemming (MMUSIC co-chairs) PS: Per our previous interim meeting announcement, we tried to schedule a longer and in-person physical interim meeting, however it has proven impossible to find a set of dates where we could get critical mass for such a meeting. Scheduling even a virtual interim before the Berlin IETF has been surprisingly difficult with the above date being the only viable option at this point. From fandreas@cisco.com Wed May 29 14:23:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5721F9724 for ; Wed, 29 May 2013 14:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHqsc5+WZ9lU for ; Wed, 29 May 2013 14:23:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DF70921F9719 for ; Wed, 29 May 2013 14:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1586; q=dns/txt; s=iport; t=1369862622; x=1371072222; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kebMiLlC6Mz2S0icpy9y8TuR5qrZFLY2QtgA4cYMvv0=; b=Tu8Ilhc+s/ovyTWNKyRGqRsbzWlW4CBpsivp1PwMbI9sAeCa+GagNq8r rtgNB3ZYolMWstaxEC5Hi7o4n/5alrfDFjedXyqhAo51fOpAGwTzzUdJ/ ZDyepX6hTBfJnoGhpoPqPtq/bk4sUWGAkJpnhWouasSTnJoLA+VOmTE+0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0GAG1vplGtJXG9/2dsb2JhbABagwkwQ8FBgQoWdIIjAQEBBAEBAS8BBTYKARALGAkWDwkDAgECARUwBg0BBQIBAQUSh3IHBbl7jxMHg1cDlzuRQIMrIA X-IronPort-AV: E=Sophos;i="4.87,766,1363132800"; d="scan'208";a="216250491" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 29 May 2013 21:23:41 +0000 Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4TLNe2m019626; Wed, 29 May 2013 21:23:40 GMT Message-ID: <51A671DC.1070101@cisco.com> Date: Wed, 29 May 2013 17:23:40 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Magnus Westerlund References: <519638D5.9030301@cisco.com> <51A28787.3090709@ericsson.com> <51A32E8B.7030909@ericsson.com> <51A5D017.6070102@ericsson.com> In-Reply-To: <51A5D017.6070102@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 21:23:52 -0000 Thank you for the comments and updates to the draft. This concludes the WGLC and we will proceed with a publication request at this point. Regards -- Flemming (MMUSIC co-chair) On 5/29/13 5:53 AM, Ari Keränen wrote: > Hi Magnus, > > The changes look good to me. > > > Thanks, > Ari > > On 5/27/13 12:59 PM, Magnus Westerlund wrote: >> Hi Ari, >> >> Thanks for these fixes. I have implemented them: >> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-16 >> >> Cheers >> >> Magnus >> >> On 2013-05-27 00:07, Ari Keränen wrote: >>> Hi, >>> >>> Here's a few editorial things worth considering fixing. >>> >>> >>> 3. Solution Overview >>> >>> 9. When the client has concluded its connectivity checks, >>> including >>> promoting candidates, and has correspondingly received the >>> >>> s/promoting candidates/nominating candidate pairs/ >>> (using "promoting/promoted" also later in the document) >>> >>> >>> 4.2. ICE Candidate Transport Header Parameter >>> >>> : [...] >>> It MUST start at 1 and MUST increment by 1 for each component >>> of a particular candidate >>> >>> s/of a particular candidate/of a particular media stream/ >>> >>> >>> In section 6.4 you talk about "SO" connection types; makes sense to >>> expand that into "Simultaneous Open". >>> >>> >>> Cheers, >>> Ari (as individual) >>> >>> >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From martin.thomson@gmail.com Wed May 29 15:19:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2737621F882A for ; Wed, 29 May 2013 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkG26YePfXWp for ; Wed, 29 May 2013 15:19:16 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id B00D821F8808 for ; Wed, 29 May 2013 15:19:15 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id w20so9466239lbh.26 for ; Wed, 29 May 2013 15:19:14 -0700 (PDT) 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=RHmFDTtjLYZ5HobFDcbS4owyxucho3PEHvgBEVp7hE8=; b=wkgLPRStOmaS36ZrCPcNThvIpThu0mY9q2LQ5vr1W1VjyLCF+Ga5a5jwbNzjCa8KDV 8q66MEhd9+aSnRZtg5MJlnixd77SueGJvZAHGms+5bZNcXm4cPIG26flIwP9+Bn0bZp7 fg+AxSA2DTCk0ilMhGCMz21EShISm73cwQvRiuGzFvjGGs8zAcGcV4LxFEk16Ryxq93Q ibwafI+3pGIwFC4zvDevkp09lw1KbpJ7QAQxo2+xZAId/Zx66l/YYpWz6jypvdICHJIU 27qaUxHP+lro19wzh4yILy3udZNiytlDq2BlIwZniXz0++rh8Yxu1o23ab/CVgaJj52z D8ZQ== MIME-Version: 1.0 X-Received: by 10.112.146.198 with SMTP id te6mr2444710lbb.133.1369865954649; Wed, 29 May 2013 15:19:14 -0700 (PDT) Received: by 10.112.154.161 with HTTP; Wed, 29 May 2013 15:19:14 -0700 (PDT) In-Reply-To: <51A6700B.40108@cisco.com> References: <51A6700B.40108@cisco.com> Date: Wed, 29 May 2013 15:19:14 -0700 Message-ID: From: Martin Thomson To: Flemming Andreasen Content-Type: text/plain; charset=UTF-8 Cc: mmusic Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 22:19:20 -0000 On 29 May 2013 14:15, Flemming Andreasen wrote: > You may also want to look at http://tools.ietf.org/html/draft-ivov-rtcweb-noplan ? From mary.ietf.barnes@gmail.com Wed May 29 15:35:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDA021F96B1 for ; Wed, 29 May 2013 15:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw8759l2oi91 for ; Wed, 29 May 2013 15:35:23 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0F21F96B0 for ; Wed, 29 May 2013 15:35:23 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bv4so683613qab.19 for ; Wed, 29 May 2013 15:35:22 -0700 (PDT) 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=rjBaLwXkZRtc/O7TyflAspUoHKhqAHEIIYZJj/sWuB0=; b=BcPf69IIXDIqGXBVQT6A0Q4tavi/8LI5PJTJq9P0ARgTL5w8zX98uTfZRgPgOoOaw3 jJarouOSo4Td9GTtoUwDIQKHldYrSlDMNj8qwWHWxDRzcmYt03Rt0iYgqguHkOlBlsoN tLfunym7XsaiaQu0RETSINLYKnDMswSd4rCZ1Pw3RK9PGS9BDOKuAIf3jFmp9U/YrvSn QG+Vwi6PbSTYZqXP+IcyM9oNTMSOPHln/pmH7vUcDrO0ID17uQfc/RX/EMFmI4SMUofg j6koWSOatUbG9FtBrNNu5T65dU02oaSZac2V81EDIjvtS1L6ZKdEu8kS9o9Z6xDbUTiK w+7A== MIME-Version: 1.0 X-Received: by 10.229.177.10 with SMTP id bg10mr1704031qcb.135.1369866922676; Wed, 29 May 2013 15:35:22 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Wed, 29 May 2013 15:35:22 -0700 (PDT) In-Reply-To: References: <51A6700B.40108@cisco.com> Date: Wed, 29 May 2013 17:35:22 -0500 Message-ID: From: Mary Barnes To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 22:35:24 -0000 I would certainly hope that this draft would also be on the agenda. Mary. On Wed, May 29, 2013 at 5:19 PM, Martin Thomson wrote: > On 29 May 2013 14:15, Flemming Andreasen wrote: >> You may also want to look at > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > ? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From prvs=88623dc6f3=christer.holmberg@ericsson.com Wed May 29 23:27:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C936E21F9413 for ; Wed, 29 May 2013 23:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCfbei-fpWgt for ; Wed, 29 May 2013 23:27:39 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE7021F9410 for ; Wed, 29 May 2013 23:27:38 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-7f-51a6f159d1f7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 4A.E0.09795.951F6A15; Thu, 30 May 2013 08:27:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Thu, 30 May 2013 08:27:37 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) Thread-Index: Ac5cYL6Xjkqad1ozQWuoyGt6QctbSAABoqcAACXMJdA= Date: Thu, 30 May 2013 06:27:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37CFE4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> <51A60F50.9020902@alum.mit.edu> In-Reply-To: <51A60F50.9020902@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+JvrW7Ux2WBBjdecFlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFLdNUmJJWXBmep6+XQJ3xt7r89gLdulX3Jk1m6mBcY9yFyMHh4SA icT150VdjJxAppjEhXvr2UBsIYHDjBJdp0S7GLmA7CWMEp17X7GB1LMJWEh0/9MGqRER8JV4 9vg2WL2wgKPE7qtnmCDiThJPf61hh7CtJGatvcQMYrMIqEqc3XcNrIYXqPfFaYi4kEC+xNSF PWD1nAI6EptunQarYQS65/upNWA2s4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VohXFCWW98tB lOtILNj9iQ3C1pZYtvA1M8RaQYmTM5+wTGAUnYVk6iwkLbOQtMxC0rKAkWUVI3tuYmZOern5 JkZgHBzc8ttgB+Om+2KHGKU5WJTEefV5FwcKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFIN jFsTds9N2TDn2SIP3jW5sj2e09NvN3Rc23M4deL+nTclt+1i86ra+dZR+djJXwESJh323//O O54vEjUzUlTIgFtnoZXgljec3/9u/DprmRrL+cdZT1h+HDxo4/7R60nOj3yBksSrv4ukm/f3 fLXUfFPleulT5qlpkqWR75WvbshVll43696i81eUWIozEg21mIuKEwFd911nVgIAAA== Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:27:44 -0000 Hi, > This seems good to me, pending polishing the language. > > I trust when you say "address information" you mean: > - the port in the m-line > - the address in the c-line > - associated ICE information > > Obviously it would be cumbersome to mention all of that each time you nee= d to refer to address information. So I'm expecting you will coin a term (e= .g., "address information") and provide a definition of it. Yes. There is going to be a separate section which describes that more in d= etail.=20 Thanks! Regards, Christer On 5/29/13 7:39 AM, Christer Holmberg wrote: > Hi, > > Based on the e-mail and interim discussions, I've tried together some=20 > "Answerer Procedures" text for BUNDLE. > > For now, I would request that people mainly focus on the technical=20 > stuff, and if some text is unclear. I WILL align the usage of "m=3D"=20 > line and "media description" :) > > Also note that examples will be added later. > > Regards, > > Christer > > ----------------------------------------------------- > > 6.4. Answerer Procedures > > 6.4.1. General > > This section describes how an Answerer, when it receives an SDP=20 > Offer > > including a BUNDLE group, generates the associated SDP Answer. > > When an Answerer receives an SDP Offer which includes a BUNDLE=20 > group, > > and the Answerer accepts the offered BUNDLE group, the Answerer=20 > MUST > > generate an SDP Answer according to the procedures in Section 6.1=20 > and > > this section. > > 6.4.2. RFC 5888 restrictions > > Based on the rules and procedures in RFC 5888, the following > > restrictions also apply to BUNDLE groups in SDP Answers: > > o 1) A BUNDLE group must not be added to an SDP Answer, unless=20 > the > > same BUNDLE group was included in the associated SDP Offer; and > > o 2) An SDP "m=3D" line must not be added to a BUNDLE group in the=20 > SDP > > Answer, unless it in the associated SDP Offer was included in=20 > the > > same BUNDLE group. > > 6.4.3. Offerer Bundle Address Selection > > In the SDP Answer, the Answerer selects the bundle address for the > > Offerer, based on the address information received in the=20 > associated > > SDP Offer, using the mid value. The mid value associated with the > > "m=3D" line in the SDP Offer that represents the bundle address MUST= =20 > in > > the SDP Answer be located first in the mid value list added to SDP > > group:BUNDLE attribute associated with the BUNDLE group. > > From the associated SDP Offer, the Answerer SHOULD choose the=20 > bundle > > address associated with the mid value located first in the mid=20 > value > > list included in the SDP group:BUNDLE attribute associated with=20 > the > > BUNDLE group, unless: > > o 1) The mid value represents an "m=3D" line with a port zero value= =20 > in > > the SDP Offer; or > > o 2) The mid value represents an "m=3D" line with a port zero value= =20 > in > > the SDP Answer. > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > 6.4.4. Answerer Bundle Address Selection > > In the SDP Answer, the Answerer selects its local bundle address. > > Each "m=3D" line included in a BUNDLE group MUST contain identical > > address information. The only exception is the usage of a zero=20 > port > > value for an "m=3D" line, which is allowed eventhough another port > > value number is used for other "m=3D" lines in the BUNDLE group. > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > In a subsequent SDP Answer, the Answerer MAY change its local=20 > bundle > > address, as long as each "m=3D" line included the BUNDLE group=20 > contain > > identical address information. > > For a given BUNDLE group, the Answerer MUST NOT assign the bundle > > address to "m=3D" lines that are not included the BUNDLE group, or=20 > to > > "m=3D" lines that are included in another BUNDLE group. > > 6.4.5. Rejecting A BUNDLE Media Description > > When generating the SDP Answer, if the Answerer wants to reject=20 > media > > associated with an "m=3D" line in the BUNDLE group, it will add a=20 > zero > > port number value to the "m=3D" line, according to the procedures > > defined in RFC 3264. > > OPEN ISSUE: It is FFS whether it is allowed to include a port zero > > media descriptions in a BUNDLE group. > > 6.4.6. Removing a media description from a BUNDLE group > > When generating the SDP Answer, if the Answerer wants to remove an > > "m=3D" line from a BUNDLE group (without rejecting the "m=3D" line),i= t > > MUST NOT include the "m=3D" line in a BUNDLE group. In addition,=20 > the > > SDP Answer MUST not add its local bundle address to the "m=3D" line. > > An Answerer MUST NOT, in the SDP Answer, remove an "m=3D" line from=20 > a > > BUNDLE group, unless the "m=3D" line had unique address information=20 > in > > the associated SDP Offer. > > NOTE: The reason for the restriction above is that, if the "m=3D"=20 > line > > would be removed from the BUNDLE group, the address information=20 > would > > be identical to the "m=3D" lines remaining in the BUNDLE group. > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > _______________________________________________ > 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 kevindempsey70@gmail.com Thu May 30 01:18:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F6021F97E2 for ; Thu, 30 May 2013 01:18:48 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8+t3UAyE+3y for ; Thu, 30 May 2013 01:18:46 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03421F980E for ; Thu, 30 May 2013 01:18:28 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hn14so4242669wib.7 for ; Thu, 30 May 2013 01:18:27 -0700 (PDT) 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=SLXcIaQAw9ujiskptr3XrIHDZqLU0pz2dWUjJLbslcI=; b=FBFpXbhou9GtxqVPyJ2JCRtudBftErLeMSB79erp5VbHZE0V3HG5h8vV8nA6rpgroA 6fz+GCLzvJBLRq125e5N6F8uazmsFHAtCQfX2vPcYMZ3joqRwQbqL/urGIKVbPgmqe0y 1jrfQje/CFrRoB1ewDXgWJyc+p1uKlJGo6hjcwuNZWwP+gl6rCDrZdiiT8yvL1V2SdgQ +Qmutkx69Q7P8OOADeA8QWnwEsa26rMY07H6+qI1or666DpvEDV4AQBt3huS5eLr2pST jzLcwX2mgKUmtimVBZBm8/ml+0BJNop1j2xE9ouPZ188a8DqR2EXrnR5H13yX7PiRTzu fTyQ== MIME-Version: 1.0 X-Received: by 10.180.185.225 with SMTP id ff1mr3390778wic.36.1369901907676; Thu, 30 May 2013 01:18:27 -0700 (PDT) Received: by 10.180.146.196 with HTTP; Thu, 30 May 2013 01:18:27 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37CFE4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> <51A60F50.9020902@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C37CFE4@ESESSMB209.ericsson.se> Date: Thu, 30 May 2013 09:18:27 +0100 Message-ID: From: Kevin Dempsey To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c34ed29591e404ddeb247f Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:18:49 -0000 --001a11c34ed29591e404ddeb247f Content-Type: text/plain; charset=ISO-8859-1 Can we add that the answerer must also ensure that it can de-mulitplex the media it will receive? That is, it must either agree to a de-mulitplex scheme that was offered (either in the SDP, such as SSRC signalling, or external signalling) or ensure that there is no PT overlap in the bundle by not including certain PTs or by unbundling one or more m-lines. On 30 May 2013 07:27, Christer Holmberg wrote: > Hi, > > > This seems good to me, pending polishing the language. > > > > I trust when you say "address information" you mean: > > - the port in the m-line > > - the address in the c-line > > - associated ICE information > > > > Obviously it would be cumbersome to mention all of that each time you > need to refer to address information. So I'm expecting you will coin a term > (e.g., "address information") and provide a definition of it. > > Yes. There is going to be a separate section which describes that more in > detail. > > Thanks! > > Regards, > > Christer > > > > > On 5/29/13 7:39 AM, Christer Holmberg wrote: > > Hi, > > > > Based on the e-mail and interim discussions, I've tried together some > > "Answerer Procedures" text for BUNDLE. > > > > For now, I would request that people mainly focus on the technical > > stuff, and if some text is unclear. I WILL align the usage of "m=" > > line and "media description" :) > > > > Also note that examples will be added later. > > > > Regards, > > > > Christer > > > > ----------------------------------------------------- > > > > 6.4. Answerer Procedures > > > > 6.4.1. General > > > > This section describes how an Answerer, when it receives an SDP > > Offer > > > > including a BUNDLE group, generates the associated SDP Answer. > > > > When an Answerer receives an SDP Offer which includes a BUNDLE > > group, > > > > and the Answerer accepts the offered BUNDLE group, the Answerer > > MUST > > > > generate an SDP Answer according to the procedures in Section 6.1 > > and > > > > this section. > > > > 6.4.2. RFC 5888 restrictions > > > > Based on the rules and procedures in RFC 5888, the following > > > > restrictions also apply to BUNDLE groups in SDP Answers: > > > > o 1) A BUNDLE group must not be added to an SDP Answer, unless > > the > > > > same BUNDLE group was included in the associated SDP Offer; and > > > > o 2) An SDP "m=" line must not be added to a BUNDLE group in the > > SDP > > > > Answer, unless it in the associated SDP Offer was included in > > the > > > > same BUNDLE group. > > > > 6.4.3. Offerer Bundle Address Selection > > > > In the SDP Answer, the Answerer selects the bundle address for the > > > > Offerer, based on the address information received in the > > associated > > > > SDP Offer, using the mid value. The mid value associated with the > > > > "m=" line in the SDP Offer that represents the bundle address MUST > > in > > > > the SDP Answer be located first in the mid value list added to SDP > > > > group:BUNDLE attribute associated with the BUNDLE group. > > > > From the associated SDP Offer, the Answerer SHOULD choose the > > bundle > > > > address associated with the mid value located first in the mid > > value > > > > list included in the SDP group:BUNDLE attribute associated with > > the > > > > BUNDLE group, unless: > > > > o 1) The mid value represents an "m=" line with a port zero value > > in > > > > the SDP Offer; or > > > > o 2) The mid value represents an "m=" line with a port zero value > > in > > > > the SDP Answer. > > > > OPEN: The decision for allowing a media description with port zero > > > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > 6.4.4. Answerer Bundle Address Selection > > > > In the SDP Answer, the Answerer selects its local bundle address. > > > > Each "m=" line included in a BUNDLE group MUST contain identical > > > > address information. The only exception is the usage of a zero > > port > > > > value for an "m=" line, which is allowed eventhough another port > > > > value number is used for other "m=" lines in the BUNDLE group. > > > > OPEN: The decision for allowing a media description with port zero > > > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > In a subsequent SDP Answer, the Answerer MAY change its local > > bundle > > > > address, as long as each "m=" line included the BUNDLE group > > contain > > > > identical address information. > > > > For a given BUNDLE group, the Answerer MUST NOT assign the bundle > > > > address to "m=" lines that are not included the BUNDLE group, or > > to > > > > "m=" lines that are included in another BUNDLE group. > > > > 6.4.5. Rejecting A BUNDLE Media Description > > > > When generating the SDP Answer, if the Answerer wants to reject > > media > > > > associated with an "m=" line in the BUNDLE group, it will add a > > zero > > > > port number value to the "m=" line, according to the procedures > > > > defined in RFC 3264. > > > > OPEN ISSUE: It is FFS whether it is allowed to include a port zero > > > > media descriptions in a BUNDLE group. > > > > 6.4.6. Removing a media description from a BUNDLE group > > > > When generating the SDP Answer, if the Answerer wants to remove an > > > > "m=" line from a BUNDLE group (without rejecting the "m=" line),it > > > > MUST NOT include the "m=" line in a BUNDLE group. In addition, > > the > > > > SDP Answer MUST not add its local bundle address to the "m=" line. > > > > An Answerer MUST NOT, in the SDP Answer, remove an "m=" line from > > a > > > > BUNDLE group, unless the "m=" line had unique address information > > in > > > > the associated SDP Offer. > > > > NOTE: The reason for the restriction above is that, if the "m=" > > line > > > > would be removed from the BUNDLE group, the address information > > would > > > > be identical to the "m=" lines remaining in the BUNDLE group. > > > > OPEN: The decision for allowing a media description with port zero > > > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > > > > > _______________________________________________ > > 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 > --001a11c34ed29591e404ddeb247f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Can we add that the answerer must also ensure that it can = de-mulitplex the media it will receive? That is, it must either agree to a = de-mulitplex scheme that was offered (either in the SDP, such as SSRC signa= lling, =A0or external signalling) or ensure that there is no PT overlap in = the bundle by not including certain PTs or by unbundling one or more m-line= s.


On 30 May 201= 3 07:27, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

> This seems good to me, pending polishing the language.
>
> I trust when you say "address information" you mean:
> - the port in the m-line
> - the address in the c-line
> - associated ICE information
>
> Obviously it would be cumbersome to mention all of that each time you = need to refer to address information. So I'm expecting you will coin a = term (e.g., "address information") and provide a definition of it= .

Yes. There is going to be a separate section which describes that mor= e in detail.

Thanks!

Regards,

Christer




On 5/29/13 7:39 AM, Christer Holmberg wrote:
> Hi,
>
> Based on the e-mail and interim discussions, I've tried together s= ome
> "Answerer Procedures" text for BUNDLE.
>
> For now, I would request that people mainly focus on the technical
> stuff, and if some text is unclear. I WILL align the usage of "m= =3D"
> line and "media description" :)
>
> Also note that examples will be added later.
>
> Regards,
>
> Christer
>
> -----------------------------------------------------
>
> 6.4. =A0Answerer Procedures
>
> 6.4.1. =A0General
>
> =A0 =A0 This section describes how an Answerer, when it receives an SD= P
> Offer
>
> =A0 =A0 including a BUNDLE group, generates the associated SDP Answer.=
>
> =A0 =A0 When an Answerer receives an SDP Offer which includes a BUNDLE=
> group,
>
> =A0 =A0 and the Answerer accepts the offered BUNDLE group, the Answere= r
> MUST
>
> =A0 =A0 generate an SDP Answer according to the procedures in Section = 6.1
> and
>
> =A0 =A0 this section.
>
> 6.4.2. =A0RFC 5888 restrictions
>
> =A0 =A0 Based on the rules and procedures in RFC 5888, the following >
> =A0 =A0 restrictions also apply to BUNDLE groups in SDP Answers:
>
> =A0 =A0 o =A01) A BUNDLE group must not be added to an SDP Answer, unl= ess
> the
>
> =A0 =A0 =A0 =A0same BUNDLE group was included in the associated SDP Of= fer; and
>
> =A0 =A0 o =A02) An SDP "m=3D" line must not be added to a BU= NDLE group in the
> SDP
>
> =A0 =A0 =A0 =A0Answer, unless it in the associated SDP Offer was inclu= ded in
> the
>
> =A0 =A0 =A0 =A0same BUNDLE group.
>
> 6.4.3. =A0Offerer Bundle Address Selection
>
> =A0 =A0 In the SDP Answer, the Answerer selects the bundle address for= the
>
> =A0 =A0 Offerer, based on the address information received in the
> associated
>
> =A0 =A0 SDP Offer, using the mid value. =A0The mid value associated wi= th the
>
> =A0 =A0 "m=3D" line in the SDP Offer that represents the bun= dle address MUST
> in
>
> =A0 =A0 the SDP Answer be located first in the mid value list added to= SDP
>
> =A0 =A0 group:BUNDLE attribute associated with the BUNDLE group.
>
> =A0 =A0 From the associated SDP Offer, the Answerer SHOULD choose the<= br> > bundle
>
> =A0 =A0 address associated with the mid value located first in the mid=
> value
>
> =A0 =A0 list included in the SDP group:BUNDLE attribute associated wit= h
> the
>
> =A0 =A0 BUNDLE group, unless:
>
> =A0 =A0 o =A01) The mid value represents an "m=3D" line with= a port zero value
> in
>
> =A0 =A0 =A0 =A0the SDP Offer; or
>
> =A0 =A0 o =A02) The mid value represents an "m=3D" line with= a port zero value
> in
>
> =A0 =A0 =A0 =A0the SDP Answer.
>
> =A0 =A0 OPEN: The decision for allowing a media description with port = zero
>
> =A0 =A0 values inside a BUNDLE group is pending on update for RFC 5888= .
>
> 6.4.4. =A0Answerer Bundle Address Selection
>
> =A0 =A0 In the SDP Answer, the Answerer selects its local bundle addre= ss.
>
> =A0 =A0 Each "m=3D" line included in a BUNDLE group MUST con= tain identical
>
> =A0 =A0 address information. =A0The only exception is the usage of a z= ero
> port
>
> =A0 =A0 value for an "m=3D" line, which is allowed eventhoug= h another port
>
> =A0 =A0 value number is used for other "m=3D" lines in the B= UNDLE group.
>
> =A0 =A0 OPEN: The decision for allowing a media description with port = zero
>
> =A0 =A0 values inside a BUNDLE group is pending on update for RFC 5888= .
>
> =A0 =A0 In a subsequent SDP Answer, the Answerer MAY change its local<= br> > bundle
>
> =A0 =A0 address, as long as each "m=3D" line included the BU= NDLE group
> contain
>
> =A0 =A0 identical address information.
>
> =A0 =A0 For a given BUNDLE group, the Answerer MUST NOT assign the bun= dle
>
> =A0 =A0 address to "m=3D" lines that are not included the BU= NDLE group, or
> to
>
> =A0 =A0 "m=3D" lines that are included in another BUNDLE gro= up.
>
> 6.4.5. =A0Rejecting A BUNDLE Media Description
>
> =A0 =A0 When generating the SDP Answer, if the Answerer wants to rejec= t
> media
>
> =A0 =A0 associated with an "m=3D" line in the BUNDLE group, = it will add a
> zero
>
> =A0 =A0 port number value to the "m=3D" line, according to t= he procedures
>
> =A0 =A0 defined in RFC 3264.
>
> =A0 =A0 OPEN ISSUE: It is FFS whether it is allowed to include a port = zero
>
> =A0 =A0 media descriptions in a BUNDLE group.
>
> 6.4.6. =A0Removing a media description from a BUNDLE group
>
> =A0 =A0 When generating the SDP Answer, if the Answerer wants to remov= e an
>
> =A0 =A0 "m=3D" line from a BUNDLE group (without rejecting t= he "m=3D" line),it
>
> =A0 =A0 MUST NOT include the "m=3D" line in a BUNDLE group. = =A0In addition,
> the
>
> =A0 =A0 SDP Answer MUST not add its local bundle address to the "= m=3D" line.
>
> =A0 =A0 An Answerer MUST NOT, in the SDP Answer, remove an "m=3D&= quot; line from
> a
>
> =A0 =A0 BUNDLE group, unless the "m=3D" line had unique addr= ess information
> in
>
> =A0 =A0 the associated SDP Offer.
>
> =A0 =A0 NOTE: The reason for the restriction above is that, if the &qu= ot;m=3D"
> line
>
> =A0 =A0 would be removed from the BUNDLE group, the address informatio= n
> would
>
> =A0 =A0 be identical to the "m=3D" lines remaining in the BU= NDLE group.
>
> =A0 =A0 OPEN: The decision for allowing a media description with port = zero
>
> =A0 =A0 values inside a BUNDLE group is pending on update for RFC 5888= .
>
>
>
> _______________________________________________
> 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

--001a11c34ed29591e404ddeb247f-- From prvs=6862f8098b=christer.holmberg@ericsson.com Thu May 30 01:28:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C00121F96CF for ; Thu, 30 May 2013 01:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv0UyV1qSwc5 for ; Thu, 30 May 2013 01:27:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D792B21F96FE for ; Thu, 30 May 2013 01:27:05 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-b9-51a70d521693 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 77.A2.18006.25D07A15; Thu, 30 May 2013 10:26:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Thu, 30 May 2013 10:26:58 +0200 From: Christer Holmberg To: Kevin Dempsey Thread-Topic: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) Thread-Index: Ac5cYL6Xjkqad1ozQWuoyGt6QctbSAABoqcAACXMJdD///4KgP//3LxQ Date: Thu, 30 May 2013 08:26:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37D20A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> <51A60F50.9020902@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C37CFE4@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.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+JvrW4w7/JAgwMdLBY3579lsZi6/DGL xYoNB1gdmD3+vv/A5LFz1l12jyVLfjIFMEdx2yQllpQFZ6bn6dslcGd0LdrJUvDWvGLrs062 Bsbd2l2MnBwSAiYSl7bcZYKwxSQu3FvP1sXIxSEkcJhRYmHPJyhnCaPEqgtzWLsYOTjYBCwk uv+BNYsI6EgcvD+ZHcRmFvCVeLngCzOILSzgKLH76hkmiBoniae/1rCDtIoIuEls+s8JEmYR UJXo+NXIAmLzArWuaJzEDLHqF6PEp3WbwBKcAoESq/qa2UBsRqDjvp9awwSxS1zi1pP5UEcL SCzZc54ZwhaVePn4H9iZEgKKEsv75SDK9SRuTJ3CBmFrSyxb+JoZYq+gxMmZT1gmMIrNQjJ1 FpKWWUhaZiFpWcDIsoqRPTcxMye93GgTIzBuDm75rbqD8c45kUOM0hwsSuK8eryLA4UE0hNL UrNTUwtSi+KLSnNSiw8xMnFwggguqQbGym9m3/WvHxcRDt5/uj9Hgevst28ZdzaYdbT1NTyd FjL35J3JGwq0b/zVy+H8yDEn+mTGGVe31ReURZVn1fNblDYJvNOdeHRFSmn+Sct/+ieLr3Hv eXllk/WW9V9FpG6/8/JeoK5t6RkpoPLqWoxgVOdtlZUJTUkcXOn6M/TnHHi2NthsJdtlJZbi jERDLeai4kQAHfondm4CAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:28:01 -0000 Hi Kevin, > Can we add that the answerer must also ensure that it can de-mulitplex th= e media it will receive? That is, it must either agree=20 > to a de-mulitplex scheme that was offered (either in the SDP, such as SSR= C signalling, =A0or external signalling) or ensure that=20 > there is no PT overlap in the bundle by not including certain PTs or by u= nbundling one or more m-lines. For sure we will have to add text also about that. The reason I didn't add = anything yet is because we don't have a clear outcome of that discussion ye= t :) Thanks! Regards, Christer On 30 May 2013 07:27, Christer Holmberg wr= ote: Hi, > This seems good to me, pending polishing the language. > > I trust when you say "address information" you mean: > - the port in the m-line > - the address in the c-line > - associated ICE information > > Obviously it would be cumbersome to mention all of that each time you nee= d to refer to address information. So I'm expecting you will coin a term (e= .g., "address information") and provide a definition of it. Yes. There is going to be a separate section which describes that more in d= etail. Thanks! Regards, Christer On 5/29/13 7:39 AM, Christer Holmberg wrote: > Hi, > > Based on the e-mail and interim discussions, I've tried together some > "Answerer Procedures" text for BUNDLE. > > For now, I would request that people mainly focus on the technical > stuff, and if some text is unclear. I WILL align the usage of "m=3D" > line and "media description" :) > > Also note that examples will be added later. > > Regards, > > Christer > > ----------------------------------------------------- > > 6.4. =A0Answerer Procedures > > 6.4.1. =A0General > > =A0 =A0 This section describes how an Answerer, when it receives an SDP > Offer > > =A0 =A0 including a BUNDLE group, generates the associated SDP Answer. > > =A0 =A0 When an Answerer receives an SDP Offer which includes a BUNDLE > group, > > =A0 =A0 and the Answerer accepts the offered BUNDLE group, the Answerer > MUST > > =A0 =A0 generate an SDP Answer according to the procedures in Section 6.1 > and > > =A0 =A0 this section. > > 6.4.2. =A0RFC 5888 restrictions > > =A0 =A0 Based on the rules and procedures in RFC 5888, the following > > =A0 =A0 restrictions also apply to BUNDLE groups in SDP Answers: > > =A0 =A0 o =A01) A BUNDLE group must not be added to an SDP Answer, unless > the > > =A0 =A0 =A0 =A0same BUNDLE group was included in the associated SDP Offer= ; and > > =A0 =A0 o =A02) An SDP "m=3D" line must not be added to a BUNDLE group in= the > SDP > > =A0 =A0 =A0 =A0Answer, unless it in the associated SDP Offer was included= in > the > > =A0 =A0 =A0 =A0same BUNDLE group. > > 6.4.3. =A0Offerer Bundle Address Selection > > =A0 =A0 In the SDP Answer, the Answerer selects the bundle address for th= e > > =A0 =A0 Offerer, based on the address information received in the > associated > > =A0 =A0 SDP Offer, using the mid value. =A0The mid value associated with = the > > =A0 =A0 "m=3D" line in the SDP Offer that represents the bundle address M= UST > in > > =A0 =A0 the SDP Answer be located first in the mid value list added to SD= P > > =A0 =A0 group:BUNDLE attribute associated with the BUNDLE group. > > =A0 =A0 From the associated SDP Offer, the Answerer SHOULD choose the > bundle > > =A0 =A0 address associated with the mid value located first in the mid > value > > =A0 =A0 list included in the SDP group:BUNDLE attribute associated with > the > > =A0 =A0 BUNDLE group, unless: > > =A0 =A0 o =A01) The mid value represents an "m=3D" line with a port zero = value > in > > =A0 =A0 =A0 =A0the SDP Offer; or > > =A0 =A0 o =A02) The mid value represents an "m=3D" line with a port zero = value > in > > =A0 =A0 =A0 =A0the SDP Answer. > > =A0 =A0 OPEN: The decision for allowing a media description with port zer= o > > =A0 =A0 values inside a BUNDLE group is pending on update for RFC 5888. > > 6.4.4. =A0Answerer Bundle Address Selection > > =A0 =A0 In the SDP Answer, the Answerer selects its local bundle address. > > =A0 =A0 Each "m=3D" line included in a BUNDLE group MUST contain identica= l > > =A0 =A0 address information. =A0The only exception is the usage of a zero > port > > =A0 =A0 value for an "m=3D" line, which is allowed eventhough another por= t > > =A0 =A0 value number is used for other "m=3D" lines in the BUNDLE group. > > =A0 =A0 OPEN: The decision for allowing a media description with port zer= o > > =A0 =A0 values inside a BUNDLE group is pending on update for RFC 5888. > > =A0 =A0 In a subsequent SDP Answer, the Answerer MAY change its local > bundle > > =A0 =A0 address, as long as each "m=3D" line included the BUNDLE group > contain > > =A0 =A0 identical address information. > > =A0 =A0 For a given BUNDLE group, the Answerer MUST NOT assign the bundle > > =A0 =A0 address to "m=3D" lines that are not included the BUNDLE group, o= r > to > > =A0 =A0 "m=3D" lines that are included in another BUNDLE group. > > 6.4.5. =A0Rejecting A BUNDLE Media Description > > =A0 =A0 When generating the SDP Answer, if the Answerer wants to reject > media > > =A0 =A0 associated with an "m=3D" line in the BUNDLE group, it will add a > zero > > =A0 =A0 port number value to the "m=3D" line, according to the procedures > > =A0 =A0 defined in RFC 3264. > > =A0 =A0 OPEN ISSUE: It is FFS whether it is allowed to include a port zer= o > > =A0 =A0 media descriptions in a BUNDLE group. > > 6.4.6. =A0Removing a media description from a BUNDLE group > > =A0 =A0 When generating the SDP Answer, if the Answerer wants to remove a= n > > =A0 =A0 "m=3D" line from a BUNDLE group (without rejecting the "m=3D" lin= e),it > > =A0 =A0 MUST NOT include the "m=3D" line in a BUNDLE group. =A0In additio= n, > the > > =A0 =A0 SDP Answer MUST not add its local bundle address to the "m=3D" li= ne. > > =A0 =A0 An Answerer MUST NOT, in the SDP Answer, remove an "m=3D" line fr= om > a > > =A0 =A0 BUNDLE group, unless the "m=3D" line had unique address informati= on > in > > =A0 =A0 the associated SDP Offer. > > =A0 =A0 NOTE: The reason for the restriction above is that, if the "m=3D" > line > > =A0 =A0 would be removed from the BUNDLE group, the address information > would > > =A0 =A0 be identical to the "m=3D" lines remaining in the BUNDLE group. > > =A0 =A0 OPEN: The decision for allowing a media description with port zer= o > > =A0 =A0 values inside a BUNDLE group is pending on update for RFC 5888. > > > > _______________________________________________ > 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 prvs=0862b76666=ivo.sedlacek@ericsson.com Thu May 30 07:11:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117A121F84D8 for ; Thu, 30 May 2013 07:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7o4J-E9XGSY for ; Thu, 30 May 2013 07:11:38 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0742421F871C for ; Thu, 30 May 2013 07:11:29 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-f9-51a75e10144e Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 26.5F.09795.01E57A15; Thu, 30 May 2013 16:11:29 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Thu, 30 May 2013 16:11:28 +0200 From: Ivo Sedlacek To: "Hannes.Tschofenig@gmx.net" , "obsidian97@gmail.com" , "gsalguei@cisco.com" Thread-Topic: Comments to draft-ietf-mmusic-media-path-middleboxes Thread-Index: Ac5dP2U9MUhBukL4S/y9NZuXA5zr2Q== Date: Thu, 30 May 2013 14:11:27 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010D72D7@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ 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_39B5E4D390E9BD4890E2B310790061010D72D7ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvra5g3PJAg9lLOSzmTvGzWLrzHqvF 1OWPWSyWzXnE7MDiMeX3RlaPnbPusnss3rSfzWPJkp9MASxR3DZJiSVlwZnpefp2CdwZx3fy FazvZ6poutnI0sC4+iNjFyMHh4SAicTzXTZdjJxAppjEhXvr2boYuTiEBA4zSiz5vYUdwlnM KPH36gV2kCo2AT2JiVuOsIIkRARmMkpsvbGZCWQSs4C6xNXFQSA1wgK2Ej0TO9hAbBEBJ4mv 1z4wQdh6EndausDmsAioSmzfNJcVxOYV8Jb4uGcDM4jNKCArcfVPLyOIzSwgLnHryXwmiOsE JJbsOc8MYYtKvHz8jxXCVpT4+GofVH2+xKmdTcwQMwUlTs58wjKBUXgWklGzkJTNQlIGEdeR WLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGy5yZm5qSXm29iBEbTwS2/DXYwbrovdohRmoNF SZxXn3dxoJBAemJJanZqakFqUXxRaU5q8SFGJg5OEMEl1cB4sutZzuxJEt8P5ZydrMj/eVJd uNjxC7O2uwVf+R8RLHRig0TGaTk3k4fFe3f+t73589fBl/+vbmRnEfRuMXt7Q0pE1kX+nM6r 6b9V/iZedFrd8SiyKGrBxUhLk4XZGTaenefXTjzbGtz6TDRtnoqfTrhzenTMFvEmyQ3dny58 8Prc2X0v/fk1JZbijERDLeai4kQA2lC7pHkCAAA= Cc: "mmusic@ietf.org" Subject: [MMUSIC] Comments to draft-ietf-mmusic-media-path-middleboxes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:11:43 -0000 --_000_39B5E4D390E9BD4890E2B310790061010D72D7ESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Comments to draft-ietf-mmusic-media-path-middleboxes-06: Comment 1: ISSUE: http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 stat= es: ------------------- 3. Architecture Figure 1 shows the architecture that is being considered in this document with respect to firewall and NAT traversal using media relaying. The timing and directionality with which media packets are allowed to traverse a particular edge device is the subject of this investigation. The MIDCOM agent thereby pushes policy rules to the middlebox that allow or deny certain flows to >>bypass<<. Additionally, in case of media relaying it is important for the MIDCOM agent to adjust the signaling messages. SIP +-----------------+ SIP +-----+ Signaling | SIP ALG | Signaling +-----+ | UAC |<----------->+-----------------+<----------->| UAS | +-----+ | MIDCOM Agent | +-----+ ^ +-----------------+ ^ | ^ | | Policy rule(s) | and NAT bindings | | v | | Media +-------------+ Media | +----------------->| Middlebox |<-----------------+ +-------------+ Figure 1: Analysed Firewalling Architecture The aspects of packet filtering are described in Section 4 whereas NAT traversal is illustrated in Section 5. ------------------- The word "bypass" does not seem to be correct. "bypass" is defined by http://dictionary.cambridge.org/ as: "to avoid somet= hing by going around it" or " to ignore a rule or official authority". However, the figure 1 shows media of the flows passing through/via the midd= lebox, not around the middlebox. PROPOSAL: ------------------- 3. Architecture Figure 1 shows the architecture that is being considered in this document with respect to firewall and NAT traversal using media relaying. The timing and directionality with which media packets are allowed to traverse a particular edge device is the subject of this investigation. The MIDCOM agent thereby pushes policy rules to the middlebox that allow or deny certain flows to >>pass through<<. Additio= nally, in case of media relaying it is important for the MIDCOM agent to adjust the signaling messages. SIP +-----------------+ SIP +-----+ Signaling | SIP ALG | Signaling +-----+ | UAC |<----------->+-----------------+<----------->| UAS | +-----+ | MIDCOM Agent | +-----+ ^ +-----------------+ ^ | ^ | | Policy rule(s) | and NAT bindings | | v | | Media +-------------+ Media | +----------------->| Middlebox |<-----------------+ +-------------+ Figure 1: Analysed Firewalling Architecture The aspects of packet filtering are described in Section 4 whereas NAT traversal is illustrated in Section 5. ------------------- Comment 2: ISSUE: http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 stat= es: ------------------- REC #4: If signaling on the media path is required before media can flow, the >>answer<< should send the SDP answer as soon as possible, for example within a provisional SIP response, to allow the media path signaling to bypass middleboxes and therefore to avoid clipping. ------------------- I believe there is an error. PROPOSAL: ------------------- REC #4: If signaling on the media path is required before media can flow, the >>answerer<< should send the SDP answer as soon as possible= , for example within a provisional SIP response, to allow the media path signaling to bypass middleboxes and therefore to avoid clipping. ------------------- Comment 3: ISSUE: http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 stat= es: ------------------- REC #4: If signaling on the media path is required before media can flow, the answer should send the SDP answer as soon as possible, for example within a provisional SIP response, to allow the media path signaling to >>bypass<< middleboxes and therefore to avoid clipping. ------------------- Same issue as in Comment 1. PROPOSAL: ------------------- REC #4: If signaling on the media path is required before media can flow, the answer should send the SDP answer as soon as possible, for example within a provisional SIP response, to allow the media path signaling to >>pass through<< middleboxes and therefore to avoid clipping. ------------------- Kind regards Ivo Sedlacek Ericsson Mobile +420 608 234 709 ivo.sedlacek@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer --_000_39B5E4D390E9BD4890E2B310790061010D72D7ESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Comments to draft-ietf-mmusic= -media-path-middleboxes-06:

 

Comment 1:

 

ISSUE:

 <= /o:p>

http= ://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states:

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

3.  Architecture
 
   Figure 1 shows the architect=
ure that is being considered in this
   document with respect to fir=
ewall and NAT traversal using media
   relaying.  The timing a=
nd directionality with which media packets are
   allowed to traverse a partic=
ular edge device is the subject of this
   investigation.  The MID=
COM agent thereby pushes policy rules to the
   middlebox that allow or deny=
 certain flows to >>bypass<<.  Additionally,=

   in case of media relaying it=
 is important for the MIDCOM agent to
   adjust the signaling message=
s.
 
 
       =
;            &n=
bsp; SIP     +-----------------+  &nb=
sp;  SIP
       =
;  +-----+  Signaling  | &nbs=
p;   SIP ALG     |  Signaling  +=
;-----+
    =
;     | UAC |<----------->+-----------------&=
#43;<----------->| UAS |
    =
;     +-----+    &nb=
sp;        |   MIDCOM Agent&nb=
sp; |           &nbs=
p; +-----+
       =
;     ^        =
        +-----------------+ =
;             &=
nbsp; ^
       =
;     |        =
            &nb=
sp;    ^        &nbs=
p;            &=
nbsp;   |
       =
;     |        =
  Policy rule(s) | and NAT bindings      =
;  |
       =
;     |        =
            &nb=
sp;    v        &nbs=
p;            &=
nbsp;   |
       =
;     |      Media  =
     +-------------+     &n=
bsp; Media      |
       =
;     +----------------->|  Middlebox =
 |<-----------------+
       =
;            &n=
bsp;           +-----=
--------+
 
       =
;         Figure 1: Analysed Firewa=
lling Architecture
 
   The aspects of packet filter=
ing are described in Section 4 whereas
   NAT traversal is illustrated=
 in Section 5.

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

 <= /o:p>

The word &qu= ot;bypass" does not seem to be correct.

 <= /o:p>

"bypass= " is defined by http://dictionary.cambridge.or= g/ as: "to avoid something by going around it" or " to i= gnore a rule or official authority".

 

However, t= he figure 1 shows media of the flows passing through/via the middlebox, not= around the middlebox.

 <= /o:p>

 <= /o:p>

PROPOSAL:

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

3.  Architecture
 
   Figure 1 shows the architect=
ure that is being considered in this
   document with respect to fir=
ewall and NAT traversal using media
   relaying.  The timing a=
nd directionality with which media packets are
   allowed to traverse a partic=
ular edge device is the subject of this
   investigation.  The MID=
COM agent thereby pushes policy rules to the
   middlebox that allow or deny=
 certain flows to >>pass through<<.  Additio=
nally,
   in case of media relaying it=
 is important for the MIDCOM agent to
   adjust the signaling message=
s.
 
 
       =
;            &n=
bsp; SIP     +-----------------+  &nb=
sp;  SIP
       =
;  +-----+  Signaling  | &nbs=
p;   SIP ALG     |  Signaling  +=
;-----+
    =
;     | UAC |<----------->+-----------------&=
#43;<----------->| UAS |
    =
;     +-----+    &nb=
sp;        |   MIDCOM Agent&nb=
sp; |           &nbs=
p; +-----+
       =
;     ^        =
        +-----------------+ =
;            &n=
bsp;  ^
       =
;     |        =
            &nb=
sp;    ^        &nbs=
p;            &=
nbsp;   |
       =
;     |        =
  Policy rule(s) | and NAT bindings      =
;  |
       =
;     |        =
            &nb=
sp;    v        &nbs=
p;            &=
nbsp;   |
       =
;     |      Media  =
     +-------------+    &nb=
sp;  Media      |
       =
;     +----------------->|  Middlebox =
 |<-----------------+
       =
;             &=
nbsp;          +-----=
--------+
 
       =
;         Figure 1: Analysed Firewa=
lling Architecture
 
   The aspects of packet filter=
ing are described in Section 4 whereas
   NAT traversal is illustrated=
 in Section 5.

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

 

Comment 2:

 

ISSUE:

 <= /o:p>

http= ://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states:

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

   REC #4:  If= signaling on the media path is required before media can=

     = ; flow, the >>answer<< should send the SDP answer as soon as = possible,

     = ; for example within a provisional SIP response, to allow the media

     = ; path signaling to bypass middleboxes and therefore to avoid

     = ; clipping.

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

I believe th= ere is an error.

 <= /o:p>

PROPOSAL:

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

   REC #4:  If= signaling on the media path is required before media can=

     = ; flow, the >>answerer<< should send the SDP answer as soon a= s possible,

     = ; for example within a provisional SIP response, to allow the media

     = ; path signaling to bypass middleboxes and therefore to avoid

     = ; clipping.

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

 

Comment 3:

 

ISSUE:

 <= /o:p>

http= ://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states:

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

   REC #4:  If= signaling on the media path is required before media can=

     = ; flow, the answer should send the SDP answer as soon as possible,

     = ; for example within a provisional SIP response, to allow the media

     = ; path signaling to >>bypass<< middleboxes and therefore to avoid

     = ; clipping.

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

Same issue a= s in Comment 1.

 <= /o:p>

PROPOSAL:

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

   REC #4:  If= signaling on the media path is required before media can=

     = ; flow, the answer should send the SDP answer as soon as possible,

     = ; for example within a provisional SIP response, to allow the media

     = ; path signaling to >>pass through<< middleboxes and therefore to avo= id

     = ; clipping.

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

 

 

Kind regards

 

Ivo Sedlacek<= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif";color:#333333">


Ericsson
Mobile +420 608 234 709
ivo.sedlacek@ericsson.com<= br> www.ericsson.com

 

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

--_000_39B5E4D390E9BD4890E2B310790061010D72D7ESESSMB301ericsso_-- From fluffy@cisco.com Thu May 30 07:23:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E5521F9021 for ; Thu, 30 May 2013 07:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.374 X-Spam-Level: X-Spam-Status: No, score=-110.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd07X9J4Ss7M for ; Thu, 30 May 2013 07:23:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0AE21F8FF3 for ; Thu, 30 May 2013 07:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4623; q=dns/txt; s=iport; t=1369923823; x=1371133423; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eh/shvpwzS9SNH/oqUIniuqxLqhNlH2/xdQzm/L6Ms0=; b=fqK+vfzlC7nX8qRd337ePnfe9WEhdHJE6rYAJY8mvtaVl4LzZT4vLL0i w0Si2z24TOOX7Ux40thfhM//qZgXAol0Trx6xMSxMua0za3b1AFi2guCl ZxJDvG+VjmQIi+B2M6yDiUq2nrCD/u1qgxLCRavHa4ipY0t5PvBR99Zl9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFALRfp1GtJV2d/2dsb2JhbABZgwkwQ8FMfRZ0giMBAQEDAQEBAWsEBwULAgEIDgoKJCcLJQIEDgUIAQsHh2wGBwW7FY5pAjEHgnZhA4hoiwWEepAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208";a="216827486" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 30 May 2013 14:23:42 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4UENg9x021625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 14:23:42 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 30 May 2013 09:23:42 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt Thread-Index: AQHOXUFIqHdsjYWnEU6ksh9SwuofgA== Date: Thu, 30 May 2013 14:22:45 +0000 Message-ID: References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> <518E169E.4050006@jitsi.org> In-Reply-To: <518E169E.4050006@jitsi.org> 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="iso-8859-1" Content-ID: <5C505430DB070D448C2F5BC7D202B027@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:23:48 -0000 I think you need to start by putting in a reference to=20 http://tools.ietf.org/html/rfc3424 and discussing the issues it raises with relation to this draft.=20 Next I think you need to add a specific attack where two people are both be= hind the same CGN. CGN is becoming increasingly common and will result in a= large number of people having the same IP address. Unless you have a solut= ions that secures this type of environment, I think you should put harmful = in the title and make the abstract very clear that the IETF does not recomm= end this and this document explains why.=20 On May 11, 2013, at 3:59 AM, Emil Ivov wrote: > Hey Cullen, >=20 > On 10.05.13, 23:53, Cullen Jennings (fluffy) wrote: >>=20 >> I think the security section series underestimates the security >> vulnerabilities this introduces. >=20 > If you think we've missed any specific attacks we'd be happy to add them. >=20 >> I'm very sad to see the IETF >> publishing this at all with anything other than "This is not the >> recommended way to solve this problem" and why. >=20 > Well that's pretty much what we say: >=20 > In no way does this document try to make a case for HNT or > present it as a solution that is somehow better than > alternatives such as ICE. The mechanisms described here, popular > as they may be, are not necessarily considered best practice or > recommended operation. >=20 > The security considerations section also specifically outlines cases > where DoS attacks can be performed even with the use of SRTP: >=20 > For example, in cases where end-to-end encryption is used it > would still be possible for an attacker to hijack a session > despite the use of SRTP and perform a denial of service attack. >=20 > The point was to show that in spite of all the threat mitigating > techniques users of latching are still left vulnerable to those. >=20 > I certainly don't understand IETF processes as well as you do, but it is > my understanding that as an informational document the draft can only do > so much and that making explicit recommendations for or against > technologies was for Standards Track documents only. Am I wrong about thi= s? >=20 > My recollection of the Paris and Vancouver meetings (and a quick skim > through the notes) is that this was also the direction chosen by the WG. >=20 > Again, if you believe that additional text would make things clearer we > are wide open to suggestions. >=20 > Cheers, > Emil >=20 >=20 >>=20 >>=20 >>=20 >>=20 >> On May 7, 2013, at 12:29 PM, internet-drafts@ietf.org wrote: >>=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 : Latching: Hosted NAT Traversal (HNT) for Media in >>> Real-Time Communication Author(s) : Emil Ivov Hadriel Kaplan=20 >>> Dan Wing Filename : draft-ietf-mmusic-latching-01.txt Pages >>> : 14 Date : 2013-05-07 >>>=20 >>> Abstract: This document describes behavior of signalling >>> intermediaries in Real-Time Communication (RTC) deployments, >>> sometimes referred to as Session Border Controllers (SBCs), when >>> performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, >>> such as media relaying and latching, that such intermediaries use >>> to enable other RTC devices behind NATs to communicate with each >>> other. This document is non-normative, and is only written to >>> explain HNT in order to provide a reference to the IETF community, >>> as well as an informative description to manufacturers, and users. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is:=20 >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching >>>=20 >>> There's also a htmlized version available at:=20 >>> http://tools.ietf.org/html/draft-ietf-mmusic-latching-01 >>>=20 >>> A diff from the previous version is available at:=20 >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-latching-01 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at:=20 >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ mmusic mailing >>> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >>=20 >> _______________________________________________ mmusic mailing list=20 >> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > --=20 > https://jitsi.org From fluffy@cisco.com Thu May 30 10:38:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCBA21F9354 for ; Thu, 30 May 2013 10:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.179 X-Spam-Level: X-Spam-Status: No, score=-110.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwF9GykwCvwl for ; Thu, 30 May 2013 10:38:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7376421F941D for ; Thu, 30 May 2013 10:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5255; q=dns/txt; s=iport; t=1369935526; x=1371145126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=G4Dzb7n2JCs+MOYKDboAfIQx3ZI6VcxX8opoxfxMfME=; b=QxBAVHWOaMNrxNYLsUbbAOadYVzDAtdggKdyBdNlTtCsxXuQOpOCCeDB K8pe8jtnTp4XlCIjDsC+eNAEwpHK4g3EuZvhpS0ztAJ4A5f7X8FrcP+H3 fZW5R+L5kK1jQ0mWKcgo/b56PwfYZJAOPGG9amGF4W5jdcM+s8cGZ6J57 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAKSNp1GtJXG//2dsb2JhbABZgwkwwhZ+FnSCIwEBAQMBAQEBawsFCwIBCCIkJwslAgQOBQiHfwYMu2gEjWp/AjEHgnZhA4wykhyKMIMPgXE2 X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="213874795" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 30 May 2013 17:38:45 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4UHcjxS021276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 17:38:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 30 May 2013 12:38:45 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) Thread-Index: AQHOXVyIByzNcym6vEWUaYu7/MrJxA== Date: Thu, 30 May 2013 17:37:48 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> 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: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:38:55 -0000 Looks good to me On May 29, 2013, at 5:39 AM, Christer Holmberg wrote: > Hi, > =20 > Based on the e-mail and interim discussions, I=92ve tried together some = =94Answerer Procedures=94 text for BUNDLE. > =20 > For now, I would request that people mainly focus on the technical stuff,= and if some text is unclear. I WILL align the usage of =93m=3D=94 line and= =93media description=94 :) > =20 > Also note that examples will be added later. > =20 > Regards, > =20 > Christer > =20 > ----------------------------------------------------- > =20 > =20 > 6.4. Answerer Procedures > =20 > 6.4.1. General > =20 > This section describes how an Answerer, when it receives an SDP Offer > including a BUNDLE group, generates the associated SDP Answer. > =20 > When an Answerer receives an SDP Offer which includes a BUNDLE group, > and the Answerer accepts the offered BUNDLE group, the Answerer MUST > generate an SDP Answer according to the procedures in Section 6.1 and > this section. > =20 > 6.4.2. RFC 5888 restrictions > =20 > Based on the rules and procedures in RFC 5888, the following > restrictions also apply to BUNDLE groups in SDP Answers: > =20 > o 1) A BUNDLE group must not be added to an SDP Answer, unless the > same BUNDLE group was included in the associated SDP Offer; and > =20 > o 2) An SDP "m=3D" line must not be added to a BUNDLE group in the SD= P > Answer, unless it in the associated SDP Offer was included in the > same BUNDLE group. > =20 > 6.4.3. Offerer Bundle Address Selection > =20 > In the SDP Answer, the Answerer selects the bundle address for the > Offerer, based on the address information received in the associated > SDP Offer, using the mid value. The mid value associated with the > "m=3D" line in the SDP Offer that represents the bundle address MUST i= n > the SDP Answer be located first in the mid value list added to SDP > group:BUNDLE attribute associated with the BUNDLE group. > =20 > From the associated SDP Offer, the Answerer SHOULD choose the bundle > address associated with the mid value located first in the mid value > list included in the SDP group:BUNDLE attribute associated with the > BUNDLE group, unless: > =20 > o 1) The mid value represents an "m=3D" line with a port zero value i= n > the SDP Offer; or > =20 > o 2) The mid value represents an "m=3D" line with a port zero value i= n > the SDP Answer. > =20 > OPEN: The decision for allowing a media description with port zero > values inside a BUNDLE group is pending on update for RFC 5888. > =20 > 6.4.4. Answerer Bundle Address Selection > =20 > In the SDP Answer, the Answerer selects its local bundle address. > Each "m=3D" line included in a BUNDLE group MUST contain identical > address information. The only exception is the usage of a zero port > value for an "m=3D" line, which is allowed eventhough another port > value number is used for other "m=3D" lines in the BUNDLE group. > =20 > OPEN: The decision for allowing a media description with port zero > values inside a BUNDLE group is pending on update for RFC 5888. > =20 > In a subsequent SDP Answer, the Answerer MAY change its local bundle > address, as long as each "m=3D" line included the BUNDLE group contain > identical address information. > =20 > For a given BUNDLE group, the Answerer MUST NOT assign the bundle > address to "m=3D" lines that are not included the BUNDLE group, or to > "m=3D" lines that are included in another BUNDLE group. > =20 > 6.4.5. Rejecting A BUNDLE Media Description > =20 > When generating the SDP Answer, if the Answerer wants to reject media > associated with an "m=3D" line in the BUNDLE group, it will add a zero > port number value to the "m=3D" line, according to the procedures > defined in RFC 3264. > =20 > OPEN ISSUE: It is FFS whether it is allowed to include a port zero > media descriptions in a BUNDLE group. > =20 > 6.4.6. Removing a media description from a BUNDLE group > =20 > When generating the SDP Answer, if the Answerer wants to remove an > "m=3D" line from a BUNDLE group (without rejecting the "m=3D" line),it > MUST NOT include the "m=3D" line in a BUNDLE group. In addition, the > SDP Answer MUST not add its local bundle address to the "m=3D" line. > =20 > An Answerer MUST NOT, in the SDP Answer, remove an "m=3D" line from a > BUNDLE group, unless the "m=3D" line had unique address information in > the associated SDP Offer. > =20 > NOTE: The reason for the restriction above is that, if the "m=3D" line > would be removed from the BUNDLE group, the address information would > be identical to the "m=3D" lines remaining in the BUNDLE group. > =20 > OPEN: The decision for allowing a media description with port zero > values inside a BUNDLE group is pending on update for RFC 5888. > =20 > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Thu May 30 10:48:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A9B21F9413 for ; Thu, 30 May 2013 10:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T432d5Q9eMSi for ; Thu, 30 May 2013 10:48:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 88B5821F8EDF for ; Thu, 30 May 2013 10:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=525; q=dns/txt; s=iport; t=1369936119; x=1371145719; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HqO0UJhsd3lI/mFXJrlX8+xbtjGspsSwa85G9EhFb10=; b=XXWCqNzmnrxSDSkGVMprFXMNjtmGe1i46LwXaUWFVT/OFdTcpxETIsFY lCTqd9zxDxnDlhUI9abMMuJ9JZ+D7pQeFEGDCuoPREBcnOpJ5sdjQosmR WPSLE7xYJ7y17pFYCbNDyv9PmYOlKNhHhoVTp7RjhV5cwtceTFD8jUt/D A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAMCQp1GtJV2Y/2dsb2JhbABZgwmDJL8ifhZ0giMBAQEDAXkFCwIBCCIkMiUCBA4FCId/BrtwjmkCMQeCdmEDqH6DD4In X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="216862465" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 30 May 2013 17:48:15 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4UHmEuJ029101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 17:48:14 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 30 May 2013 12:48:14 -0500 From: "Cullen Jennings (fluffy)" To: Harald Alvestrand Thread-Topic: [MMUSIC] The pick-a-config debate - perhaps an useful example Thread-Index: AQHOXV3b1FfHUcuVe0GLq36o2akfew== Date: Thu, 30 May 2013 17:47:17 +0000 Message-ID: References: <51A3C6C9.6050606@alvestrand.no> In-Reply-To: <51A3C6C9.6050606@alvestrand.no> 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: <021F7442145F5845867922F80EFD027F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] The pick-a-config debate - perhaps an useful example X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:48:47 -0000 On May 27, 2013, at 2:49 PM, Harald Alvestrand wrote= : > a=3Dgroup:BUNDLE foo bar >=20 > m=3Dvideo > a=3Dmid:foo > a=3Dimageattr:* [x=3D160,y=3D100] > a=3Drtpmap:96:vp8 >=20 > m=3Dvideo > a=3Dmid:bar > a=3Dimageattr:* [x=3D640,y=3D480] > a=3Drtpmap:96:vp8 >=20 > Now, the video is the same. Small nit =85 as far as I am concerned, if the above is a 3264 based offer,= the video could be from two different cameras. You need some other signali= ng to indicate it is simulcast. From internet-drafts@ietf.org Thu May 30 11:01:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888EC21F9672; Thu, 30 May 2013 11:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmmsyGgmor4J; Thu, 30 May 2013 11:01:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D72D21F86E9; Thu, 30 May 2013 11:01:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130530180110.6524.47602.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 11:01:10 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 18:01:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Analysis of Middlebox Interactions for Signaling Protoco= l Communication along the Media Path Author(s) : Brian Stucker Hannes Tschofenig Gonzalo Salgueiro Filename : draft-ietf-mmusic-media-path-middleboxes-07.txt Pages : 20 Date : 2013-05-30 Abstract: Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-path-middleboxes= -07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gsalguei@cisco.com Thu May 30 11:03:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E3321F9410 for ; Thu, 30 May 2013 11:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXAI8TzAvaiO for ; Thu, 30 May 2013 11:03:00 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 535B821F93EB for ; Thu, 30 May 2013 11:03:00 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4UI2wlV026099 for ; Thu, 30 May 2013 14:02:59 -0400 (EDT) Received: from rtp-gsalguei-8912.cisco.com (rtp-gsalguei-8912.cisco.com [10.116.132.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4UI2wbG022518; Thu, 30 May 2013 14:02:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Gonzalo Salgueiro In-Reply-To: <39B5E4D390E9BD4890E2B310790061010D72D7@ESESSMB301.ericsson.se> Date: Thu, 30 May 2013 14:02:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <673F23F8-5627-4F4A-A5ED-3A7987A634D0@cisco.com> References: <39B5E4D390E9BD4890E2B310790061010D72D7@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Mailer: Apple Mail (2.1503) Cc: obsidian97@gmail.com, mmusic@ietf.org Subject: Re: [MMUSIC] Comments to draft-ietf-mmusic-media-path-middleboxes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 18:03:04 -0000 Thanks, Ivo. I have posted a new version addressing your and Bruno's = comments. Thanks, Gonzalo On May 30, 2013, at 10:11 AM, Ivo Sedlacek = wrote: > Hello, > =20 > Comments to draft-ietf-mmusic-media-path-middleboxes-06: > =20 > Comment 1: > =20 > ISSUE: > =20 > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 = states: > ------------------- > 3. Architecture > =20 > Figure 1 shows the architecture that is being considered in this > document with respect to firewall and NAT traversal using media > relaying. The timing and directionality with which media packets = are > allowed to traverse a particular edge device is the subject of this > investigation. The MIDCOM agent thereby pushes policy rules to the > middlebox that allow or deny certain flows to >>bypass<<. = Additionally, > in case of media relaying it is important for the MIDCOM agent to > adjust the signaling messages. > =20 > =20 > SIP +-----------------+ SIP > +-----+ Signaling | SIP ALG | Signaling +-----+ > | UAC |<----------->+-----------------+<----------->| UAS | > +-----+ | MIDCOM Agent | +-----+ > ^ +-----------------+ ^ > | ^ | > | Policy rule(s) | and NAT bindings | > | v | > | Media +-------------+ Media | > +----------------->| Middlebox |<-----------------+ > +-------------+ > =20 > Figure 1: Analysed Firewalling Architecture > =20 > The aspects of packet filtering are described in Section 4 whereas > NAT traversal is illustrated in Section 5. > ------------------- > =20 > The word "bypass" does not seem to be correct. > =20 > "bypass" is defined by http://dictionary.cambridge.org/ as: "to avoid = something by going around it" or " to ignore a rule or official = authority". > =20 > However, the figure 1 shows media of the flows passing through/via the = middlebox, not around the middlebox. > =20 > =20 > PROPOSAL: > ------------------- > 3. Architecture > =20 > Figure 1 shows the architecture that is being considered in this > document with respect to firewall and NAT traversal using media > relaying. The timing and directionality with which media packets = are > allowed to traverse a particular edge device is the subject of this > investigation. The MIDCOM agent thereby pushes policy rules to the > middlebox that allow or deny certain flows to >>pass through<<. = Additionally, > in case of media relaying it is important for the MIDCOM agent to > adjust the signaling messages. > =20 > =20 > SIP +-----------------+ SIP > +-----+ Signaling | SIP ALG | Signaling +-----+ > | UAC |<----------->+-----------------+<----------->| UAS | > +-----+ | MIDCOM Agent | +-----+ > ^ +-----------------+ ^ > | ^ | > | Policy rule(s) | and NAT bindings | > | v | > | Media +-------------+ Media | > +----------------->| Middlebox |<-----------------+ > +-------------+ > =20 > Figure 1: Analysed Firewalling Architecture > =20 > The aspects of packet filtering are described in Section 4 whereas > NAT traversal is illustrated in Section 5. > ------------------- > =20 > Comment 2: > =20 > ISSUE: > =20 > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 = states: > ------------------- > REC #4: If signaling on the media path is required before media = can > flow, the >>answer<< should send the SDP answer as soon as = possible, > for example within a provisional SIP response, to allow the = media > path signaling to bypass middleboxes and therefore to avoid > clipping. > ------------------- > I believe there is an error. > =20 > PROPOSAL: > ------------------- > REC #4: If signaling on the media path is required before media = can > flow, the >>answerer<< should send the SDP answer as soon as = possible, > for example within a provisional SIP response, to allow the = media > path signaling to bypass middleboxes and therefore to avoid > clipping. > ------------------- > =20 > Comment 3: > =20 > ISSUE: > =20 > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 = states: > ------------------- > REC #4: If signaling on the media path is required before media = can > flow, the answer should send the SDP answer as soon as possible, > for example within a provisional SIP response, to allow the = media > path signaling to >>bypass<< middleboxes and therefore to avoid > clipping. > ------------------- > Same issue as in Comment 1. > =20 > PROPOSAL: > ------------------- > REC #4: If signaling on the media path is required before media = can > flow, the answer should send the SDP answer as soon as possible, > for example within a provisional SIP response, to allow the = media > path signaling to >>pass through<< middleboxes and therefore to = avoid > clipping. > ------------------- > =20 > =20 > Kind regards > =20 > Ivo Sedlacek >=20 > Ericsson > Mobile +420 608 234 709 > ivo.sedlacek@ericsson.com > www.ericsson.com > =20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer From iesg-secretary@ietf.org Thu May 30 11:56:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4F121F92BB; Thu, 30 May 2013 11:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65D70ju7lOsI; Thu, 30 May 2013 11:56:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA6921F922A; Thu, 30 May 2013 11:56:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 11:56:19 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 18:56:21 -0000 Greetings, This is to announce a(nother) virtual interim meeting for the MMUSIC = Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the = so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=3D" lines or = very few "m=3D" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately on the = MMUSIC mailing list. For now, people should take a close look at the = following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari & Flemming (MMUSIC co-chairs) PS: Per our previous interim meeting announcement, we tried to schedule = a longer and in-person physical interim meeting, however it has proven = impossible to find a set of dates where we could get critical mass for = such a meeting. Scheduling even a virtual interim before the Berlin IETF = has been surprisingly difficult with the above date being the only = viable option at this point. From fandreas@cisco.com Thu May 30 12:04:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FFB21F9408 for ; Thu, 30 May 2013 12:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4BMCw8eZZ55 for ; Thu, 30 May 2013 12:04:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8803E21F900C for ; Thu, 30 May 2013 12:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1135; q=dns/txt; s=iport; t=1369940666; x=1371150266; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JcJFA7vWI/oBFp/WYHv8owNOqgGGJTX0r9l6Y3VcQpQ=; b=dqrl42/zmFbb6n6iIa9GugTe6ZLtnZCa2UFpsvVIhpxBI/7a6OZIT5zh NpVRDt1oA+U8r/uN6ncEqPe8ATN91bbRefgwwWKU7SRYgBaZZWN2Fpm48 gkWC/m2uodlJxHG0wtBrbIuDxzgyLN/Qhnr2K5t5X2e4Pc4wQ6JNDkahK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACGip1GtJV2c/2dsb2JhbABZgwkwwhd+FnSCIwEBAQQBAQE1NgoBEAsYCRYPCQMCAQIBDwYwBg0BBQIBAYd3Aw8MskANiQCMRIJYB4NXA5VYgWaBKYp0hSODKyA X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="216856631" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 30 May 2013 19:04:26 +0000 Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4UJ4PMZ032677; Thu, 30 May 2013 19:04:25 GMT Message-ID: <51A7A2B9.5020909@cisco.com> Date: Thu, 30 May 2013 15:04:25 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mary Barnes References: <51A6700B.40108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:04:33 -0000 I'm not trying to be facetious, but it is genuinely hard to say when the draft hasn't been announced or discussed in MMUSIC (and this is not the only draft that suffers from that). It seems the bulk of the work and discussions happen in RTCWeb but with an expectation that decisions are to be made in MMUSIC. Maybe this is part of the reason for the lack of progress on this one and we should reconsider the approach ? Thanks -- Flemming On 5/29/13 6:35 PM, Mary Barnes wrote: > I would certainly hope that this draft would also be on the agenda. > > Mary. > > On Wed, May 29, 2013 at 5:19 PM, Martin Thomson > wrote: >> On 29 May 2013 14:15, Flemming Andreasen wrote: >>> You may also want to look at >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> ? >> _______________________________________________ >> 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 fluffy@cisco.com Thu May 30 12:07:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590B521F8FDD for ; Thu, 30 May 2013 12:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.428 X-Spam-Level: X-Spam-Status: No, score=-110.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV7hDNwkCdXt for ; Thu, 30 May 2013 12:07:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC6C21F8E6E for ; Thu, 30 May 2013 12:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8316; q=dns/txt; s=iport; t=1369940861; x=1371150461; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZjKYqg0iO4EshOt8j5k8hKgx3dk8duuP/MdAmC84UrM=; b=iUrIl4ReMgBAIkCazyqA1wBEmoAW4YgQ51jnX8JFBnv4IN1uhmmT2gOX a1UEes9HTLqk2fm+HceLGhqzKCFmsu3npf2U0qPMXSksZaveYHZPyE0Kr fWXXi+nfU5MrZIcn7wJ9jsySJsrh517ba054E+2j0flAHg/N7MPcPTcIy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMuip1GtJV2c/2dsb2JhbABZgwkwwhd+FnSCIwEBAQMBAQEBJBMuBgsFCwIBCA4KChQQJwslAgQOBQiHfwYMu0mNWYEQAjEHgnZhA5NthHqQF4MPgic X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="213914578" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 30 May 2013 19:07:41 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4UJ7e7J003252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 19:07:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 30 May 2013 14:07:40 -0500 From: "Cullen Jennings (fluffy)" To: Colin Perkins Thread-Topic: [MMUSIC] Proposal for what bundle should say about demux Thread-Index: AQHOXWj0qIVhF30UxESpVVVeVdmv6g== Date: Thu, 30 May 2013 19:06:43 +0000 Message-ID: References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> In-Reply-To: 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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:07:46 -0000 Colin,=20 I've been deliberately merging layers A, B, C all into one in my discussion= of this and focusing on the media stack code which has to deal with all th= ose layers. The reasons I have been doing that is people just seemed to con= fused about what all the parts of RTP are such as RTP sessions. But most pe= ople seemed to understand what bits in the various packets they could look = at what and what data had to end up at the right spot in the end.=20 At a high level, I would draw the layers a little differently than you in t= hat many of the implementation I work with do the jitter buffer after the d= ata is decoded. This allows the implementations to do better packet loss co= ncealment and play rate games where they speed up or slow down playback ver= y slightly to smoothly adapt the jitter buffer depth.=20 But regardless of the details of the order, the jitter buffer needs to look= at the SSRC and if the SSRC has changed, it probably needs to retrain the = jitter buffer.=20 Lets talk a bit more about your diagram and what happens when Alice creates= and Offer with that does not have use bundle and has two audio codecs. Whe= n an RTP packets #1 gets sent to Alice and it arrives before the answer, so= mewhere in layer B/C, something needs to look at the PT value to decide wha= t codec this goes to. Alice knows nothing about what SSRC the other side is= using. Now lets say that packet #2 arrives (again before answer) and packe= t #2 is on the same port, same PT, but has a different SSRC. None of the im= plementations I work with for audio would allocate a new PB or CR. Instead = they would pass packet #2 throughout the same codec instance that packet #1= had used and expect things like the jitter buffer to note the SSRC change = and act accordingly. For DSP based audio systems where the actual codec ins= tances are loaded into the DSP and have a reserved set or resources allocat= ed for them, this is a very common design.=20 There is probably more variety in video applications but many conferences b= ridges act this way.=20 So I have no problem if things split on SSRC and whatever processing that c= an be done knowing only that is done. That probably includes RTCP, FEC, RTX= , who knows. But before the packed can be decoded by the codec, something = needs to consider the PT and other things such as port when not doing bundl= e to make this work. Keep in mind things like PLI are much more likely to b= e sent at the layer near the codec than at layer B so layers B and C are no= t as cleanly separated as one might wish.=20 That's a long way of saying, I was talking about the aggregate demux in med= ia stack that include whatever happened at layers B and C. If layer B only = used SSRC that's fine with me. I am trying to say what happens in the combi= nation of layer B/C put together. =20 What terminology should I be using to not cause confusion ? On May 27, 2013, at 7:57 AM, Colin Perkins wrote: > I don't agree with the phrasing about "packet processing pipelines", but = can't tell if this is a terminology disagreement or a more fundamental disc= onnect. The way I see the demultiplexing logically working is: >=20 > | > | packets > +-- v > | +----------+ > | |UDP socket| > A | +----------+ > | RTP || | | > | and RTCP || | +------> SCTP > | || +---------> STUN/ICE > +-- || > +-- || > | split by SSRC > | || || || > | || || || > B | +--+ +--+ +--+ > | |PB| |PB| |PB| Playout buffer, process RTCP, FEC, etc. > | +--+ +--+ +--+ > +-- | | | > +-- | / | > | +---+ | > | / | | > C | +--+ +--+ +--+ > | |CR| |CR| |CR| Codecs and rendering > | +--+ +--+ +--+ > +-- >=20 > If your algorithm is for demultiplexing at layer C, i.e., to figure out w= hat codec and rendering pipeline to use, then I think we're in agreement ap= art from terminology.=20 >=20 > For layer B, I believe the SSRC is the right thing to use to demultiplex,= and fits with RTP and RTCP. This is where RTCP is processed, playout de-ji= tter buffering happens, FEC is processed, NACKs are sent, etc. It's logical= ly independent of the decoding and rendering process since you can start fi= lling your de-jitter buffer for an SSRC before you figure out if/how/where = you're going to render that SSRC.=20 >=20 > For layer A, there was a clear-cut way of doing this with RTP, RTCP, and = STUN. I haven't looked at SCTP enough to know how that affects things. I do= think it's a logically separate issue, and should be documented separately= to BUNDLE though, since it the same issues arise with non-bundled sessions= . >=20 > An implementation might merge these together, of course, but to avoid con= fusion the standards should be clear what level they're considering. >=20 > Colin >=20 >=20 >=20 > On 27 May 2013, at 14:15, Cullen Jennings (fluffy) wrote: >> Great - sounds like we agree this algorithm will work. >>=20 >> On May 27, 2013, at 6:41 AM, Colin Perkins wrote: >>=20 >>> I'm not sure I agree. >>>=20 >>> As I said in my previous message to the list, if we are agreed that the= m=3D lines in a BUNDLE group form a single RTP session, then I believe we = need unique payload types across all m=3D lines. In this case, BUNDLE can s= imply say that regular RTP source demultiplexing based on the SSRC has to b= e performed, then the payload type can be used to match sources to m=3D lin= es for those applications that care about doing so.=20 >>>=20 >>> If we're not agreed that the m=3D lines in a BUNDLE group form a single= RTP session, then we have a lot more to discuss... >>>=20 >>> Colin >>>=20 >>>=20 >>>=20 >>> On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: >>>> Here's is my proposal for roughly what the bundle draft should say abo= ut this demux topic=20 >>>>=20 >>>> Application will decide which packet processing pipeline to pass an gi= ven RTP/RTCP packet to based on what the application knows: >>>>=20 >>>> 1) If future RFCs define new things (like RTP header extension), that = explicitly specify the mapping, check if that future RFC is in use and if s= o then use that to form the mapping=20 >>>>=20 >>>> 2) If the PT type is uniquely identifies a mapping, use that to form t= he mapping >>>>=20 >>>> 3) If application knows the SSRC the other side will use, use that to = form the mapping=20 >>>>=20 >>>> 4) if there is no way to know which pipeline to pass it too, the packe= t MAY be discarded or the application MAY decide to buffer it until the map= ping is known=20 >>>>=20 >>>> This is trivial to implement. It meets the requirements for Plan A, Pl= an B, UCIF, CLUE, and so on.=20 >>>>=20 >>>> We could swap the order of step 2 and 3, My thinking for this order wa= s the only time it made any difference the order was if the PT were unique = and indicated a different mapping than the SSRC. The only way this could ha= ppen is with a SSRC collision so the PT is the one that would be correct no= t the SSRC. If someone feels strongly the order of steps 2 and 3 should be = the opposite way around, I can live with that. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>>=20 >>>=20 >>> --=20 >>> Colin Perkins >>> http://csperkins.org/ >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Thu May 30 12:08:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C520E21F9113 for ; Thu, 30 May 2013 12:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQYOpwPBlXrl for ; Thu, 30 May 2013 12:08:52 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E8D3721F9080 for ; Thu, 30 May 2013 12:08:46 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id p57so573751wes.4 for ; Thu, 30 May 2013 12:08:36 -0700 (PDT) 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=VnVGvWA/Wzehia2BlL70NXjQv0WloDWJb9XhGjyYPvQ=; b=EtMAsKhpIo8Os02djEw/RKHD2uJrAIVbbVG/9139qYCHZwhrNhTE61MmQg2k+HMKTJ S6lcYUL26uvEzPkc2ex29IV5UB+22sdH3kdOSgyKc1bouhjkUzZA3PglpN/qhQRtXd+j 0oY/ESYMcSs3ZaF1+LM1pJKOZCTg8R6TSnR0YsvmYe77ia7+DeNlQON94EgdcTx/pJwj 4De8aZuCsf1AVCaQLJoVel8G+Td0EdkyYFhZvnCX1Oc0pfpIRSkNaLodo8Hhj1yjfQyc yFblEaC++YGvxvAIapEfORkHxu2QzznOBD2DrkCXq4MQh4EVk5MfarOaefziXt3an5ir 1LGQ== MIME-Version: 1.0 X-Received: by 10.181.13.74 with SMTP id ew10mr186487wid.9.1369940916817; Thu, 30 May 2013 12:08:36 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Thu, 30 May 2013 12:08:36 -0700 (PDT) In-Reply-To: <51A7A2B9.5020909@cisco.com> References: <51A6700B.40108@cisco.com> <51A7A2B9.5020909@cisco.com> Date: Thu, 30 May 2013 12:08:36 -0700 Message-ID: From: Martin Thomson To: Flemming Andreasen Content-Type: text/plain; charset=UTF-8 Cc: mmusic Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:08:52 -0000 On 30 May 2013 12:04, Flemming Andreasen wrote: > I'm not trying to be facetious, but it is genuinely hard to say when the > draft hasn't been announced or discussed in MMUSIC (and this is not the only > draft that suffers from that). It seems the bulk of the work and discussions > happen in RTCWeb but with an expectation that decisions are to be made in > MMUSIC. Maybe this is part of the reason for the lack of progress on this > one and we should reconsider the approach ? That is a perfectly reasonable response. I believe that having the discussion piecemeal across different working groups hasn't helped at all. In part, I was hoping that Emil would explain why he chose to tag his draft as rtcweb rather than mmusic. I was wondering if the intent was to avoid entering into this plan a/b discussion here, and only address the WebRTC API. From fluffy@iii.ca Thu May 30 12:15:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8F021F9113 for ; Thu, 30 May 2013 12:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udffo8S+Wlgd for ; Thu, 30 May 2013 12:15:49 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2576521F9080 for ; Thu, 30 May 2013 12:15:49 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E1B60509B8; Thu, 30 May 2013 15:15:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51A7A2B9.5020909@cisco.com> Date: Thu, 30 May 2013 13:15:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51A6700B.40108@cisco.com> <51A7A2B9.5020909@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1503) Cc: mmusic Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:15:53 -0000 I know I'm guilt of just replying without looking at what list I am = sending stuff to but the how we use SDP (plan A/ planB) should be = happening on mmusic list. I'll try and do better.=20 On May 30, 2013, at 1:04 PM, Flemming Andreasen = wrote: > I'm not trying to be facetious, but it is genuinely hard to say when = the draft hasn't been announced or discussed in MMUSIC (and this is not = the only draft that suffers from that). It seems the bulk of the work = and discussions happen in RTCWeb but with an expectation that decisions = are to be made in MMUSIC. Maybe this is part of the reason for the lack = of progress on this one and we should reconsider the approach ? >=20 > Thanks >=20 > -- Flemming >=20 >=20 > On 5/29/13 6:35 PM, Mary Barnes wrote: >> I would certainly hope that this draft would also be on the agenda. >>=20 >> Mary. >>=20 >> On Wed, May 29, 2013 at 5:19 PM, Martin Thomson >> wrote: >>> On 29 May 2013 14:15, Flemming Andreasen wrote: >>>> You may also want to look at >>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>=20 >>> ? >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From prvs=4863755801=christer.holmberg@ericsson.com Fri May 31 00:33:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9FF21F941F for ; Fri, 31 May 2013 00:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy1ddQYhJHz8 for ; Fri, 31 May 2013 00:33:19 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF921F8CF4 for ; Fri, 31 May 2013 00:33:18 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-3c-51a8523d422c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 42.21.09795.D3258A15; Fri, 31 May 2013 09:33:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Fri, 31 May 2013 09:33:16 +0200 From: Christer Holmberg To: "mmusic@ietf.org" , "suhasietf@gmail.com" , =?iso-8859-1?Q?Ari_Ker=E4nen?= , "Flemming Andreasen (fandreas@cisco.com)" Thread-Topic: Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections 5.22, 5.40, 5.41, 5.42 Thread-Index: Ac5dzHO0Q+r/un2nR0ihy0dNOS7t9g== Date: Fri, 31 May 2013 07:33:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37E6A7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C37E6A7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvra5t0IpAg1fPZCzeX9C1mLr8MYtF b0O4xc65HcwOLB6tz/ayekz5vZHVY+esu+weS5b8ZApgieK2SUosKQvOTM/Tt0vgztj7zq/g xAHGilc/PrM0MC5ezNjFyMkhIWAiMaW3hRnCFpO4cG89WxcjF4eQwGFGic2H5rJAOEsYJT6u WMTUxcjBwSZgIdH9TxskLiJwlVHibPtCsG5mgQyJKY1zWUFsYYFkiVvrWllB6kWA4rfvlYCE RQT0JDqfP2MCsVkEVCWe3bjIBmLzCvhKHFr0GqyVEeiI76fWMEGMFJe49WQ+E8RxAhJL9pyH OlRU4uXjf2DjJQQUJZb3y4GYzAL5EtvOq0FMFJQ4OfMJywRG4VlIBs1CqJqFpAqiRE/ixtQp bBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FyJ6bmJmTXm6+iREYRQe3/DbYwbjpvtghRmkOFiVx Xn3exYFCAumJJanZqakFqUXxRaU5qcWHGJk4OEEEl1QDo/6U9RbLmirnbqi1+LdqQdbfie0d 4uv+TM1Ws5DP9ek/ebGWU//X40OFp7MFpHZy9qhJnyjcWK38mcXfaHKeW2P1903n5pldmr9K Xdb0r5CSoKpPp25WcnfY0WsvHnrLPGjIFfQ4t2ttO2t5+gdPhznZ76Met7w73lUquHZGcuna yXNuN8xbpcRSnJFoqMVcVJwIAJ2G2vd1AgAA Subject: [MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections 5.22, 5.40, 5.41, 5.42 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 07:33:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C37E6A7ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was requested to review the attributes listed in sections 5.22, 5.40, 5.4= 1 and 5.42. However, first I have a general comment on the document: For some attributes (e.g. MSRP-CEMA), there is note text saying: "Not recommended due to legacy interop purposes" Making such statements is completely outside the scope of the document. The= document is about multiplexing, and how/if attributes are affected. There is also similar note text saying: "Not recommended due to interop purposes" Now, for the 3GPP defined attributes you could say "Usage only defined for = IMS", or something. But, again, it's not within the scope of this document = to recommend against using things. ...unless, of course, there from a multiplexing perspective is a reason to = do so, and they should be listed under the NOT RECOMMENDED category: 5.22 +------------+---------------------------------+---------+----------+ | Name | Notes | Current | Category | +------------+---------------------------------+---------+----------+ | msrp-cema | | M | NORMAL | | | | | | | | | | | +------------+---------------------------------+---------+----------+ 5.40 +-------------+--------------------------------+---------+----------+ | Name | Notes | Current | Category | +-------------+--------------------------------+---------+----------+ | g.3gpp.cat | Usage defined for the IP | M | NORMAL | | | Multimedia Subsystem [ref] | | | | | | | | +-------------+--------------------------------+---------+----------+ 5.41 +-------------+--------------------------------+---------+----------+ | Name | Notes | Current | Category | +-------------+--------------------------------+---------+----------+ | g.3gpp.crs | Usage defined for the IP | M | NORMAL | | | Multimedia Subsystem [ref] | | | | | | | | +-------------+--------------------------------+---------+----------+ 5.42 This is actually an interesting one, and needs a little more investigation.= So, I'll have to come back on that one. It would be good if Richard Ejzak,= who is the "architect" behind the attributes, could take a look :) +------------------+---------------------------+---------+----------+ | Name | Notes | Current | Category | +------------------+---------------------------+---------+----------+ | secondary-realm | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | visited realm | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-m-cksum | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-s-cksum | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-m-att | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-s-att | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-s-bw | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-m-att | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-codecs | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | +------------------+---------------------------+---------+----------+ Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C37E6A7ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I was requested to review the attributes listed in s= ections 5.22, 5.40, 5.41 and 5.42.

 

However, first I have a general comment on the docum= ent:

 

For some attributes (e.g. MSRP-CEMA), there is note = text saying:

 

“Not recommended due to legacy interop purpose= s”

 

Making such statements is completely outside the sco= pe of the document. The document is about multiplexing, and how/if attribut= es are affected.

 

There is also similar note text saying:

 

“Not recommended due to interop purposes”= ;

 

Now, for the 3GPP defined attributes you could say &= #8220;Usage only defined for IMS”, or something. But, again, it’= ;s not within the scope of this document to recommend against using things.=

 

…unless, of course, there from a multiplexing = perspective is a reason to do so, and they should be listed under the NOT R= ECOMMENDED category:

 

 

5.22

 

  +------------+-----------------------------= ----+---------+----------+

   | Name       | = Notes           &nbs= p;            &= nbsp;  | Current | Category |

   +------------+-----------------------= ----------+---------+----------+

   | msrp-cema  |    &n= bsp;            = ;             &= nbsp;  | M       | NORMAL &nbs= p; |

   |       &n= bsp;    |         &n= bsp;            = ;           | &= nbsp;       |     &n= bsp;    |

   |       &n= bsp;    |        &nb= sp;            =             | &= nbsp;       |     &n= bsp;    |

   +------------+-----------------------= ----------+---------+----------+

 

 

5.40

 

   +-------------+--------------------------------&#=
43;---------+----------+
   | Name        | Notes&=
nbsp;           &nbs=
p;             =
| Current | Category |
   +-------------+--------------------------------&#=
43;---------+----------+
   | g.3gpp.cat  | Usage defined for the IP  =
     | M       | NORMAL &=
nbsp; |
   |         &n=
bsp;   | Multimedia Subsystem [ref]     |&nbs=
p;        |     =
;     |
   |         &n=
bsp;   |         &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   +-------------+--------------------------------&#=
43;---------+----------+

 

 

5.41

 

   +-------------+--------------------------------&#=
43;---------+----------+
   | Name        | Notes&=
nbsp;           &nbs=
p;             =
| Current | Category |
   +-------------+--------------------------------&#=
43;---------+----------+
   | g.3gpp.crs  | Usage defined for the IP  =
     | M       | NORMAL &=
nbsp; |
   |         &n=
bsp;   | Multimedia Subsystem [ref]     |&nbs=
p;        |     =
;     |
   |         &n=
bsp;   |         &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   +-------------+--------------------------------&#=
43;---------+----------+

 

 

5.42

 

This is actually an interesting one, and needs a lit= tle more investigation. So, I’ll have to come back on that one. It wo= uld be good if Richard Ejzak, who is the “architect” behind the= attributes, could take a look :)

 

  +------------------+---------------------------+---=
------+----------+
   | Name        &nb=
sp;    | Notes       &nbs=
p;             =
| Current | Category |
   +------------------+---------------------------&#=
43;---------+----------+
   | secondary-realm  | Usage defined for the IP  =
| M       | TBD      =
;|
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | visited realm    | Usage defined for the=
 IP  | M       | TBD   &n=
bsp;  |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-m-cksum      | Usage defin=
ed for the IP  | M       | TBD &nbs=
p;    |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-s-cksum      | Usage defin=
ed for the IP  | M       | TBD &nbs=
p;    |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-m-att        | U=
sage defined for the IP  | M       | TBD=
      |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-s-att        | U=
sage defined for the IP  | M       | TBD=
      |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-s-bw        =
; | Usage defined for the IP  | M       =
| TBD      |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-m-att        | U=
sage defined for the IP  | M       | TBD=
      |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |    =
     |       &n=
bsp;  |
   | omr-codecs       | Usage =
defined for the IP  | M       | TBD =
;     |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   +------------------+---------------------------&#=
43;---------+----------+

 

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C37E6A7ESESSMB209erics_-- From harald@alvestrand.no Fri May 31 01:05:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14421F8FB3 for ; Fri, 31 May 2013 01:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8JlRDelcYZ2 for ; Fri, 31 May 2013 01:05:51 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E8FD821F8E8F for ; Fri, 31 May 2013 01:05:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DD3D39E058; Fri, 31 May 2013 10:05:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CfNdGw0WaQG; Fri, 31 May 2013 10:05:47 +0200 (CEST) Received: from [192.168.34.10] (22.Red-83-38-155.dynamicIP.rima-tde.net [83.38.155.22]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1B35F39E031; Fri, 31 May 2013 10:05:44 +0200 (CEST) Message-ID: <51A859D4.7030201@alvestrand.no> Date: Fri, 31 May 2013 10:05:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <51A3C6C9.6050606@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mmusic Subject: Re: [MMUSIC] The pick-a-config debate - perhaps an useful example X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 08:05:57 -0000 On 05/30/2013 07:47 PM, Cullen Jennings (fluffy) wrote: > On May 27, 2013, at 2:49 PM, Harald Alvestrand wrote: > >> a=group:BUNDLE foo bar >> >> m=video >> a=mid:foo >> a=imageattr:* [x=160,y=100] >> a=rtpmap:96:vp8 >> >> m=video >> a=mid:bar >> a=imageattr:* [x=640,y=480] >> a=rtpmap:96:vp8 >> >> Now, the video is the same. > Small nit … as far as I am concerned, if the above is a 3264 based offer, the video could be from two different cameras. You need some other signaling to indicate it is simulcast. > I did not intend it to say whether it was simulcast or not - I wasn't thinking of simulcast when I wrote it, just about "one of the parties says he wants two different, incompatible resolutions". "The video is the same" was badly formulated; I meant "The video codec is the same". From prvs=68638fc20f=christer.holmberg@ericsson.com Fri May 31 01:16:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B438021F941F for ; Fri, 31 May 2013 01:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Dd6xTUW6A4 for ; Fri, 31 May 2013 01:16:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 162D921F95EF for ; Fri, 31 May 2013 01:16:20 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-60-51a85c53013a Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B2.51.18006.35C58A15; Fri, 31 May 2013 10:16:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Fri, 31 May 2013 10:16:19 +0200 From: Christer Holmberg To: Harald Alvestrand , mmusic Thread-Topic: [MMUSIC] The pick-a-config debate - perhaps an useful example Thread-Index: AQHOWxutP4AVe/uSTUeROL2lcmLxN5ke99bQ Date: Fri, 31 May 2013 08:16:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37E700@ESESSMB209.ericsson.se> References: <51A3C6C9.6050606@alvestrand.no> In-Reply-To: <51A3C6C9.6050606@alvestrand.no> 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+NgFjrILMWRmVeSWpSXmKPExsUyM+JvrW5IzIpAg3cX2CyO9XWxWUxd/pjF gcnjyoQrrB5LlvxkCmCK4rZJSiwpC85Mz9O3S+DO+Dj/EmNBQcXMWRYNjMFdjJwcEgImEjNn /mCHsMUkLtxbzwZiCwkcZpRY8Mazi5ELyF7CKLHyw2/mLkYODjYBC4nuf9ogNSICbhLH5kHU Cwt4Sfw4coAJIu4t0f9pPjOEbSTx5+85sDiLgKrE1AUnwWxeAV+Jqd9vskPs0pHY2vsArJ5T QFfi9fV5YDWMQPd8P7UGzGYWEJe49WQ+E8SdAhJL9pxnhrBFJV4+/scKcpqEgKLE8n45iHId iQW7P7FB2NoSyxa+ZoZYKyhxcuYTlgmMorOQTJ2FpGUWkpZZSFoWMLKsYmTPTczMSS832sQI jIGDW36r7mC8c07kEKM0B4uSOK8e7+JAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJwggkuqgVHo 5hd7673rzQ2d8lfM6/TzuJQcrpXy75e64LaH72YuZL9/06C670n3mSX2y+1qL2b75H8rTGpr YqiXlmv49kF6jYFq7fbyMM6HPPxlR3JKX0/nyG9ovxPw9LCwhZSWi+3Rl9eYui/f2t23S6b1 vLBPk9TLzf7d5dv1gprnPHKJ8z+mx7WQW4mlOCPRUIu5qDgRAGytLZ5UAgAA Subject: Re: [MMUSIC] The pick-a-config debate - perhaps an useful example X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 08:16:31 -0000 >I don't like the name "demux", as I've said before. Blame your parents - not us ;) Regards, Christer From prvs=586395ec7e=ivo.sedlacek@ericsson.com Fri May 31 02:49:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FF521F96EB for ; Fri, 31 May 2013 02:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzDIQ6-Ho592 for ; Fri, 31 May 2013 02:49:32 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CF56121F8E12 for ; Fri, 31 May 2013 02:49:31 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-14-51a8722ae759 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7A.F0.18006.A2278A15; Fri, 31 May 2013 11:49:30 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 31 May 2013 11:49:30 +0200 From: Ivo Sedlacek To: Gonzalo Salgueiro Thread-Topic: Comments to draft-ietf-mmusic-media-path-middleboxes Thread-Index: AQHOXV/vMkYv9S/UjUq1uIDl6n9odpkfC9Wg Importance: low X-Priority: 5 Date: Fri, 31 May 2013 09:49:29 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010D77EF@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B310790061010D72D7@ESESSMB301.ericsson.se> <673F23F8-5627-4F4A-A5ED-3A7987A634D0@cisco.com> In-Reply-To: <673F23F8-5627-4F4A-A5ED-3A7987A634D0@cisco.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvra5W0YpAg+Z7ahZzp/hZLN15j9Vi 6vLHLBbL5jxidmDxmPJ7I6vHzll32T0Wb9rP5rFkyU+mAJYobpukxJKy4Mz0PH27BO6Mtxf+ sRecNK74P/sLSwPjJ+UuRg4OCQETialdLl2MnECmmMSFe+vZuhi5OIQEDjNK/Ft8EcpZzCix adUSVpAqNgE9iYlbjoDZIgJaEtfvXGcCsZkFJjNK7FkuDmILCzhKvL36mgWixkni67UPTCDL RASMJC5P1gIJcwrwS7y4c5YNYjGvRO+SNrCRLAKqEjPPvQEbySvgLfHqeCtYq5BAncTaBV4Q rbYSzUeWgU1nFJCVuPqnlxHiAnGJW0/mM0GMFJBYsuc8M4QtKvHy8T9WCFtRov1pA1S9nsSz U7NYIGxtiWULXzNDrBWUODnzCcsERolZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXG21iBMbd wS2/VXcw3jkncohRmoNFSZxXj3dxoJBAemJJanZqakFqUXxRaU5q8SFGJg5OEMEl1cAo4cq/ Ju2f6dQ+S+msd1xp9t9fv6w5XWAU2zzJRtGWyaK1wk7tlu3K4KlT391dNkdr59uwzoYF1dF5 yjLG3c6mZfdbFVcrqYk+SWb/Z5p4UjZ0xhKjv+whiir7Tlwy+91+J6fX2KhSaWtjReKmDq/r p678/HWmyHmt7LUPDgv1PfNWM574+V+JpTgj0VCLuag4EQCxPJEbjgIAAA== Cc: "obsidian97@gmail.com" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Comments to draft-ietf-mmusic-media-path-middleboxes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 09:49:37 -0000 Thank you for covering my comments in draft-ietf-mmusic-media-path-middlebo= xes-07. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com]=20 Sent: 30. kv=ECtna 2013 20:03 To: Ivo Sedlacek Cc: Hannes.Tschofenig@gmx.net; obsidian97@gmail.com; mmusic@ietf.org Subject: Re: Comments to draft-ietf-mmusic-media-path-middleboxes Thanks, Ivo. I have posted a new version addressing your and Bruno's comme= nts. Thanks, Gonzalo On May 30, 2013, at 10:11 AM, Ivo Sedlacek wrot= e: > Hello, > =20 > Comments to draft-ietf-mmusic-media-path-middleboxes-06: > =20 > Comment 1: > =20 > ISSUE: > =20 > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 st= ates: > ------------------- > 3. Architecture > =20 > Figure 1 shows the architecture that is being considered in this > document with respect to firewall and NAT traversal using media > relaying. The timing and directionality with which media packets are > allowed to traverse a particular edge device is the subject of this > investigation. The MIDCOM agent thereby pushes policy rules to the > middlebox that allow or deny certain flows to >>bypass<<. Additionall= y, > in case of media relaying it is important for the MIDCOM agent to > adjust the signaling messages. > =20 > =20 > SIP +-----------------+ SIP > +-----+ Signaling | SIP ALG | Signaling +-----+ > | UAC |<----------->+-----------------+<----------->| UAS | > +-----+ | MIDCOM Agent | +-----+ > ^ +-----------------+ ^ > | ^ | > | Policy rule(s) | and NAT bindings | > | v | > | Media +-------------+ Media | > +----------------->| Middlebox |<-----------------+ > +-------------+ > =20 > Figure 1: Analysed Firewalling Architecture > =20 > The aspects of packet filtering are described in Section 4 whereas > NAT traversal is illustrated in Section 5. > ------------------- > =20 > The word "bypass" does not seem to be correct. > =20 > "bypass" is defined by http://dictionary.cambridge.org/ as: "to avoid som= ething by going around it" or " to ignore a rule or official authority". > =20 > However, the figure 1 shows media of the flows passing through/via the mi= ddlebox, not around the middlebox. > =20 > =20 > PROPOSAL: > ------------------- > 3. Architecture > =20 > Figure 1 shows the architecture that is being considered in this > document with respect to firewall and NAT traversal using media > relaying. The timing and directionality with which media packets are > allowed to traverse a particular edge device is the subject of this > investigation. The MIDCOM agent thereby pushes policy rules to the > middlebox that allow or deny certain flows to >>pass through<<. Addit= ionally, > in case of media relaying it is important for the MIDCOM agent to > adjust the signaling messages. > =20 > =20 > SIP +-----------------+ SIP > +-----+ Signaling | SIP ALG | Signaling +-----+ > | UAC |<----------->+-----------------+<----------->| UAS | > +-----+ | MIDCOM Agent | +-----+ > ^ +-----------------+ ^ > | ^ | > | Policy rule(s) | and NAT bindings | > | v | > | Media +-------------+ Media | > +----------------->| Middlebox |<-----------------+ > +-------------+ > =20 > Figure 1: Analysed Firewalling Architecture > =20 > The aspects of packet filtering are described in Section 4 whereas > NAT traversal is illustrated in Section 5. > ------------------- > =20 > Comment 2: > =20 > ISSUE: > =20 > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 st= ates: > ------------------- > REC #4: If signaling on the media path is required before media can > flow, the >>answer<< should send the SDP answer as soon as possible= , > for example within a provisional SIP response, to allow the media > path signaling to bypass middleboxes and therefore to avoid > clipping. > ------------------- > I believe there is an error. > =20 > PROPOSAL: > ------------------- > REC #4: If signaling on the media path is required before media can > flow, the >>answerer<< should send the SDP answer as soon as possib= le, > for example within a provisional SIP response, to allow the media > path signaling to bypass middleboxes and therefore to avoid > clipping. > ------------------- > =20 > Comment 3: > =20 > ISSUE: > =20 > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 st= ates: > ------------------- > REC #4: If signaling on the media path is required before media can > flow, the answer should send the SDP answer as soon as possible, > for example within a provisional SIP response, to allow the media > path signaling to >>bypass<< middleboxes and therefore to avoid > clipping. > ------------------- > Same issue as in Comment 1. > =20 > PROPOSAL: > ------------------- > REC #4: If signaling on the media path is required before media can > flow, the answer should send the SDP answer as soon as possible, > for example within a provisional SIP response, to allow the media > path signaling to >>pass through<< middleboxes and therefore to avo= id > clipping. > ------------------- > =20 > =20 > Kind regards > =20 > Ivo Sedlacek >=20 > Ericsson > Mobile +420 608 234 709 > ivo.sedlacek@ericsson.com > www.ericsson.com > =20 > This Communication is Confidential. We only send and receive email on the= basis of the terms set out at www.ericsson.com/email_disclaimer From prvs=28632c56aa=christer.holmberg@ericsson.com Fri May 31 03:31:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED11321F92FC for ; Fri, 31 May 2013 03:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mibdIhA2DUaP for ; Fri, 31 May 2013 03:30:58 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0021F9433 for ; Fri, 31 May 2013 03:30:56 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-84-51a87bdfa21b Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1F.16.15700.FDB78A15; Fri, 31 May 2013 12:30:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Fri, 31 May 2013 12:30:55 +0200 From: Christer Holmberg To: mmusic Thread-Topic: BUNDLE: SDP Offer Types Thread-Index: Ac5d6erED7N11c9tSI+QddHtfsU6Pg== Date: Fri, 31 May 2013 10:30:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C37F87CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvre796hWBBntemVlMXf6YxYHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3BkNH9+yFewPqZh8YB5jA+Nhzy5GTg4JAROJpbtmMULYYhIX 7q1n62Lk4hASOMwosX/jVCYIZwmjxMJde1m6GDk42AQsJLr/aYM0iAjISOzdtJkZxBYWUJBY 8/YWM0RcVeLKihXsELaexMk5i5lAWlmA4idWGYOYvAK+Ert2cIFUMAKt/X5qDROIzSwgLnHr yXwmiHMEJJbsOc8MYYtKvHz8jxWkVUJAUWJ5vxxEeb5Ex9FzLCA2r4CgxMmZT1gmMArNQjJp FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG9tzEzJz0csNNjMCQP7jlt+4O xlPnRA4xSnOwKInz6vEuDhQSSE8sSc1OTS1ILYovKs1JLT7EyMTBCSK4pBoYeadkH/zHvZj5 oVL1hWUHV3fZGLxO0OD9/Dg+dPZUHYO0AzfXXBdjkWF6W7qLjdezqysz2FLqC5/TNu2Ekh01 7u5b2bY/M193vbSfs9ONN1vFtkWxNHDlJoXizPYH804uCeb5VZetHWbzyt89sOWtyhSefxeU VlgunmycaRoa9StwybfESc+VWIozEg21mIuKEwHybCj2TAIAAA== Subject: [MMUSIC] BUNDLE: SDP Offer Types X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 10:31:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C37F87CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As we know, BUNDLE currently uses two main "types" of SDP Offers: one where= each m- line in the BUNDLE group has a different port number value, and on= e where each m- line has the same port value. Often we refer to these as "the first offer" resp. "the second offer". Now, this works fine when we talk about the session establishment, but as w= e know a session can contain multiple additional offers, and with BUNDLE th= ose can be of either type. So, my question is whether we should come up with some better wording. I'll throw the ball out with suggesting the following ones: - Bundle restart offer (different port value, currently referred t= o as "first offer") The reason I use "restart" wording is because this is used, no matter wheth= er in the beginning of the session or mid-session, to (re-)negotiate the us= age of BUNDLE, and the bundle address information selection. - Bundle sync offer (identical port value, currently referred to a= s "second offer") The reason I used "sync" wording is because this is used to ensure that int= ermediaries have correct address information for each m- line. Keep in mind that we may even need to split the sync offer into more sub ty= pes, when we get into the details of adding new m- lines etc, but I'd like = to agree a base to start from :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C37F87CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As we know, BUNDLE currently uses two main ”ty= pes” of SDP Offers: one where each m- line in the BUNDLE group has a = different port number value, and one where each m- line has the same port v= alue.

 

Often we refer to these as “the first offer= 221; resp. “the second offer”.

 

Now, this works fine when we talk about the session = establishment, but as we know a session can contain multiple additional off= ers, and with BUNDLE those can be of either type.

 

So, my question is whether we should come up with so= me better wording.

 

I’ll throw the ball out with suggesting the fo= llowing ones:

 

-     &= nbsp;    Bundle restart offer (different port value, = currently referred to as “first offer”)

 

The reason I use “restart” wording is be= cause this is used, no matter whether in the beginning of the session or mi= d-session, to (re-)negotiate the usage of BUNDLE, and the bundle address in= formation selection.

 

 

-     &= nbsp;    Bundle sync offer (identical port value, cur= rently referred to as “second offer”)

 

The reason I used “sync” wording is beca= use this is used to ensure that intermediaries have correct address informa= tion for each m- line.

 

Keep in mind that we may even need to split the sync= offer into more sub types, when we get into the details of adding new m- l= ines etc, but I’d like to agree a base to start from :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C37F87CESESSMB209erics_-- From emil@sip-communicator.org Fri May 31 03:46:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0986021F9399 for ; Fri, 31 May 2013 03:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGPwqVRWOWp0 for ; Fri, 31 May 2013 03:46:45 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EC75A21F910D for ; Fri, 31 May 2013 03:46:44 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg9so315354bkc.20 for ; Fri, 31 May 2013 03:46:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=8jGrXQFwrAyt79hasRsyATJjT48yaJD3xe58JQyVZb4=; b=UwlpfuhLZSra0DNGACgv8APN+RHKUeU3N09zvNmmN9cjkcrixvlWUe0K4KXuuWY3IQ 3PZ5nNpW9iEsd4xecvZmHUpd6VF9F8H2Sl5OleS7PMle3qVrbHPpNfvUaPe73dZVAelU I24F75U2mwaSPxNwS1H+IQXkktkDu6t7QtnNerjwAblGzLiDsN+dRtRQS+UE4auTdZBg C1RwlrcZnVKWc2khnzMl2p9aDOldD+LxziWvK6DF4669wHf9GQtoZV+Et674TF1fxvQD xT4GlkCdTqqMzUVC0lw+woOMDJFEbc78Rvq8pXIjD0siXy7il0wVe1RXD0ZO9m4oj0LV 44sg== X-Received: by 10.205.36.79 with SMTP id sz15mr3141382bkb.94.1369997203659; Fri, 31 May 2013 03:46:43 -0700 (PDT) Received: from camionet.local (77-85-161-202.btc-net.bg. [77.85.161.202]) by mx.google.com with ESMTPSA id uh4sm14997436bkb.14.2013.05.31.03.46.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 03:46:42 -0700 (PDT) Message-ID: <51A87F91.2080500@jitsi.org> Date: Fri, 31 May 2013 13:46:41 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: IESG Secretary References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> In-Reply-To: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlr/6kUEsgrzm0yt0xUGkrWvK676AIASawbJ0fmw+gFOrxzYDyMYANPqUcw7aHV/AOH6JHp Cc: mmusic@ietf.org, IETF Announcement List Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 10:46:46 -0000 Dear chairs, Could you please also consider the following draft for the interim meeting agenda: http://tools.ietf.org/html/draft-ivov-rtcweb-noplan I apologise if not stating this earlier has introduced any confusion. Regards, Emil On 30.05.13, 21:56, IESG Secretary wrote: > Greetings, > > This is to announce a(nother) virtual interim meeting for the MMUSIC > Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am > Pacific Time. The goal of this meeting is to come to a resolution on the > so-called "Plan A" or "Plan B" approach related to SDP signaling needed > by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or > very few "m=" lines and to what extent is there sub-negotation and > signaling at the SSRC level). > > A more detailed agenda and logistics will be sent out separately on the > MMUSIC mailing list. For now, people should take a close look at the > following two drafts: > > http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt > > http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > > You may also want to look at > http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt > > > Thanks > > -- Ari & Flemming (MMUSIC co-chairs) > > > PS: Per our previous interim meeting announcement, we tried to schedule > a longer and in-person physical interim meeting, however it has proven > impossible to find a set of dates where we could get critical mass for > such a meeting. Scheduling even a virtual interim before the Berlin IETF > has been surprisingly difficult with the above date being the only > viable option at this point. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- https://jitsi.org From emil@sip-communicator.org Fri May 31 03:46:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A310321F910D for ; Fri, 31 May 2013 03:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrW010ZHSdmb for ; Fri, 31 May 2013 03:46:46 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D2A7021F938E for ; Fri, 31 May 2013 03:46:45 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg9so318467bkc.34 for ; Fri, 31 May 2013 03:46:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=GWh5+EFshjpA0WCpt+1TVtrrlIeOKqI3IfGG7bMXJ+8=; b=RXCKz//MnWWr7Wpr8N5k78H/RqizDlD4WgJVZsiWuPIPWFFhWwzPQ60sqfY+B+Tbea mI0Rc0oH0sSHObV6pxj/oRfWEMXgbwUc7bf8HYuSZG36RJH/QTfHdlIYWa5fPs3DTr6u psahtffPCs5Wn95VXSP7isWLt0vk9Q3kwCzztNbJ5EjEnPINckKYBHzGFkUBQro07RXk gF+4KIqYDsXYZUfkK/tSSO2LjKYv1tNvedDIxGAGmmEMz2XikPOwm5pLJ+X9ktFKzgTX T8fWJGYzttMGbZIS6zLRvbBvJ2Ad99QDgxCRVMsZrwaiD9bJirk7r1XNo6pfLDOynJPy 9F5Q== X-Received: by 10.204.191.72 with SMTP id dl8mr1999975bkb.56.1369997204903; Fri, 31 May 2013 03:46:44 -0700 (PDT) Received: from camionet.local (77-85-161-202.btc-net.bg. [77.85.161.202]) by mx.google.com with ESMTPSA id jy7sm6642162bkb.6.2013.05.31.03.46.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 03:46:44 -0700 (PDT) Message-ID: <51A87F93.1070009@jitsi.org> Date: Fri, 31 May 2013 13:46:43 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <51A6700B.40108@cisco.com> <51A7A2B9.5020909@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQngIMwAwiZILtwGYgbMyEgguULKl8pteaUGmL+qsApt7gQ4VmqH6Rx3msIAnntcjhmFuHsf Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 10:46:46 -0000 On 30.05.13, 22:08, Martin Thomson wrote: > On 30 May 2013 12:04, Flemming Andreasen wrote: >> I'm not trying to be facetious, but it is genuinely hard to say when the >> draft hasn't been announced or discussed in MMUSIC (and this is not the only >> draft that suffers from that). It seems the bulk of the work and discussions >> happen in RTCWeb but with an expectation that decisions are to be made in >> MMUSIC. Maybe this is part of the reason for the lack of progress on this >> one and we should reconsider the approach ? > > That is a perfectly reasonable response. I believe that having the > discussion piecemeal across different working groups hasn't helped at > all. > > In part, I was hoping that Emil would explain why he chose to tag his > draft as rtcweb rather than mmusic. Seriously? The three drafts that are currently part of the agenda are: draft-roach-rtcweb-plan-a-00 draft-uberti-rtcweb-plan-00 draft-roach-rtcweb-glareless-add-00 By the time No Plan arrived *all* Plan A vs Plan B discussions had been happening on the rtcweb mailing list. If chairs and contributors believe that it should instead be happening elsewhere, I would be happy to post wherever they redirect it to. Emil -- https://jitsi.org From hannes.tschofenig@gmx.net Fri May 31 04:31:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C429D21F9195 for ; Fri, 31 May 2013 04:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.38 X-Spam-Level: X-Spam-Status: No, score=-100.38 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnWQYNHumF7S for ; Fri, 31 May 2013 04:31:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6455B21F910D for ; Fri, 31 May 2013 04:31:05 -0700 (PDT) Received: from 3capp-gmx-bs43.server.lan ([172.19.170.95]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MfC3Y-1V2o4j3ITa-00Ommr; Fri, 31 May 2013 13:31:03 +0200 Received: from [194.251.119.198] by 3capp-gmx-bs43.server.lan with HTTP; Fri May 31 13:31:03 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "Ivo Sedlacek" Content-Type: text/html; charset=UTF-8 Date: Fri, 31 May 2013 13:31:03 +0200 (CEST) Importance: normal Sensitivity: Normal In-Reply-To: <39B5E4D390E9BD4890E2B310790061010D77EF@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B310790061010D72D7@ESESSMB301.ericsson.se> <673F23F8-5627-4F4A-A5ED-3A7987A634D0@cisco.com>, <39B5E4D390E9BD4890E2B310790061010D77EF@ESESSMB301.ericsson.se> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:5HJmCYnzjb/qo+AMLmPqIPKyU9RPZ3ktwYctYI9ql0d zzkyf8YtCKVCxE92Ae/XV3uNb5TWUn9IiOg2wXWEmLOJ3443xG uUHaA2NsX8gssV3zNjKgtYpwYtHDkwxy1nPy4Ab8HHcXdKSfAE BU0UW620pQjNNbsMxHy7wlGNL4MJQmPFEQIWskq0vYqqToaQa3 Q4G9ULEKWnKWt25a5xttj4jc8vPX9zy0p8N9i3hpkKRlm2JR5B gjS/1TYG0ie9qykhMI73dXrYoQlkpsd2JkTss+tC3kGQxZSdAK z5spoA= Cc: "obsidian97@gmail.com" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Comments to draft-ietf-mmusic-media-path-middleboxes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 11:31:09 -0000
Thanks for the careful reading of the document and for providing actionable feedback, Ivo. 
And thanks to Gonzalo for reacting so quickly with a new draft update. 
 
Ciao
Hannes
 
Gesendet: Freitag, 31. Mai 2013 um 11:49 Uhr
Von: "Ivo Sedlacek" <ivo.sedlacek@ericsson.com>
An: "Gonzalo Salgueiro" <gsalguei@cisco.com>
Cc: "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>, "obsidian97@gmail.com" <obsidian97@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Betreff: RE: Comments to draft-ietf-mmusic-media-path-middleboxes
Thank you for covering my comments in draft-ietf-mmusic-media-path-middleboxes-07.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

-----Original Message-----
From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com]
Sent: 30. května 2013 20:03
To: Ivo Sedlacek
Cc: Hannes.Tschofenig@gmx.net; obsidian97@gmail.com; mmusic@ietf.org
Subject: Re: Comments to draft-ietf-mmusic-media-path-middleboxes

Thanks, Ivo. I have posted a new version addressing your and Bruno's comments.

Thanks,

Gonzalo

On May 30, 2013, at 10:11 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

> Hello,
>
> Comments to draft-ietf-mmusic-media-path-middleboxes-06:
>
> Comment 1:
>
> ISSUE:
>
> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states:
> -------------------
> 3. Architecture
>
> Figure 1 shows the architecture that is being considered in this
> document with respect to firewall and NAT traversal using media
> relaying. The timing and directionality with which media packets are
> allowed to traverse a particular edge device is the subject of this
> investigation. The MIDCOM agent thereby pushes policy rules to the
> middlebox that allow or deny certain flows to >>bypass<<. Additionally,
> in case of media relaying it is important for the MIDCOM agent to
> adjust the signaling messages.
>
>
> SIP +-----------------+ SIP
> +-----+ Signaling | SIP ALG | Signaling +-----+
> | UAC |<----------->+-----------------+<----------->| UAS |
> +-----+ | MIDCOM Agent | +-----+
> ^ +-----------------+ ^
> | ^ |
> | Policy rule(s) | and NAT bindings |
> | v |
> | Media +-------------+ Media |
> +----------------->| Middlebox |<-----------------+
> +-------------+
>
> Figure 1: Analysed Firewalling Architecture
>
> The aspects of packet filtering are described in Section 4 whereas
> NAT traversal is illustrated in Section 5.
> -------------------
>
> The word "bypass" does not seem to be correct.
>
> "bypass" is defined by http://dictionary.cambridge.org/ as: "to avoid something by going around it" or " to ignore a rule or official authority".
>
> However, the figure 1 shows media of the flows passing through/via the middlebox, not around the middlebox.
>
>
> PROPOSAL:
> -------------------
> 3. Architecture
>
> Figure 1 shows the architecture that is being considered in this
> document with respect to firewall and NAT traversal using media
> relaying. The timing and directionality with which media packets are
> allowed to traverse a particular edge device is the subject of this
> investigation. The MIDCOM agent thereby pushes policy rules to the
> middlebox that allow or deny certain flows to >>pass through<<. Additionally,
> in case of media relaying it is important for the MIDCOM agent to
> adjust the signaling messages.
>
>
> SIP +-----------------+ SIP
> +-----+ Signaling | SIP ALG | Signaling +-----+
> | UAC |<----------->+-----------------+<----------->| UAS |
> +-----+ | MIDCOM Agent | +-----+
> ^ +-----------------+ ^
> | ^ |
> | Policy rule(s) | and NAT bindings |
> | v |
> | Media +-------------+ Media |
> +----------------->| Middlebox |<-----------------+
> +-------------+
>
> Figure 1: Analysed Firewalling Architecture
>
> The aspects of packet filtering are described in Section 4 whereas
> NAT traversal is illustrated in Section 5.
> -------------------
>
> Comment 2:
>
> ISSUE:
>
> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states:
> -------------------
> REC #4: If signaling on the media path is required before media can
> flow, the >>answer<< should send the SDP answer as soon as possible,
> for example within a provisional SIP response, to allow the media
> path signaling to bypass middleboxes and therefore to avoid
> clipping.
> -------------------
> I believe there is an error.
>
> PROPOSAL:
> -------------------
> REC #4: If signaling on the media path is required before media can
> flow, the >>answerer<< should send the SDP answer as soon as possible,
> for example within a provisional SIP response, to allow the media
> path signaling to bypass middleboxes and therefore to avoid
> clipping.
> -------------------
>
> Comment 3:
>
> ISSUE:
>
> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states:
> -------------------
> REC #4: If signaling on the media path is required before media can
> flow, the answer should send the SDP answer as soon as possible,
> for example within a provisional SIP response, to allow the media
> path signaling to >>bypass<< middleboxes and therefore to avoid
> clipping.
> -------------------
> Same issue as in Comment 1.
>
> PROPOSAL:
> -------------------
> REC #4: If signaling on the media path is required before media can
> flow, the answer should send the SDP answer as soon as possible,
> for example within a provisional SIP response, to allow the media
> path signaling to >>pass through<< middleboxes and therefore to avoid
> clipping.
> -------------------
>
>
> Kind regards
>
> Ivo Sedlacek
>
> Ericsson
> Mobile +420 608 234 709
> ivo.sedlacek@ericsson.com
> www.ericsson.com
>
> This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer
 
From pkyzivat@alum.mit.edu Fri May 31 07:14:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D8021F89C3 for ; Fri, 31 May 2013 07:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT5xtVDOmrlf for ; Fri, 31 May 2013 07:14:51 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 8024D21F8F7B for ; Fri, 31 May 2013 07:14:50 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta14.westchester.pa.mail.comcast.net with comcast id icVt1l00116LCl05EeEq3f; Fri, 31 May 2013 14:14:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id ieEq1l00C3ZTu2S3SeEqqt; Fri, 31 May 2013 14:14:50 +0000 Message-ID: <51A8B059.7070705@alum.mit.edu> Date: Fri, 31 May 2013 10:14:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37F87C@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=1370009690; bh=4UbE2AxuBQIxG7FtiwtXaBBoYaV0oMjAMRG2fYltm/U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KkBqnuiZUS6y17LpMAMND0K/lMHXC7zaVZy4hFSXkbQ0MU73RCcOGJzXRdEhmexFN b6gqT/+3a/XPC3URFzrPyM+puMYrJl1q1PZygmseuVAfHjRSSqm0aobIzes/VRTH4j /YuOky5wbjGzC46k+2K4D1DXoJmB07XJgwfE5TdvCyXxLvUymw1GRVJRxMbFWpF9Uo ENbZNb7ll9bt+TeXwSXEKcJZoeWWzdYeirw6Wq/jf3gytSz3LWGo6C8SA4Dqrh9XX+ U3Jc+1oqy5OtO7po9O4qOK3PHoKZxx0PKT03XdB4cEVZhTjPqVvbASiXCf3jQ/PCXn BTLs9m5tqWtjw== Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 14:14:57 -0000 On 5/31/13 6:30 AM, Christer Holmberg wrote: > Hi, > > As we know, BUNDLE currently uses two main ”types” of SDP Offers: one > where each m- line in the BUNDLE group has a different port number > value, and one where each m- line has the same port value. > > Often we refer to these as “the first offer” resp. “the second offer”. > > Now, this works fine when we talk about the session establishment, but > as we know a session can contain multiple additional offers, and with > BUNDLE those can be of either type. > > So, my question is whether we should come up with some better wording. Yes, I agree we need something better. > I’ll throw the ball out with suggesting the following ones: > > -*Bundle restart offer* (different port value, currently referred to as > “first offer”) > > The reason I use “restart” wording is because this is used, no matter > whether in the beginning of the session or mid-session, to > (re-)negotiate the usage of BUNDLE, and the bundle address information > selection. > > -*Bundle sync offer* (identical port value, currently referred to as > “second offer”) > > The reason I used “sync” wording is because this is used to ensure that > intermediaries have correct address information for each m- line. > > Keep in mind that we may even need to split the sync offer into more sub > types, when we get into the details of adding new m- lines etc, but I’d > like to agree a base to start from :) Above seems like a good start, but I'm still grappling with some things and don't know how to talk about concisely: I understand that the next offer after a Bundle Restart Offer will typically be a Bundle Sync Offer. But if there is another offer after a Bundle Sync Offer, and it doesn't change anything about the bundle, then is it still a Bundle Sync Offer? Also, I don't believe the above are mutually exclusive. If I send an offer to add a new m-line to a bundle, and I give it distinct address info so that the answerer may take it out of the bundle if needed, then is that a Bundle Restart Offer or a Bundle Sync Offer? It seems to be a bit of each. And of course there may be multiple bundles described by the SDP, and these terms apply independently to each. Maybe we need a couple more terms for: - offer that adds a new m-line to bundle using the existing bundle address info. - offer that adds a new m-line to an existing bundle using unique address info. And even if we do that we still need to explain that they only describe typical cases, not all cases. Or else we need to find a way to use terms that apply more narrowly than to a complete offer or answer. Thanks, Paul